Why would a computer object ever exist without a password requirement in an Active Directory domain? The basic answer is for legacy support, but the real answer is one of two scenarios:

  • No enforced standard

  • No monitoring

A recent penetration test showed that my environment had several computer objects with the "password not required" flag in its calculated userAccountControl attribute value. The default value for userAccountControl is 4096 which only uses the flag WORKSTATION_TRUST_ACCOUNT. This value means that the computer has successfully joined the domain and will continue to use this computer object during authentication.

More details about userAccountControl

When a computer object is configured with no password requirement the decimal value 32 (PASSWD_NOTREQD) is added to the userAccountControl cumulative value. If no other flags are configured, the resulting value is 4128, instead of the default 4096.

Once we know what to look for it makes finding them rather trivial with the proper LDAP queries. If you explicitly want to find computer objects with the userAccountControl value of 4128, use:

If instead you want to find any computer object whose userAccountControl value includes the "password not required" flag regardless of other flags, use:

Remediate these computer objects by resetting the value to 4096. If other required flags are present, reduce the existing value by 32. If you are using hexadecimal, you have to do your own math for that.

We now know how to fix it, but how did this happen in the first place?

For my environment, most of the computer objects with the "no password required" flag were created several years ago as confirmed by their whenCreated timestamp. Most likely, these computer objects were manually created with the "Assign this computer account as a pre-Windows 2000 computer" box checked.

That option might have made sense 20+ years ago to support legacy or non-Windows operating systems, but not today. Modern, secure environments require computer objects to regularly update their own computer passwords.

The good news is that on the computer objects configured without a password requirement, I also found that their pwdLastSet value contained a timestamp. This indicates that although the computer could go without a password, the pwdLastSet timestamp tells me that it used a password anyway. Whew! Not ideal, but at least the PW was not <NULL>.

I verified with the teams responsible for workstation and server provisioning that they were not using this non-secure flag. I encouraged them to update their documentation to include an explanation why not to use this configuration.

Going back to my original bullet list of reasoning, I addressed the enforced standard with my communication with the provisioning teams. By incorporating the aforementioned LDAP queries into my periodic security checks, I will have some level of monitoring going forward.

While it was embarrassing to find computer objects configured this way, it reinforced an important lesson: Unless we have controls to prevent insecure configurations, they will happen.