sssd-users November 2019

sssd-users@lists.fedorahosted.org

23 participants
23 discussions

sssd - ssh and ticket renewal
by Jay McCanta 04 Nov '19

04 Nov '19

I've been working with SSSD for a good while and I could have sworn I knew how to get this working, but.... Login on workstations via GDM and my Kerberos tickets get renewed automatically. As I type this, I realize that I do lock/unlock my screen at least once a day. My tickets never seem to expire on my workstation. From my workstation, I ssh to a server with sssd enabled authentication (Ubuntu bionic on both ends). I use a different account on the remote server and am asked for a password. Ssh is configured to use PAM and has it's own password authentication disabled. (PasswordAuthentication no; UsePAM yes; ChallengeResponseAuthentication yes). Home folders are kerberized NFS and upon initial login, all is well. However the ticket for this session never renews on its own. sudo will refresh the ticket. It's about the only other thing we have sssd enable for besides ssh. Without any sudo activity, the Kerberos ticket expires and we lose access to home folders. Current workaround is a user cron job that tries to refresh the key every hour. I have to sudo on this server several times a day so my tickets were being renewed. CO-workers don't have sudo access and they are the ones losing their tickets. Is my assumption that one should be able to ssh to a server and have that server refresh tickets (like on a workstation) a valid one? If so, where should I concentrate my efforts to get this working? Thanks to all in this group. [cid:image001.jpg@01D592E5.F6CEED20]<https://f5.com/> Jay McCanta | Principal Systems Administrator D +1 (206) 272-7998 M +1-206-434-1080

1 0

smartcard mapping via msUPN SAN (OID 1.3.6.1.4.1.311.20.2.3)?
by James Ralston 01 Nov '19

01 Nov '19

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.ht… 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…

2 5

Ability to auth sudo against a different back end using sssd.
by Erinn Looney-Triggs 01 Nov '19

01 Nov '19

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

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users November 2019