Hi, I’ve started looking into migrating a jupyterhub service from Rocky 8 to Rocky 9 and found that the AD integration fails. I’m using the exact same config as in Rocky 8 (ansible playbook) and the realm join is successful, but user lookups fail on Rocky 9.
Joining with
realm join -U abc123-admin OUR.DOMAIN.DUMMY
It seems to be successful
realm list OUR.DOMAIN.DUMMY
our.domain.dummy
type: kerberos
realm-name: OUR.DOMAIN.DUMMY
domain-name: our.domain.dummy
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U@our.domain.dummy
login-policy: allow-realm-logins
Testing with
getent passwd abc123@our.domain.dummy
does not yield any result and /var/log/sssd/ldap_child.log contains a lot of these
(2022-11-19 14:12:27): [ldap_child[3440]] [main] (0x0020): ldap_child_get_tgt_sync failed.
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
(2022-11-19 14:12:27): [ldap_child[3440]] [ldap_child_get_tgt_sync] (0x0010): Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: KDC has no support for encryption type. Unable to create GSSAPI-encrypted LDAP connection.
Everything works ok on my prod cluster running Rocky 8.7. On my prod system /var/log/sssd/ldap_child.log is empty.
Troubleshooting so far:
realm leave
update-crypto-policies --set LEGACY
reboot
realm join
→ no change in behavior.
Any thoughts?
Am I missing something obvious?
Best regards
Roy
(The jupyter service is running on a small cluster in Azure with AzureAD login and AD for uid-lookups and user verification)
I experienced this same problem on my organization’s domain. In our case, it was due to a system update on the domain controllers and was fixed with another update – no configuration changes were needed on the RL 8.x/9.x systems.
I’m not a domain admin and was not involved with the fix, but I believe this is the relevant link:
With debug_level=10 set in the SSSD config file, /var/log/sssd/ldap_child.log gave details on the encryption types:
(2022-11-16 12:42:03): [ldap_child[10116]] [sss_child_krb5_trace_cb] (0x4000): [10116] 1668624123.409082: Looked up etypes in keytab: aes128-cts, aes256-cts
These matched the types encoded for in msDS-SupportedEncryptionTypes attribute of the affected computer objects in AD (0x18) and our systems were using the default crypto policies.
The original update(s) that caused the problem were in response to CVE-2022-37966 and CVE-2022-37967. One of the updates was intended to disable RC4, but it ended up breaking things that only supported AES.
Hi, and thanks for all the help. You put me on the right track! It is indeed an issue with support for older encryption types. The solution for me was to set crypto policy to AD-SUPPORT-LEGACY and rejoining the domain.
Redhat has a published a piece where I found the solution. (Well, the real solution is for MS to fix the bug in AD so we do not need to support arcfour-hmac)