PASSWORD_NOTREQD How is this possible on User objects!!
This is a fun one that some of my peers at Microsoft have covered in their blogs. I’ve been working to clean up Active Directory Objects in customer environments and noticed some behavior I didn’t know was possible or didn’t know how to duplicate. In this case when new users are being created they are being created with no password (pwdlastset=0), are enabled, and have a user account control value of PASSWORD_NOTREQD. This is what I found while going through this process and the steps I used to repro.
How do I create an account with this behavior?
Going to try new-aduser and net user /add
The new-aduser command worked but the account is disabled and the the password not required flag is not set.
I then ran across the switch for each command not to require the password and reran the commands with it.
Using the switch worked for both commands, here are the results?
Both objects are enabled and have the flag set. but test-user456 has a password set. I have no idea what that password is, the net user /add command seems to gives it one.
Note: if you open up an existing user property and set the flag for “User must change password at next logon” those users will be enabled and the pwdlastset will equal 0. However PASSWORD_NOTREQD does not get added.
Lets identify the scope of the problem.
- This script will get you a list of all User objects with pwdLastset to 0, LastlogonTimeStamp is Null, Account is Enabled and I added a column to show the msds-replattributemetadata which will give us a bunch of other important dates like the last time ntPwdHistory was changed. By default the code to disable these accounts has been commented out and a –whatif is added so that no changes are made. Make note in the report if the ActualLastPWD’s column matches the Whencreated column there is a good chance along with the other criteria these accounts have never been used and need to be disabled.
- This script gets all the users with the PASSWORD_NOTREQD useraccountcontrol set. These accounts could be enabled and actively used. The goal would be to find them and get rid of the flag, usually if an account doesn’t truly have a password it should error and requires a password prior to removing the flag.
Prevent this from happening.
This is actually an easy thing to fix. If you find that the accounts are being generated from an Identity Management Solution, work with them to prevent it from happening since the fix will more than likely break it.
This script will get all of the extended rights from the root of each domain in the forest. Run this first to see what is set.
After the the script is complete open in Excel and filter the extended rights to Update-Password-Not-Required-Bit
Expect the results to look like this. Now determine if you should deny this for all Authenticated Users, or just Deny it to a particular set of users or group like Domain Admins or Account Operators. For this blog I’m going to set a deny to my test account. Please test this prior to putting into a Production Forest!!!
Give it some time to replicate, Then try to repro creating a new account. I got Access Denied. I also tried creating an account with out the switches just to make sure I didn’t break anything (First time I tried this I set read deny rights on my account took me a while to recover).
Just like that its no longer possible to create accounts with PASSWORD_NOTREQD. Now that the day has been saved and PASSWORD_NOTREQD is a thing of the past, consider using the scripts used to identify objects and use them to clean up existing accounts.
That is all I have time for today I hope you find this as useful as I did.
Also consider using these other extender rights if needed.