We have Linux servers joined to an Active Directory forest with SSSD and realmd. Many computer objects report PasswordNeverExpires = TRUE, yet their PasswordLastSet values show changes every few days to roughly monthly, suggesting that machine credentials are being rotated.
Why is the ADS_UF_DONT_EXPIRE_PASSWD (0x10000) bit set on these Linux computer objects? Older versions of adcli reportedly enabled it by default, while newer versions made it optional, so we are trying to determine whether our join automation still passes --dont-expire-password or whether another component sets the flag.
Does the flag have any practical effect when SSSD is already renewing the machine password? My understanding is that Active Directory does not actively reject a computer account because its password age exceeds the normal interval; the age is mainly used by the client to decide when to rotate. If that is correct, clearing the flag should mostly satisfy compliance reporting without changing operation, provided rotation continues.
For a large mixed Windows and Linux environment, should we bulk-clear the bit, correct the join automation, or use adcli update to change it? Before making changes, what is the safest way to confirm that SSSD—not a scheduled task, configuration-management job, or rejoin—is responsible for the PasswordLastSet changes? I am also interested in any interaction between SSSD's ad_maximum_machine_account_password_age and winbind's machine password timeout settings.
3 Answers
Do not assume that PasswordLastSet proves SSSD performed the rotation. That attribute changes when anything updates the machine password, including adcli, a scheduled configuration-management task, or a rejoin. A spread of four to thirty days could easily reflect automation schedules.
On an affected host, inspect the SSSD configuration and drop-ins for machine-account settings, for example with grep against /etc/sssd/sssd.conf and /etc/sssd/conf.d/. Also inspect the Kerberos keytab with klist -ket and check the newest key version and timestamp. If ad_maximum_machine_account_password_age is set to 0, SSSD renewal is disabled, so another process must be responsible for the changing PasswordLastSet value.
The practical approach is to correct the source and validate before making a bulk change. Audit Ansible, Puppet, join scripts, and image-building steps for --dont-expire-password, and confirm which adcli version is installed. Then verify rotation on a representative sample by comparing keytab KVNO/timestamps with directory PasswordLastSet values.
If policy requires the flag to be cleared, Set-ADComputer -PasswordNeverExpires $false can be used carefully against a scoped set of computer objects, preferably after an export and with exclusions for systems managed by other tooling. Clearing it should not stop SSSD from rotating credentials, but it also does not create a rotation mechanism. Keep the client-side renewal configuration and monitoring in place, and do not mix SSSD and winbind timeout assumptions without checking which component actually manages each host.
This may be more of a reporting issue than an operational failure. Active Directory commonly leaves computer-account passwords marked as non-expiring, and older adcli/realm-join behavior treated that as the safer default. If a domain controller is unreachable during a renewal, forcing an expiry policy can create an avoidable authentication outage.
Unless a compliance requirement specifically demands the bit be cleared, I would first monitor actual machine-account rotations and identify accounts that have stopped changing. Fixing the join process for new machines is still worthwhile, but bulk-changing every existing computer object should be treated as a policy decision rather than an automatic repair.
That is the part I want to settle first: why does the Linux computer object appear as “Password Never Expires” in Active Directory if something on the host is still changing its machine password?