Am Thu, Mar 02, 2023 at 01:51:47PM -0600 schrieb Spike White: > All, > > We are surveying our ecosystem of Linux servers, trying to slowly eradicate > the weak rc4 encryption from AD. (Our AD team has done all the legwork; > plus we’ve tested and we’re certain that rc4 is not required for OS-level > AD integration.) > > We’re focusing on eliminating rc4 from our sssd-based OS-level logins > now. What we want to do is determine which servers are currently relying > on rc4 for their Kerberos OS-level creds. > > A simple way to do this (usually) is to acquire a Kerberos host credential > and see what encryption it negotiated. > > kinit -k > > klist -e | grep Etype > > renew until 03/09/2023 12:41:32, Etype (skey, tkt): > aes256-cts-hmac-sha1-96, > aes256-cts-hmac-sha1-96 > > > > Normally, it’ll get aes256 or aes128; either of which are good. > > But we’ve hit on some old builds (RHEL7) where we don’t understand what’s > going on. We frankly don’t understand how sssd is working on them. (48 > servers in total). We want to audit these, but we’re unclear how. > > Sssd is starting and running fine on them. Adcli testjoin is working. But > we don’t know why! > > We think because the server names are in upper-case on these builds, that’s > part of our problem. > > ldap_sasl_authid is set as so in /etc/sssd/sssd.conf file: > > ldap_sasl_authid = srspls3bwcof104.us.example....@amer.example.com > <srspls3bwcof104.us.dell....@amer.dell.com> > > default_realm and mapping from DNS domain to AD domain isn’t set in > /etc/krb5.conf file. (Yes, we know this is bad.) > > adcli testjoin succeeds. > > [root@SRSPLS3BWCOF104 etc]# adcli testjoin -D AMER.EXAMPLE.COM -v > > * Found realm in keytab: AMER.EXAMPLE.COM > > * Found computer name in keytab: SRSPLS3BWCOF104 > > * Found service principal in keytab: host/srspls3bwcof104.us.example.com > > * Found host qualified name in keytab: srspls3bwcof104.us.example.com > > * Found service principal in keytab: host/SRSPLS3BWCOF104 > > * Found service principal in keytab: RestrictedKrbHost/SRSPLS3BWCOF104 > > * Found service principal in keytab: RestrictedKrbHost/ > srspls3bwcof104.us.example.com > > * Using domain name: AMER.EXAMPLE.COM > > * Calculated computer account name from fqdn: SRSPLS3BWCOF104 > > * Using domain realm: AMER.EXAMPLE.COM > > * Discovering domain controllers: _ldap._tcp.AMER.EXAMPLE.COM > > * Sending NetLogon ping to domain controller: > AUSDC16AMER41.amer.example.com > > * Received NetLogon info from: AUSDC16AMER41.amer.example.com > > * Discovering site domain controllers: _ldap._tcp.AMERAustin._sites.dc._ > msdcs.amer.example.com > > * Sending NetLogon ping to domain controller: > AUSDC16AMER14.amer.example.com > > * Received NetLogon info from: AUSDC16AMER14.amer.example.com > > * Wrote out krb5.conf snippet to > /tmp/adcli-krb5-62UEmj/krb5.d/adcli-krb5-conf-EvFdQ4 > > * Authenticated as default/reset computer account: SRSPLS3BWCOF104 > > * Using GSS-SPNEGO for SASL bind > > * Looked up short domain name: AMERICAS > > * Looked up domain SID: S-1-5-21-1802859667-647903414-1863928812 > > Sucessfully validated join to domain AMER.EXAMPLE.COM > > [root@SRSPLS3BWCOF104 etc]# > > > > Sssd service is fat and happy. > > [root@SRSPLS3BWCOF104 etc]# systemctl status sssd > > ● sssd.service - System Security Services Daemon > > Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor > preset: disabled) > > Active: active (running) since Thu 2023-03-02 11:30:25 EST; 2h 25min ago > > Main PID: 28053 (sssd) > > CGroup: /system.slice/sssd.service > > ├─28053 /usr/sbin/sssd -i --logger=files > > ├─28054 /usr/libexec/sssd/sssd_be --domain amer.example.com > --uid 0 --gid 0 --logger=files > > ├─28055 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files > > ├─28056 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files > > ├─28057 /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --logger=files > > └─28058 /usr/libexec/sssd/sssd_autofs --uid 0 --gid 0 > --logger=files > > > > Mar 02 13:15:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 1 > > Mar 02 13:15:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 2 > > Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 1 > > Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 1 > > Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 1 > > Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 2 > > Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 1 > > Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 1 > > Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 1 > > Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI > client step 2 > > [root@SRSPLS3BWCOF104 etc]# > > > > /etc/krb5.keytab file has new updated entries in the last 30 days. > > [root@SRSPLS3BWCOF104 etc]# klist -kte > > Keytab name: FILE:/etc/krb5.keytab > > KVNO Timestamp Principal > > ---- ------------------- > ------------------------------------------------------ > > 28 02/09/2023 16:14:59 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM (arcfour-hmac) > > 28 02/09/2023 16:14:59 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM > (aes128-cts-hmac-sha1-96) > > 28 02/09/2023 16:14:59 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM > (aes256-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 host/ > srspls3bwcof104.us.example....@amer.example.com (arcfour-hmac) > > 28 02/09/2023 16:15:00 host/ > srspls3bwcof104.us.example....@amer.example.com (aes128-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 host/ > srspls3bwcof104.us.example....@amer.example.com (aes256-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 host/srspls3bwcof...@amer.example.com > (arcfour-hmac) > > 28 02/09/2023 16:15:00 host/srspls3bwcof...@amer.example.com > (aes128-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 host/srspls3bwcof...@amer.example.com > (aes256-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 RestrictedKrbHost/srspls3bwcof...@amer.example.com > (arcfour-hmac) > > 28 02/09/2023 16:15:00 RestrictedKrbHost/srspls3bwcof...@amer.example.com > (aes128-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 RestrictedKrbHost/srspls3bwcof...@amer.example.com > (aes256-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 RestrictedKrbHost/ > srspls3bwcof104.us.example....@amer.example.com (arcfour-hmac) > > 28 02/09/2023 16:15:00 RestrictedKrbHost/ > srspls3bwcof104.us.example....@amer.example.com (aes128-cts-hmac-sha1-96) > > 28 02/09/2023 16:15:00 RestrictedKrbHost/ > srspls3bwcof104.us.example....@amer.example.com (aes256-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:22 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM (arcfour-hmac) > > 27 01/10/2023 06:14:22 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM > (aes128-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:22 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM > (aes256-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 host/ > srspls3bwcof104.us.example....@amer.example.com (arcfour-hmac) > > 27 01/10/2023 06:14:23 host/ > srspls3bwcof104.us.example....@amer.example.com (aes128-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 host/ > srspls3bwcof104.us.example....@amer.example.com (aes256-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 host/srspls3bwcof...@amer.example.com > (arcfour-hmac) > > 27 01/10/2023 06:14:23 host/srspls3bwcof...@amer.example.com > (aes128-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 host/srspls3bwcof...@amer.example.com > (aes256-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 RestrictedKrbHost/srspls3bwcof...@amer.example.com > (arcfour-hmac) > > 27 01/10/2023 06:14:23 RestrictedKrbHost/srspls3bwcof...@amer.example.com > (aes128-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 RestrictedKrbHost/srspls3bwcof...@amer.example.com > (aes256-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 RestrictedKrbHost/ > srspls3bwcof104.us.example....@amer.example.com (arcfour-hmac) > > 27 01/10/2023 06:14:23 RestrictedKrbHost/ > srspls3bwcof104.us.example....@amer.example.com (aes128-cts-hmac-sha1-96) > > 27 01/10/2023 06:14:23 RestrictedKrbHost/ > srspls3bwcof104.us.example....@amer.example.com (aes256-cts-hmac-sha1-96) > > [root@SRSPLS3BWCOF104 etc]# > > > > But when we kinit it fails. > > > > [root@SRSPLS3BWCOF104 etc]# hostname --fqdn > > SRSPLS3BWCOF104.us.example.com > > [root@SRSPLS3BWCOF104 etc]# kinit -k > > kinit: Client 'host/srspls3bwcof104.us.example....@amer.example.com' not > found in Kerberos database while getting initial credentials > > [root@SRSPLS3BWCOF104 etc]# kinit -k 'host/ > srspls3bwcof104.us.example....@amer.example.com' > > kinit: Keytab contains no suitable keys for host/ > srspls3bwcof104.us.example....@amer.example.com while getting initial > credentials > > [root@SRSPLS3BWCOF104 etc]# grep sasl /etc/sssd/sssd.conf > > ldap_sasl_authid = srspls3bwcof104.us.example....@amer.example.com > > [root@SRSPLS3BWCOF104 etc]# kinit -k ' > srspls3bwcof104.us.example....@amer.example.com' > > kinit: Keytab contains no suitable keys for > srspls3bwcof104.us.example....@amer.example.com while getting initial > credentials > > [root@SRSPLS3BWCOF104 etc]# > > > > If we grab the very first entry out of /etc/krb5.keytab file, kinit -k > works. > > > > [root@SRSPLS3BWCOF104 etc]# klist -kte | head -4 > > Keytab name: FILE:/etc/krb5.keytab > > KVNO Timestamp Principal > > ---- ------------------- > ------------------------------------------------------ > > 28 02/09/2023 16:14:59 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM (arcfour-hmac) > > [root@SRSPLS3BWCOF104 etc]# kinit -k 'SRSPLS3BWCOF104$@AMER.EXAMPLE.COM' > > [root@SRSPLS3BWCOF104 etc]# klist -e | grep Etype > > renew until 03/09/2023 14:03:20, Etype (skey, tkt): > aes256-cts-hmac-sha1-96, > aes256-cts-hmac-sha1-96 > > > > This might be what ‘adcli testjoin’ is doing (grabbing first entry from > /etc/krb5.keytab as the service principal to use). But it’s surely not > what sssd is doing, as we explicitly set ldap_sasl_authid.
Hi, > > > I know sssd will prepend ‘host/’ to ldap_sasl_authid if it’s missing. But > I don’t think it does anything else if ldap_sasl_authid is explicitly > defined. SSSD does not add 'host/' it takes the value of ldap_sasl_authid as it is and checks if this principal can be found in the keytab. If not SSSD will try to pick to most suitable. With the AD provider this is not a 'host/fqdn@REALM' principal but 'SHORTNAME$@REALM' which is the default user principal name in AD. Similar with 'adcli testjoin', here as well not a random principal is picked from the keytab but 'SHORTNAME$@REALM'. AD is quite strict when it comes to requesting TGTs, you can only use 'SHORTNAME$@REALM' or the principal from userPrincipalName to request a TGT. And here is what is puzzling me ... > > > > What is sssd doing for us under the covers and how can we replicate this > with kinit -k to verify we don’t have rc4 encryption in use? > > > > BTW, here is how the server is known in AD: > > > > cn: SRSPLS3BWCOF104 > > distinguishedName: > CN=SRSPLS3BWCOF104,OU=Servers,OU=UNIX,DC=amer,DC=example,DC=com > > name: SRSPLS3BWCOF104 > > sAMAccountName: SRSPLS3BWCOF104$ > > dNSHostName: srspls3bwcof104.us.example.com > > userPrincipalName: host/srspls3bwcof104.us.example....@amer.example.com ... You have host/srspls3bwcof104.us.example....@amer.example.com defined as userPrincipalName, so I would expect that kinit -k 'host/srspls3bwcof104.us.example....@amer.example.com' should work. Maybe you can run it as KRB5_TRACE=/dev/stdout kinit -k 'host/srspls3bwcof104.us.example....@amer.example.com' to better understand which operation triggered the error. About disabling rc4 in general. If you are using 'permitted_enctypes' in /etc/krb5.conf and makes sure that 'arcfour-hmac-md5' (and other legacy encryption types) is not listed libkrb5 will not use it. This is how the crypto policies in RHEL-8 and newer and recent Fedora release are working. HTH bye, Sumit > > servicePrincipalName: RestrictedKrbHost/srspls3bwcof104.us.example.com > > servicePrincipalName: RestrictedKrbHost/SRSPLS3BWCOF104 > > servicePrincipalName: host/srspls3bwcof104.us.example.com > > servicePrincipalName: host/SRSPLS3BWCOF104 > > > > Spike > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
