none
Changing UserAccountControl Attribute To Require Password Change

    Question

  • I was looking for stale computer accounts within our domain using the PasswordLastSet date when I discovered hundreds of computer objects with the useraccountcontrol value of 4128 (WORKSTATION_TRUST_ACCOUNT and PASSWD_NOTREQD)  instead of the usual 4096 (WORKSTATION_TRUST_ACCOUNT) value.

    Most of these computers were part of a migration from another domain but many were created recently.

    I would like to require all computers maintain a secure password with the domain so I could discover stale computer objects. I created a script which could make that change but I am unsure of any negative consequences that might result.

    Have you had experience changing this useraccountcontrol value? What would you advise?

    Thanks!


    Thursday, January 5, 2017 9:50 PM

All replies

  • The worst that can happen is that the computers must change their passwords the next time they restart. This could result in a lot of replication traffic if they restart at once. But I would check the pwdLastSet attribute on the "Attribute" editor of ADUC. I have a few computer objects with the same setting (I don't remember why), but they still have changed their password within the last 30 days. Or, you can use Get-ADComuter:

    Get-ADComputer -LDAPFilter "(userAccountControl=4128)" -Properties PasswordLastSet, LastLogonDate | Select sAMAccountName, PasswordLastSet, LastLogonDate

    It appears that even though a password is not required, they still request a new password every 30 days or so.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Thursday, January 5, 2017 11:01 PM
  • https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, January 5, 2017 11:59 PM
  • https://blogs.technet.microsoft.com/askds/2013/01/07/intermittent-mail-sack-must-remember-to-write-2013-edition/#_Question_3

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, January 6, 2017 12:00 AM