How to do an ‘adcli join’ (or re-join) without creating an msDS-supportedEncryptionTypes LDAP attribute in the machine account?

[Spike White]

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)