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.com(a)AMER.EXAMPLE.COM
<SRSPLS3BWCOF104.us.dell.com(a)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$(a)AMER.EXAMPLE.COM (arcfour-hmac)
28 02/09/2023 16:14:59 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
28 02/09/2023 16:14:59 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
28 02/09/2023 16:15:00 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
28 02/09/2023 16:15:00 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
28 02/09/2023 16:15:00 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
28 02/09/2023 16:15:00 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:22 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM (arcfour-hmac)
27 01/10/2023 06:14:22 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:22 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
27 01/10/2023 06:14:23 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
27 01/10/2023 06:14:23 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
27 01/10/2023 06:14:23 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
27 01/10/2023 06:14:23 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)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.com(a)AMER.EXAMPLE.COM' not
found in Kerberos database while getting initial credentials
[root@SRSPLS3BWCOF104 etc]# kinit -k 'host/
SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM'
kinit: Keytab contains no suitable keys for host/
SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM while getting initial
credentials
[root@SRSPLS3BWCOF104 etc]# grep sasl /etc/sssd/sssd.conf
ldap_sasl_authid = SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM
[root@SRSPLS3BWCOF104 etc]# kinit -k '
SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM'
kinit: Keytab contains no suitable keys for
SRSPLS3BWCOF104.us.example.com(a)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$(a)AMER.EXAMPLE.COM (arcfour-hmac)
[root@SRSPLS3BWCOF104 etc]# kinit -k 'SRSPLS3BWCOF104$(a)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.
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.com(a)AMER.EXAMPLE.COM
... You have host/srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM
defined as userPrincipalName, so I would expect that
kinit -k 'host/srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM'
should work. Maybe you can run it as
KRB5_TRACE=/dev/stdout kinit -k
'host/srspls3bwcof104.us.example.com(a)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