smartcard mapping via msUPN SAN (OID 1.3.6.1.4.1.311.20.2.3)?
by James Ralston
I was reviewing the documentation for the "certificate mapping and
matching rules for all providers" feature that landed in sssd 2.0:
https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file....
However, I'm not sure how to use this feature to map certificates to
AD users based on the msUPN SAN.
For smartcards used with Microsoft Active Directory, the certificate
with the "Microsoft Smartcardlogin" X509v3 Extended Key Usage object
(EKU) will typically have additional X509v3 Subject Alternative Name
objects:
$ pkcs15-tool --read-certificate 01 | openssl x509 -noout -text | grep
-A 1 'X509v3 Subject Alternative Name'
Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00
X509v3 Subject Alternative Name:
othername:<unsupported>, othername:<unsupported>
The OpenSSL x509 tool doesn't parse the othername attributes, but we
can use asn1parse to do so:
$ pkcs15-tool --read-certificate 01 | openssl asn1parse
Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00
0:d=0 hl=4 l=1296 cons: SEQUENCE
4:d=1 hl=4 l=1016 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
…
874:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternative Name
879:d=5 hl=2 l= 81 prim: OCTET STRING [HEX DUMP]:DEADBEEFDEADBEEF…
962:d=4 hl=2 l= 27 cons: SEQUENCE
Decoding the hex blob at offset 879 yields:
$ pkcs15-tool --read-certificate 01 | openssl asn1parse -strparse 879
Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00
0:d=0 hl=2 l= 79 cons: SEQUENCE
2:d=1 hl=2 l= 36 cons: cont [ 0 ]
4:d=2 hl=2 l= 10 prim: OBJECT :Microsoft Universal
Principal Name
16:d=2 hl=2 l= 22 cons: cont [ 0 ]
18:d=3 hl=2 l= 20 prim: UTF8STRING :123456789@example.org
"Microsoft Universal Principal Name" is OID 1.3.6.1.4.1.311.20.2.3:
$ grep -A 3 msUPN /usr/include/openssl/obj_mac.h
#define SN_ms_upn "msUPN"
#define LN_ms_upn "Microsoft Universal Principal Name"
#define NID_ms_upn 649
#define OBJ_ms_upn 1L,3L,6L,1L,4L,1L,311L,20L,2L,3L
From <http://oid-info.com/get/1.3.6.1.4.1.311.20.2.3>:
{
iso(1)
identified-organization(3)
dod(6)
internet(1)
private(4)
enterprise(1)
311 20 2 3
}
The value of this object will be set as the userPrincipalName
attribute on the AD user object of the person to whom the smartcard
was issued.
And this is why Microsoft Windows smartcard login doesn't need the AD
user object to have the user's certificate preloaded into the
userCertificate attribute.
Interestingly enough, for pkinit.so's pkinit_cert_match option, the
<SAN> component-rule is also matching against the msUPN object. You
can see this if you build pkinit.so with debugging and execute "kinit"
with "pkinit_cert_match = <SAN>.*@.*":
$ kinit
…
pkinit_cert_matching: Processing rule '<SAN>.*@.*'
parse_rule_component: found keyword '<SAN>'
parse_rule_component: found value '.*@.*'
parse_rule_component: returning 0
parse_rule_set: After parse_rule_component, remaining 0, rule ''
parse_rule_set: returning 0
crypto_retrieve_X509_sans: looking for SANs in cert = …
crypto_retrieve_X509_sans: found 2 subject alt name extension(s)
crypto_retrieve_X509_sans: unrecognized othername oid in SAN
crypto_retrieve_X509_key_usage: returning eku 0x60000000
crypto_retrieve_X509_key_usage: returning ku 0x80000000
…
check_all_certs: matching rule relation is NONE with 1 components
check_all_certs: subject: …
regexp_match: checking SAN rule '.*@.*' with value 123456789(a)example.org
regexp_match: the result is a match
component_match: returning match = 1
<SAN> component-rule
Looking at the source, crypto_retrieve_X509_sans() is targeting SAN
values of GEN_OTHERNAME and GEN_DNS; all other SAN objects are
skipped. And for GEN_OTHERNAME, it is targeting only specific OIDs
(thus the "unrecognized othername oid in SAN" line). But one of the
OIDs targeted is msUPN.
So… how can I configure sssd to perform the same matching on the msUPN
SAN that Windows and pkinit.so perform?
From looking at sss-certmap(5), my first attempt would be something
like this:
[certmap/example.org/msupn]
matchrule = &&<SAN:1.3.6.1.4.1.311.20.2.3>.*
maprule = (userPrincipalName={subject_pkinit_principal})
First, I suspect I don't need to use <SAN:dotted-decimal-oid> form,
but I don't know which <SAN:foo> match is the one I actually want,
because the man page doesn't clarify which <SAN:foo> matches
correspond to specific OIDs. Is it <SAN:pkinit>?
The same problem for the maprule: I'm not sure if
{subject_pkinit_principal} is the correct maprule to use. "The SAN
used by pkinit" sounds correct, though.
Thanks in advance for any tips…
4 years, 5 months
Ability to auth sudo against a different back end using sssd.
by Erinn Looney-Triggs
Folks I am in the process of working through this but I thought I would
throw it out just in case there were other thoughts or I was chasing
down the wrong lane.
We have a requirement for sudo to use a different password than the user
password where I work. Now in RHEL 7 we implemented this requirement by
modifying the pam stack for sudo to use the pam_krb5 module like the
following:
auth required pam_env.so
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so try_first_pass no_user_check
auth required pam_deny.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_krb5.so try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
Now pam_krb5 is configured to auth against a username/sudo principal in
/etc/krb5.conf like the following (the mappings is the important part):
[appdefaults]
pam = {
debug = false
forwardable = true
renew_lifetime = 24h
ticket_lifetime = 24h
krb4_convert = false
mappings = ^(.*)$ $1/sudo
}
pam_krb5 has for better or worse gone the way of the dodo in RHEL 8 and
so I am looking to implement something similar using sssd. Our systems
are already joined to an AD, and it appears to me for the moment that
the 'application domain' using pam_sss might be the right approach here.
I understand that it is best tested with LDAP, but well, here we go. So
thus far I have:
[application/appdom]
inherit_from = ad.example.com
and the /etc/pam.d/sudo has the following inserted:
auth sufficient pam_sss.so forward_pass domains=appdom
Great it seems to work. Now I need to remap the name to username/sudo
and auth it against kerb. I don't even know if this is possible at this
point, but again I thought I would write it up and ask just in case
someone knew.
Thanks,
-Erinn
4 years, 5 months
Samba4, sssd on same machine
by Thomas Schweikle
Hi!
I've set up samba4 as ad-dc -- worked right away.
Exported the keytab. "klist -ke" looks good:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
1 Administrator(a)ADA.DE (aes256-cts-hmac-sha1-96)
1 Administrator(a)ADA.DE (aes128-cts-hmac-sha1-96)
1 Administrator(a)ADA.DE (arcfour-hmac)
1 Administrator(a)ADA.DE (etype 3)
1 Administrator(a)ADA.DE (etype 1)
1 krbtgt(a)ADA.DE (aes256-cts-hmac-sha1-96)
1 krbtgt(a)ADA.DE (aes128-cts-hmac-sha1-96)
1 krbtgt(a)ADA.DE (arcfour-hmac)
1 krbtgt(a)ADA.DE (etype 3)
1 krbtgt(a)ADA.DE (etype 1)
1 AD01$(a)ADA.DE (aes256-cts-hmac-sha1-96)
1 AD01$(a)ADA.DE (aes128-cts-hmac-sha1-96)
1 AD01$(a)ADA.DE (arcfour-hmac)
1 AD01$(a)ADA.DE (etype 3)
1 AD01$(a)ADA.DE (etype 1)
checked kinit with the servers name:
# kinit -k AD01\$(a)ADA.DE
# klist
Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
Standard-Principal: AD01$(a)ADA.DE
Valid starting Expires Service principal
25.10.2019 19:00:20 26.10.2019 05:00:20 krbtgt/ADA.DE(a)ADA.DE
erneuern bis 01.11.2019 18:00:20
looks good too.
Then configured sssd:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, pac
domains = ADA.DE
#debug_level = 0x0270
[domain/ADA.DE]
enumerate = true
cache_credentials = true
id_provider = ad
auth_provider = ad
sudo_provider = none
chpass_provider = ad
access_provider = ad
ad_server = ad01.ada.de, ad02.ada.de
ad_maximum_machine_account_password_age = 30
ldap_id_mapping = false
use_fully_qualified_names = false
fallback_homedir = /home/%d/%u
fallback_shell = /bin/bash
skel_dir = /etc/skel
ldap_schema = ad
dyndns_update = false
dyndns_refresh_interval = 43200
dyndns_update_ptr = false
dyndns_ttl = 3600
debug_level = 0x0270
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
#debug_level = 0x0270
[pam]
reconnection_retries = 3
#debug_level = 0x0270
[pac]
reconnection_retries = 3
#debug_level = 0x0270
Then tried:
# getent passwd Administrator(a)ADA.DE
#
and got nothing.
Any idea anyone?
--
Thomas
4 years, 5 months
sssctl in RHEL6?
by Eugene Vilensky
Greetings,
Will sssctl ever be packaged for RHEL6?
Or alternatively, what might be the cheapest/easiest alternative to
check functionality such as pam_auth success/deny that sssctl
provides? (For executing on a client as a Nagios check, for example).
Thank you kindly,
Eugene
4 years, 6 months
Double-check that I have this sssd.conf right....
by Spike White
All,
I worked an sssd configuration case with my OS vendor in the last 3 weeks.
I have resolution and it's working 100% correctly.
Just wanted to double-check. A second set of eyes to verify this solution
is all above board.
The problem manifested itself in our multi-domain AD forest with Posix
Attributes. One parent domain that has a transitive trust with 4
(regional) child domains.
Thus all 4 child domains trust each other. All users and groups are stored
in the 4 child domains.
The original problem was that I was disabling subdomains_provider and
explicitly defining each of the 4 child domains. I had:
domains = amer.company.com,apac.company.com, ....
...
[domain/amer.company.com]
....
[domain/apac.company.com]
...
That worked great -- for everything except universal groups. Universal
groups exist in the first domain in which they're created, but they're
replicated to each domain. However, each child domain for this group's
membership only has the local users of that domain. The full universal
group membership is stored only in the global catalog (GC).
The problem? The GC lookups are done in the subdomain_provider's code. So
by disabling subdomains_provider, I was disabling GC lookups. Thus, I was
getting the group membership only of the first child domain queried (
amer.company.com).
What that amounted to is that remote support personnel couldn't log into
local boxes, because they weren't listed in the allowed groups.
So I re-wrote the sssd.conf file and only explicitly defined the one local
child domain. I left on subdomain_provider, so it auto-discovered the
other domains (sssctl domain-list confirms this).
Like this:
domains = amer.company.com
...
[domain/amer.company.com]
ldap_search_base = dc=AMER,dc=COMPANY,dc=COM
[domain/amer.company.com/apac.company.com]
ldap_search_base = dc=APAC,dc=COMPANY,dc=COM
So then, universal groups showed all memberships. The only remaining
problem was that now it was only searching the amer.company.com child
domain. So while a remote user was listed as a member of an allowed
universal group, the details of that user's account was not known.
I couldn't add these auto-discovered domains to the "domains" line. (only
domains explicitly defined in sssd.conf file are allowed in this line
apparently). But I was able to add:
domain_resolution_order = amer.company.com, emea.company.com,
apac.company.com, japn.company.com, company.com
Now all works 100%.
Is this all legit? Do you see any problems with above final sssd.conf
setting?
Spike
4 years, 6 months
Re: sssctl in RHEL6?
by Arpit Tolani
Hello
getent passwd -s sss username or id username can fetch data from cache, you
can never confirm if server is online or offline & where are we fetching
data from.
sssctl does a lot more.
AFAIK, There is no plan to bring sssctl in RHEL6, You can build your own
packages from source.
On Wed, Oct 23, 2019 at 9:24 PM Ondrej Valousek <
ondrej.valousek(a)adestotech.com> wrote:
> what about 'getent -s sss passwd <username>'?
> ------------------------------
> *From:* Eugene Vilensky <evilensky(a)gmail.com>
> *Sent:* Wednesday, October 23, 2019 4:29 PM
> *To:* sssd-users(a)lists.fedorahosted.org <sssd-users(a)lists.fedorahosted.org
> >
> *Subject:* [SSSD-users] sssctl in RHEL6?
>
> Greetings,
>
> Will sssctl ever be packaged for RHEL6?
>
> Or alternatively, what might be the cheapest/easiest alternative to
> check functionality such as pam_auth success/deny that sssctl
> provides? (For executing on a client as a Nagios check, for example).
>
> Thank you kindly,
> Eugene
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
> List Guidelines:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>
--
Thanks & Regards
Arpit Tolani
4 years, 6 months
sssd-session-recording
by MAUPERTUIS, PHILIPPE
Hi list,
With Redhat 8 come tlogs for session recording.
It seems a promising tool to comply with PCI DSS requirement 10.2 which requires Monitoring of all actions taken by any individual with root or administrative privileges.
Redhat preferred way to configure tlog-rec-session is through sssd.
I have doubt about the interaction between the nss and the session-recording sections.
The man states :
users (string)
A comma-separated list of users which should have session recording enabled.
Matches user names as returned by NSS. I.e. after the possible space
replacement, case changes, etc.
Am I right to understand that if the nss filters some users (root for example) with the filter_users directive, their sessions won't be recorded even if defined in the session-recording session ?
If yes is there a way to find the discrepancies between the two sections?
Thanks
Philippe
equensWorldline is a registered trade mark and trading name owned by the Worldline Group through its holding company.
This e-mail and the documents attached are confidential and intended solely for the addressee. If you receive this e-mail in error, you are not authorized to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. EquensWorldline and the Worldline Group therefore can accept no liability for any errors or their content. Although equensWorldline and the Worldline Group endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with equensWorldline and the Worldline Group by email
4 years, 6 months
Changed passwords in AD seem to take a long time to be seen on sssd-integrated servers?
by Spike White
All,
Users are complaining when they change their passwords in AD, it's taking
an excessive amount of time to be reflected on their sssd-integrated Linux
servers. Temporarily, they are denied access to their boxes.
These are boxes they log into frequently, so I'm guessing their Posix
attributes are read from cache. (Does this include their password)?
I'm setting only these cache settings in the sssd.conf file:
[nss]
entry_cache_nowait_percentage = 75
...
[domain/xxx]
...
cache_credentials = True
Here's the entry that's being reported (in /var/log/secure). The user
reports that he waits 15 - 20 mins after changing his password in AD before
attempting to ssh in:
Oct 21 19:50:16 acmappdev01 sshd[9817]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129
user=gudar1
Oct 21 19:50:16 acmappdev01 sshd[9817]: pam_sss(sshd:auth): received for
user gudar1: 6 (Permission denied)
After 20 - 30 mins, the problem goes away without any intervention.
Oct 21 20:15:40 acmappdev01 sshd[11326]: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.185.116.129
user=gudar1
Oct 21 20:15:40 acmappdev01 sshd[11326]: Accepted password for gudar1 from
10.185.116.129 port 49954 ssh2
I realize it can take up to 30 mins for a changed password to fully
replicate in AD globally.
But what settings in sssd determine how long passwords are stored in cache?
I see entry_cache_timeout, which has a default of 5400 seconds. (1.5
hrs). Should I set entry_cache_user_timeout to something lower -- say 15
mins?
Spike
4 years, 6 months
SSSD multiple domain controllers issue.
by Abhisheyk Deb
Hi.
We have the following setup, CentOS machines which are running 7.3 version
and we want them to use active directory users for SSH Logins.
The domain ad.example.com which we want to use, has two domain controllers
with IP addresses of 10.1.2.1 and 10.1.2.2, and both have DNS Servers
installed on them.
We have the following in the /etc/resolv.conf
search ad.example.com
nameserver 10.1.2.1
nameserver 10.1.2.2
We were able to do a join by using the following command:
realm join ad.example.com
The computer objects are getting created in both domain controllers.
The SSH Logins for the active directory users are also working without any
issues.
The /etc/sssd/sssd.conf file is as follows:
[sssd]
domains = ad.example.com
config_file_version = 2
services = nss, pam
[pam]
offline_credentials_expiration = 1
[domain/ad.example.com]
ad_domain = ad.example.com
krb5_realm = ad.example.com
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
access_provider = ad
override_homedir = /user/%u
account_cache_expiration = 1
entry_cache_timeout = 180
But when we put the first domain controller down (10.1.2.1) which is the
first nameserver in /etc/resolv.conf. SSSD is not trying the second domain
controller (10.1.2.2) at all because when we login, we see the following
message
"Authenticated with cached credentials, your cached password will expire
at: Fri Oct 18 19:47:42 2019."
And we are able to ping 10.1.2.2 and the command
nslookup ad.example.com also gives the following output
Server: 10.1.2.2
Address: 10.1.2.2#53
Name: ad.example.com
Address: 10.1.2.1
Name: ad.example.com
Address: 10.1.2.2
And we have not added any option for ad_server or ad_backup_server in our
sssd.conf file which I am assuming means that autodiscovery is turned on by
default.
So should the /etc/resolv.conf only have one nameserver entry, and SSSD
only reads that, which means the main domain controller needs to running
always.
What I mainly want to know is that even if one of the Domain Controllers
are down and SSSD was using it as the primary domain controller for
authentication requests, can it not fallback to using some other domain
controllers in the AD Domain.
How can tweak my sssd.conf file for the use case that I want.
If somebody can give me some advice on this, it would be really helpful,
Thank you
Abhishek Deb
4 years, 6 months
libnss request does not reach sssd responder
by Rowan Decker
Following through the troubleshooting guide and getting stuck on step 3.
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html#getent-passw...
Absolutely no output occurs in the sssd log (good or bad) even with [nss] debug_level=6. Running strace on getent I can confirm that the sss library is getting loaded.
open("/lib64/libnss_sss.so.2", O_RDONLY) = 3
open("/lib64/libnss3.so", O_RDONLY) = 3
open("/lib64/libnssutil3.so", O_RDONLY) = 3
Looking in the sssd output I can see that the nss responder has started
(Thu Oct 10 22:22:50 2019) [sssd[nss]] [sss_process_init] (0x0400): Responder initialization complete (explicitly configured)
What other steps can be preformed to help debug this issue? We are using a custom distribution with an older gcc/glibc toolchain with the following configuration.
./configure \
--with-smb-idmap-interface-version=6 \
--without-selinux \
--without-semanage \
--exec-prefix=/ \
--localstatedir=/var \
--libexecdir=/usr/libexec \
--datarootdir=/usr/share \
--prefix=/. \
4 years, 6 months