An Active Directory health assessment is flagging about 40 Linux and Unix computer accounts with PasswordNeverExpires=True, meaning the userAccountControl bit 65536 is set. The environment includes RHEL 7/8/9, Ubuntu, legacy CentOS, and NetApp/QNAP appliances joined through a mixture of realm/adcli with SSSD, Samba/winbind, and older Centrify deployments. Several accounts have PasswordLastSet values more than five years old, even though the systems still authenticate users through Kerberos. Some SSSD configurations explicitly set ad_maximum_machine_account_password_age = 0, while others do not define the setting. Was the flag set automatically by a join method such as realm join, adcli, or net ads join, or was it probably added manually in the past? If I clear it on a host whose machine-password rotation is disabled, will anything immediately break, or does the client need to initiate a password change before there is an impact? What is the recommended approach today: enable SSSD rotation with an age such as 30 days, schedule adcli updates, or document non-rotating legacy and appliance accounts as exceptions?
3 Answers
Clearing PasswordNeverExpires usually does not disable a Linux host immediately. AD does not normally reach out and terminate the machine account simply because the stored password is old; the client and its authentication software are involved in the password-change process. However, a non-rotating account can eventually become a problem under domain policy or after a trust-related operation, so treating the change as purely cosmetic is risky. Test it first on a noncritical host and watch for Kerberos or secure-channel errors.
A sensible long-term policy is to standardize new Linux joins on SSSD with machine-password rotation enabled and a defined maximum age, such as 30 or 60 days. Then inventory older winbind, Centrify, and appliance-based joins separately. Fix rotation where the platform supports it, clear the exception flag after testing, and maintain a documented exception list for devices that cannot rotate. Do not rely on the health report alone; confirm that PasswordLastSet changes and that the client can obtain and use its updated credentials.
The flag is often historical rather than something deliberately required by modern Linux join tools. Older winbind, Centrify, or custom join scripts may have set it to avoid trust-account problems. Modern SSSD-based deployments can generally rotate the machine password automatically, but the exact behavior depends on the join method and configuration. Compare several hosts and monitor PasswordLastSet in AD over a week or two; that will show whether rotation is really happening.
Legacy systems are where the inconsistency usually comes from. Newer SSSD hosts may rotate normally while older machines have had the flag set for years and never changed their password.
A canary test is a good way to separate the health-check warning from a real dependency. Unset the flag on one host, leave it through a complete password-age interval, and verify both user authentication and machine-account operations.