Partager via


Do You Allow Blank Passwords In Your Domain?

Do you or did you back in the days use your own code or a third party tool to create user accounts that did not update the userAccountControl attribute after the account was created?

Well then there's a change you might have accounts in your domain that are allowed blank passwords or even worse have accounts with blank passwords!

Why?

Because user objects are allowed using blank passwords by default when created, something that must be handled afterwards. Unless that's in line with your security policy ;)

This is the default setting of userAccountControl on user objects at creation:

userAccountControl: 0x222 = (ACCOUNTDISABLE | PASSWD_NOTREQD | NORMAL_ACCOUNT);

How does this setting affect my environment?

Q: We have a password policy in our domain that does not allow blank passwords, are we protected from blank passwords?

A: No, this setting overrides the password policy in the domain or your fine grained password policy when you do reset password operations.

So when is the "blank password" setting on user accounts effective:

When users are delegated the permissions to do password resets on user accounts with ADS_UF_PASSWD_NOTREQD, they can set a blank password.

A normal change password procedure by a user do not follow the ADS_UF_PASSWD_NOTREQD, it will follow the password policy in your domain or fine grained password policy if you got defined for the user.

So let say that an user with the delegate right to do password reset accidentally press OK in the password reset dialog box without the "User must change password at next logon" or someone in your organization with permissions to create user objects accidentally runs a script that sets blank password.  Then you will have accounts in you domain with no password.

How do I find accounts with ADS_UF_PASSWD_NOTREQD?

How will I know if any of the accounts in my domain have "password not required" set?

The easiest way to do it is to do a search with ADUC (Active Directory Users and Computers) mmc snap-in:

  1. Right click the domain root.
  2. Select Find... .
  3. In the Find: drop down box select Custom Search.
  4. Click the Advanced tab.
  5. In the Enter LDAP Query: field type: (&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32)) .
  6. Click Find Now.

This will give you all accounts in the select domain that does not requires a password.

What are NETBIOSNAME$ accounts?

Some accounts should have this value so you might expect to find user accounts called  "Trust Short Domain Name"$ . ie. CORP$ or CHILDDOMAIN$.

These are trust accounts, located in the Users (CN=Users, + Domain DN) container, named after the NETBIOS domain name of the domain you share a trust with plus a dollar sign ($).

Leave these accounts alone, if you try to change the userAccountControl value alone for these accounts you will get Access Denied!

Here can you read about the trust account (TDO Passwords):

How Domain and Forest Trusts Work

https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx

 

How to create users?

To create users without allowing blank passwords you must deal with the userAccountContol values:

When a new user account is created,the userAccountControl attribute for the account automatically has the UF_PASSWD_NOTREQD flag set,
which indicates that no password is required for the account. If the security policies of the domain that the account is created in requires a password for
all user accounts, then the UF_PASSWD_NOTREQD flag must be removed from the userAccountControl attribute for the account.

Here you can read on how to create user accounts:

Creating a user (Windows)

PASSWD_NOTREQD flag:

Binary Decimal C# Constant VB Constant VB Script Constant
00000000000000000000000000100000 32 0x0020 &H20 32 ADS_UF_PASSWD_NOTREQD

This Vbscript code example will create a user with ADS_UF_PASSWD_NOTREQD. The user will be allowed using blank passwords.

Set objOU = GetObject(LDAP://ou=sales,dc=contoso,dc=com)
Set objUser = objOU.Create("User","cn=jsmith")
objUser.Put "sAMAccountName","jsmith"
objUser.Put "givenName","james"
objUser.SetInfo
objUser.put "userPrincipalName",objUser.sAMAccountName & "@contoso.com"
objUser.AccountDisabled = False
strPassword = "P@ssW0rdPh@rse"
objUser.SetPassword strPassword
objUser.SetInfo

This Vbscript code example manage the userAccountControl attribute. It removes both the disabled state and "password not required" setting:

Set objOU = GetObject("LDAP://ou=sales,dc=contoso,dc=com")
Set objUser = objOU.Create("User","cn=jsmith")
objUser.Put "sAMAccountName","jsmith"
objUser.Put "givenName","james"
objUser.SetInfo
objUser.put "userPrincipalName",objUser.sAMAccountName & "@contoso.com"
Const ADS_UF_ACCOUNT_DISABLE = 2
Const ADS_UF_PASSWD_NOTREQD = 32
intUAc = objUser.Get ("userAccountControl")
objUser.put "userAccountControl", intUAc And (Not ADS_UF_PASSWD_NOTREQD) And (Not ADS_UF_ACCOUNT_DISABLE)
strPassword = "P@ssW0rdPh@rse"
objUser.SetPassword strPassword
objUser.SetInfo

How do I know if I got blank passwords and how do I deal with it?

Well, you can run a script to test every account against a blank password or why not find users with passwords that don't comply with the password policy and remove the user setting for other users at the same time? :)

There's a code-sample (RemoveUserPASSWD_NOTREQD.ps1) attached below that remove the ADS_UF_PASSWD_NOTREQD flag and If a user has a blank password the script will fail and report an error stating it does not follow the password policy for the domain, as long as you have a password policy in the domain that requires minimum length above zero characters.

If the script succeeds to remove the ADS_UF_PASSWD_NOTREQD flag  it will also report the status of the account, since if the account is also disabled it still could have a blank password. Something you will get aware of when you try to enable it.

If you try to enable an account that has no password you will get this:

You could test your environment with this code-sample and review the output.

Here is an example of output:

.\RemoveUserPASSWD_NOTREQD.ps1 -server DC1 -path "ou=account,dc=contoso,dc=com" -subtree -logfile c:\MyLoqFile.txt

User02 ;Failed; The password does not meet the length, complexity, or history requirement of the domain.

User07; Success; Status: ADS_UF_NORMAL_ACCOUNT 

This PowerShell script requires Active Directory Module for Windows PowerShell.

What happens when I remove the ADS_UF_PASSWD_NOTREQD flag?

The afftect account can not get blank password at the next password reset, unless the password policy in the domain or fine grained password policy allow it!

 

Hopefully you do not have accounts with ADS_UF_PASSWD_NOTREQD.

You could still have accounts with blank passwords in case you had a domain password policy with no minimum password length.

To fix this you have to :

  • make sure your password policies are in line with your security policy
  • verify that users are required to change their passwords
  • verify that users don´t have "Password never expires" ticked in.

Go and verify!https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/telligent.evolution.components.attachments/01/9414/00/00/03/54/00/11/RemoveUserPASSWD_NOTREQD.ps1.txt

Updated script 2017-08-29

RemoveUserPASSWD_NOTREQD.ps1

Comments

  • Anonymous
    January 01, 2003
    Nice write-up Robin.

  • Anonymous
    January 01, 2003
    Hi Michael, Tried it my self and it seems to work. If you like I could mail you the script.

  • Anonymous
    January 01, 2003
    Thank you Santosh!

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    May 02, 2013
    Thanks Robin, It is very useful for me... Much appreciated

  • Anonymous
    May 09, 2013
    Thanks for this.  When downloading the script sample it appears to be a blank txt file.  Could you please republish the ps script?

  • Anonymous
    June 07, 2013
    Hi Robin, Seems to be working fine now. Many Thanks

  • Anonymous
    January 29, 2014
    Very nice writeup, Robin. This was exactly what I needed to know.Many thanks

  • Anonymous
    April 01, 2014
    Thank you so much! This is still relevant and worked like a charm!