Querying UserAccountControl Configurations
One of the checks we perform as part of our AD security assessments is looking for security principals that have certain security configurations. A number of these settings are stored as a bitwise value on both user and computer objects as part of the userAccountControl attribute. Full details of all the settings for this attribute are located in this MSDN article.
Some of the common values that most people recognise are:
- Password Never Expires (DONT_EXPIRE_PASSWD)
- User Cannot Change Password (PASSWD_CANT_CHANGE)
- Account is Disabled (ACCOUNTDISABLE)
From a security perspective the above values are all important, but as an AD admin, you should also be very interested in any accounts with the following flags:
- Password Not Required (PASSWD_NOTREQD)
- Account is Sensitive and Cannot be Delegated (NOT_DELEGATED)
- Account is Trusted For Kerberos Delegation (TRUSTED_FOR_DELEGATION)
- Account is Trusted for Kerberos Delegation with Protocol Transition (TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION)
I will definitely be talking about these in more detail in upcoming posts, but in the mean time, the script below can help you with your discovery of principals
Query UserAccountControl Script
Download here -> Query-UserAccountControl.ps1
The script will loop through each of the corresponding User Account Control flags, and create 2 ".csv" files for each of them. One will be for user accounts, prefixed with a "U-" and the other will be for computer accounts, prefixed with a "C-".
The output folder should resemble something like the following:
The script is pretty easy to execute, simple call it directly and optionally provide a server name. It will default to the localhost if a name is not provided.
.\Query-UserAccountControl.ps1 -Server "dc1.contoso.com"
Note: Some files will always be empty as their flags are not used. Account Lockout is such an example.
I hope this script is useful in your first steps to understanding any AD accounts that may be mis-configured and need to be remediated. Special care should of course be taken for those that are privileged from both Active Directory and your application perspectives.
Russ