Sssd experts,
Our AD team is in the process of eradicating deprecated arcfour-hmac encryption type from AD. (It’s a long road).
Our strong preference on the machine accounts is to not even have an msDS-supportedEncryptionTypes LDAP attribute associated with it. In that way, the machine account takes on the AD domain’s default.
Windows servers do this when they AD join. Their machine accounts don’t have an explicit msDS-supportedEncryptionTypes LDAP attribute. Only our Linux machine accounts have an explicit msDS-supportedEncryptionTypes LDAP attribute. (Our Linux machines AD integrate via sssd, using adcli join to join the domain).
Right now, the AD domain default is aes256/aes128/rc4, but when all rc4 traffic is eradicated they’ll change the domain default to aes256/aes128 only.
We would prefer to not have to circle around and clean up all the explicit msDS-supportedEncryptionTypes LDAP attributes associated with all the Linux machine accounts. To that end, weeks ago one of the AD engineers removed all msDS-supportedEncryptionTypes LDAP attributes from all our Linux machine accounts.
But just today, we noticed that some have come back. And we can’t even figure out a pattern. Some have aes256/aes128/rc4 and some have aes256/aes128 only.
It appears that new builds are setting an explicit msDS-supportedEncryptionTypes LDAP attribute. If we re-join (via adcli join), is it then setting an explicit msDS-supportedEncryptionTypes LDAP attribute?
(When sssd drops off the domain, our Linux support engineers often just re-join the server to the domain via a script that does ‘adcli join’.)
I looked at the adcli man page. It has flags for setting random LDAP attributes, but doesn’t take explicitly about msDS-supportedEncryptionTypes LDAP attribute.
Seeking enlightenment,
Spike White
(Happy sssd customer)