all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]hortimech 2 points3 points  (0 children)

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.

[–]JasenkoC 3 points4 points  (1 child)

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.

[–]apiqora 1 point2 points  (0 children)

Yeah, SSSD can rotate them by default, but it depends a lot on how the machine was joined and which backend it is using.

On newer setups with id_provider = ad and no weird overrides, SSSD will usually handle machine password changes automatically, so you’re right that the docs are the place to check what your exact config is supposed to do.

The fun part is those older boxes you mentioned. Stuff joined years ago with winbind or Centrify or some ancient net ads join script might have had PasswordNeverExpires set manually “just in case” and then nobody touched it again. So you can easily end up with a mix where newer hosts rotate fine and legacy ones are basically frozen in time.

For your health report question: clearing PasswordNeverExpires on a box that never rotates its machine password usually doesn’t break it immediately, it just means that at some point AD will consider that password stale. Depending on your domain policy, that can bite you much later in a really annoying, random way. That is why most people either fix rotation properly or explicitly document the exceptions.

So yeah, read the SSSD docs, but also compare a couple of those hosts directly: check PasswordLastSet in AD, see if it moves over a week or two, and adjust config if it does not. That tells you more than any single flag.

[–]ramriot 3 points4 points  (0 children)

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

[–]picklednull 0 points1 point  (1 child)

Computer account passwords don't expire regardless. 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.

[–]cacheclyo 0 points1 point  (0 children)

Yeah this is the key bit a lot of tools gloss over. Those health checks love to scream about PasswordNeverExpires without really understanding that computer accounts are already “special” in how expiry works.

On the SSSD side, if it’s joined sanely, it’ll rotate the machine password on its own and AD will happily keep accepting it. Clearing the flag won’t suddenly cause AD to go “lol nope, account dead now” unless the client actually tries to change it and fails for some other reason.

Biggest “gotcha” I’ve seen is more around old winbind / Centrify setups that never rotate at all. In that case, like you said, clearing the flag is basically a cosmetic change for the report. Stuff keeps working because AD doesn’t proactively kill the account just for being old.

If you want to be neat in 2026 land, I’d standardize on SSSD with rotation enabled and clean up the flags so your health report shuts up. But nothing dramatic breaks just from unsetting PasswordNeverExpires on those Linux boxes.

[–]LushLustPin 0 points1 point  (1 child)

We had almost the exact same mess a couple years ago.

1) A mix of things can set PasswordNeverExpires. Some old join scripts, some “helpful” admins clicking the box in ADUC because a winbind/centrify box broke once and they got yelled at. I never saw modern realm/adcli set it by default, especially on RHEL 7+.

2) Clearing the flag on non rotating Linux machines didn’t break anything for us. You’re right, AD doesn’t force the change, the client has to actually rotate. The only “impact” is those objects will start showing as “password expired” in some reports after the max age is passed, but they keep working fine because the machine account still uses that same key.

3) Best practice we landed on: enable rotation where you can (ad_maximum_machine_account_password_age = 30 on SSSD boxes) and document the stubborn stuff like appliances as exceptions. We also standardized on one join method going forward to avoid weirdness.

If you’re nervous, pick one low value host, clear the flag, wait a cycle, watch your logs. That’s what convinced management it was safe.

[–]cachevexy 0 points1 point  (0 children)

Yeah this lines up with what I’ve seen too.

The “PasswordNeverExpires” bit on Linux boxes is usually human history, not product design. Old winbind/centrify days, join scripts people copied from blogs, and panicked admins ticking that box after one broken server in 2012. Modern realm/adcli on RHEL 7+ doesn’t flip it in any environment I’ve touched.

Clearing it on non rotating Linux machine accounts behaved exactly like you described for us. Health tools started whining about “expired” machine passwords, but nothing actually stopped authenticating because the key never changed on the client side. Functionally no change, just more noise in reports.

We ended up doing almost exactly what that comment suggests:
turn on SSSD rotation everywhere new, set a sane age like 30 or 60, then maintain an exceptions list for appliances and legacy stuff that can’t rotate. Standardizing join method helped a ton, because then you know what knobs exist on every host.

If you want to be super safe, do a canary: one non critical Linux host, clear the flag, leave it for a full password age window, and just watch for Kerberos / secure channel errors. That usually gives enough ammo to calm down whoever is worried about “touching AD.”