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.
realm join -U abc123-admin OUR.DOMAIN.DUMMY
It seems to be successful
realm list OUR.DOMAIN.DUMMY
getent passwd firstname.lastname@example.org
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] [main] (0x0020): ldap_child_get_tgt_sync failed.
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
- (2022-11-19 14:12:27): [ldap_child] [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:
update-crypto-policies --set LEGACY
→ no change in behavior.
Am I missing something obvious?
(The jupyter service is running on a small cluster in Azure with AzureAD login and AD for uid-lookups and user verification)
It would help to know what “encryption type” it’s trying to use, e.g. on the old, and then on the new?
Yes, any ideas on how to get that? Increase loglevel, grepping logfiles?
This should list encryption(s) used for kerberos principals in the system keytab:
sudo klist -kte
Hello. This is, what I did to get it working:
/usr/bin/update-crypto-policies --set DEFAULT:AD-SUPPORT
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:
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] [sss_child_krb5_trace_cb] (0x4000):  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.
update-crypto-policy --set DEFAULT:AD-SUPPORT-LEGACY
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)
Red Hat Enterprise Linux and Microsoft security update of November 2022
Best regards and thanks for all the help,