Linux/Unix domain-joined computer objects with PasswordNeverExpires=True — expected behavior or should I remediate?

Posted by maxcoder88@reddit | linuxadmin | View on Reddit | 4 comments

Running an AD Health Assessment on our Windows 2019 forest and it flags

\~40 Linux/Unix computer accounts as `PasswordNeverExpires=True`

(userAccountControl bit 65536 set). Before I blindly clear the flag, I want

to understand what's actually going on.

**Environment:**

- Mixed Linux estate: RHEL 7/8/9, Ubuntu, some legacy CentOS, plus NetApp/QNAP appliances

- Join methods vary: `realm join` (SSSD), Samba/Winbind, some old Centrify leftovers

- Some boxes have `PasswordLastSet` going back 5+ years but are actively authenticating users via Kerberos

- SSSD configs I've checked either have `ad_maximum_machine_account_password_age = 0` or the parameter is missing entirely

**Questions:**

Is `PasswordNeverExpires=True` actively *set* by the Linux join tooling,

or did sysadmins set it manually years ago to prevent breakage? Does

`realm join` / `adcli` / `net ads join` set bit 65536 by default?

If I clear the flag on a Linux box where SSSD rotation is disabled,

does anything actually break? My understanding is the GPO doesn't actively

expire passwords — the *client* initiates the change. So clearing the flag

on a non-rotating box should be functionally a no-op while making the

health report happy. Am I missing something?

What's actual best practice in 2026 for Linux machine password rotation?

Enable `ad_maximum_machine_account_password_age = 30` everywhere? Cron

`adcli update`? Or just accept Linux passwords don't rotate and document

the exception?

Looking for war stories from anyone running mixed Windows/Linux AD at scale.

Bonus if you've tested what happens when clearing the flag on a non-rotating box.

[-]

picklednull@reddit

Computer account passwords don't expire. And at least SSSD is able to rotate them on its own.

So you can just remove the flag.

What you want to do regarding the password changes is up to you. The computer accounts just have the standard read access to AD that every account by default has, they're practically irrelevant.

I cannot speak for the other methods, but 'net ads join' sets the userAccountControl attribute to 4096, the workstation trust account and the machine password should rotate every 30 days. However, a computer, in AD, is just a user with an additional objectclass and it sounds like someone in the past set yours to never expire. Having never been in this position, I do not know what will happen if you reset a computers userAccountControl attribute, it may just get its password rotated, or it may fall over, who knows ? Why not try it with a computer you want to get rid of. SSSD probably works similarly to winbind, it is after all just a wrapper around winbind.

ramriot@reddit

Wow, looks like there is up to speed with current NIST advisories.

JasenkoC@reddit

If I remember correctly SSSD should be able to keep the computer credentials rotated by default. Read into the SSSD documentation about it, and you'll figure it out.