We have Linux servers joined to an Active Directory forest through realmd, adcli, and SSSD. Some computer objects report PasswordNeverExpires = TRUE, but their PasswordLastSet values show recent changes—typically every 4–30 days—so machine credentials appear to be rotating normally.
Why is the ADS_UF_DONT_EXPIRE_PASSWD (0x10000) flag set on these computer objects? Older adcli versions reportedly set it by default, while newer versions made it optional through --dont-expire-password. However, some recently joined machines still have the flag, so our join automation may still be enabling it, or another process could be setting it.
Does the flag have any practical effect when SSSD is already renewing the machine password? My understanding is that Active Directory does not directly expire computer-account passwords; the age is mainly a hint used by the client's renewal logic. If so, clearing the flag should be functionally harmless and mainly address compliance reporting. Is there a situation where removing it could cause access problems?
For a large mixed Windows and Linux environment, should we bulk-clear the flag with Set-ADComputer, fix the join automation, or use adcli update to clear it during normal maintenance? We also want to avoid confusing SSSD's ad_maximum_machine_account_password_age setting, commonly 30 days, with winbind's machine password timeout setting, which often defaults to 7 days.
3 Answers
Do not assume that a changing PasswordLastSet value proves SSSD performed the rotation. That attribute can change after an SSSD renewal, an adcli update, a configuration-management job, or a rejoin. It also does not record which process made the change.
On an affected host, inspect the SSSD configuration and keytab, for example by searching for machine_account settings and checking the newest KVNO and timestamps in /etc/krb5.keytab. If ad_maximum_machine_account_password_age is set to 0, SSSD renewal is disabled. A regular change may instead be coming from scheduled automation.
This may be more of a reporting issue than an operational problem. Computer-account passwords are commonly marked as non-expiring in Active Directory, and adcli or realm join workflows may preserve that behavior for compatibility and safer recovery when a domain controller is temporarily unreachable. SSSD can still rotate the underlying machine password on its own schedule.
Before changing every object, audit the actual rotation status and consider reporting on accounts whose passwords have not changed within the expected interval. In many environments, leaving the flag alone is the least risky option unless a compliance requirement specifically mandates clearing it. Also check the join automation and installed adcli version, since an explicit --dont-expire-password option may still be present.
The practical approach is to fix the source first: inspect the versions and arguments used by your join scripts, Ansible, Puppet, and any scheduled adcli maintenance. Then validate rotation on a sample of systems before making a bulk change.
If policy requires PasswordNeverExpires to be false, clearing the bit should generally not stop an already functioning client from renewing its machine password, because the client controls that renewal behavior. Still, test it with representative SSSD and winbind configurations, retain a rollback plan, and monitor keytab KVNO changes and authentication after the update. Avoid changing the flag solely because PasswordLastSet looks healthy without first confirming what performs the rotation.
That distinction is important: the first step should be proving which client-side process is rotating the credential, rather than treating PasswordLastSet as an SSSD audit trail.