Kerberos targets in Active Directory should negotiate with their KDC to use the strongest mutually supported encryption type for their shared key. (This is not normally required in an MIT realm, where the keytab administratively configured and provided to the target).
Samba does this, setting msDS-SupportedEncryptionType at join time. However it is not updated later, so if the join was done over RPC we would still be sent arcfour-hmac-md5 keys.
Samba's winbindd should confirm the current set value for msDS-SupportedEncryptionType using NETLOGON GetDomainInfo and to contact the KDC using LDAP and update the msDS-SupportedEncryptionType if this isn't the strongest common type.
RFC 8429 encourages moving away from arcfour-hmac-md5 (and the DES encryption types), so there is good precedent for making this move.
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master-exchange has some code for winbindd to call netlogon_creds_cli_LogonGetDomainInfo(), but the tricky part is that
the netr_OsVersionInfoEx stuff right, as at least for the AD DC it's important
for the exchange installer...
Any automated updates should probably follow whatever values are being pushed out via group policy and consider that some of the other bits here may have been set manually (Resource-SID-compression-disabled for example).
We support resource group compression as acceptor therefor it's not critical to keep any Resource-SID-compression-disabled bit.
It's also need really critical to monitor the "msDS-SupportedEncryptionType",
because net ads join includes aes-256 and aes-128, which means strong session
keys are also supported.
In very old joins msDS-SupportedEncryptionType is missing and
we'll get aes-256-sk implied from the kdc.
Otherwise admins can use "net ads enctypes set 'COMPUTERACCOUNT$'"
in order to set it to the (good) default.
So this is not as as urgent as the other related bugs