ActiveDirectory integration problem in Rocky9

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

  • (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
realm join
→ no change in behavior.

Any thoughts?
Am I missing something obvious?

Best regards
(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

1 Like

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.

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,