userAccountControl, Attributes for AD Users

I needed this today for use in querying a large AD.

Repost. Credits go to


you can query with this e.g. with powershell and do some counting:

(Get-ADUser -LDAPFilter “(&(sAMAccountName=*)(!userAccountControl:1.2.840.113556.1.4.803:=2))” -SearchBase ‘OU=Users,DC=domain,DC=local’ ).Count

But could also check if password has been set to never expire, etc.

Attributes for AD Users : userAccountControl

The Active Directory attribute userAccountControl contains a range of flags which define some important basic properties of a user object. These flags can also be used to request or change the status of an account.



LDAP name userAccountControl
Data type Integer (DWORD – 4 Bytes)
Multivalue (Array) No
System Flags 0x12
Search Flags 0x19
In Global Catalog? Yes
Attribute ID 1.2.840.113556.1.4.8
AD DB attribute name User-Account-Control
ADSI datatype 7 – Integer
LDAP syntax – Integer
Used in … > W2K
Schema Info Microsoft – MSDN


In addition to the mere attribute specification in the schema docu, there are two important websites which explain the meaning of the different userAccountControl flags:

MSDN: Open Specifications – [MS-ADTS] – 2.2.15 – userAccountControl Bits

MSDN: Open Specifications – [MS-SAMR] – – userAccountControl

Here are the single flags, you find some annotations afterwards:


Flag value (binary) (decimal)
0000000000000000000000000000000x 1  Reserved, the value must always be 0
00000000000000000000000000000010 2  UF_ACCOUNT_DISABLE
00000000000000000000000000000×00 4   Reserved, the value must always be 0
00000000000000000000000000001000 8  UF_HOMEDIR_REQUIRED
00000000000000000000000000010000 16  UF_LOCKOUT
00000000000000000000000000100000 32  UF_PASSWD_NOTREQD
00000000000000000000000001000000 64  UF_PASSWD_CANT_CHANGE
00000000000000000000000010000000 128  UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED
00000000000000000000000×00000000 256  Reserved, the value must always be 0
00000000000000000000001000000000 512  UF_NORMAL_ACCOUNT
000000000000000000000×0000000000 1024  Reserved, the value must always be 0
00000000000000000000100000000000 2048  UF_INTERDOMAIN_TRUST_ACCOUNT
00000000000000000001000000000000 4096  UF_WORKSTATION_TRUST_ACCOUNT
00000000000000000010000000000000 8192 UF_SERVER_TRUST_ACCOUNT
00000000000000000×00000000000000 16384  Reserved, the value must always be 0
0000000000000000×000000000000000 32768  Reserved, the value must always be 0
00000000000000010000000000000000 65536  UF_DONT_EXPIRE_PASSWD
00000000000000100000000000000000 131072  UF_MNS_LOGON_ACCOUNT
00000000000001000000000000000000 262144  UF_SMARTCARD_REQUIRED
00000000000010000000000000000000 524288  UF_TRUSTED_FOR_DELEGATION
00000000000100000000000000000000 1048576  UF_NOT_DELEGATED
00000000001000000000000000000000 2097152  UF_USE_DES_KEY_ONLY
00000000010000000000000000000000 4194304  UF_DONT_REQUIRE_PREAUTH
00000000100000000000000000000000 8388608  UF_PASSWORD_EXPIRED
00000001000000000000000000000000 16777216  UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION
00000010000000000000000000000000 33554432  UF_NO_AUTH_DATA_REQUIRED
00000100000000000000000000000000 67108864  UF_PARTIAL_SECRETS_ACCOUNT
0000×000000000000000000000000000 134217728  Reserved, the value must always be 0
000×0000000000000000000000000000 268435456  Reserved, the value must always be 0
00×00000000000000000000000000000 536870912  Reserved, the value must always be 0
0x000000000000000000000000000000 1073741824  Reserved, the value must always be 0
x0000000000000000000000000000000 2147483648  Reserved, the value must always be 0


If there are several flags set for a certain account, you just have to add the decimal values of these flags to get the according value of the userAccountControl attribute. Some Examples:


Normal User Account
00000000000000000000001000000000 512  UF_NORMAL_ACCOUNT
Total  512



Disabled User
00000000000000000000000000000010 2  UF_ACCOUNT_DISABLE
00000000000000000000001000000000 512  UF_NORMAL_ACCOUNT
Total  514



User whose password never expires
00000000000000000000001000000000 512  UF_NORMAL_ACCOUNT
00000000000000010000000000000000 65536 UF_DONT_EXPIRE_PASSWD
Total  66048


To set or erase bits in the userAccountControl attribute, this is what you could do:


Const ADS_UF_ACCOUNT_DISABLE = 2 Const ADS_UF_HOMEDIR_REQUIRED = 8 Const ADS_UF_LOCKOUT = 16 Const ADS_UF_PASSWD_NOTREQD = 32 Const ADS_UF_PASSWD_CANT_CHANGE = 64 Const ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED = 128 Const ADS_UF_NORMAL_ACCOUNT = 512 Const ADS_UF_INTERDOMAIN_TRUST_ACCOUNT = 2048 Const ADS_UF_WORKSTATION_TRUST_ACCOUNT = 4096 Const ADS_UF_SERVER_TRUST_ACCOUNT = 8192 Const ADS_UF_DONT_EXPIRE_PASSWD = 65536 Const ADS_UF_MNS_LOGON_ACCOUNT = 131072 Const ADS_UF_SMARTCARD_REQUIRED = 262144 Const ADS_UF_TRUSTED_FOR_DELEGATION = 524288 Const ADS_UF_NOT_DELEGATED = 1048576 Const ADS_UF_USE_DES_KEY_ONLY = 2097152 Const ADS_UF_DONT_REQUIRE_PREAUTH = 4194304 Const ADS_UF_PASSWORD_EXPIRED = 8388608 Const ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION = 16777216 Const ADS_UF_NO_AUTH_DATA_REQUIRED = 33554432 Const ADS_UF_PARTIAL_SECRETS_ACCOUNT = 67108864 Set obj = GetObject(“LDAP://cn=philipp,ou=user,dc=cerrotorre,dc=de”) ‘The user is disabled (set flag bit): obj.userAccountControl = obj.userAccountControl or ADS_UF_ACCOUNT_DISABLE obj.SetInfo ‘The user is enabled (remove flag bit): obj.userAccountControl = obj.userAccountControl xor ADS_UF_ACCOUNT_DISABLE obj.SetInfo

If you are searching for users with specific userAccountControl properties (in an LDAP search operation), you need special LDAP filters to limit the search to the accounts which have set or not set certain bits in this value:


Const ADS_UF_ACCOUNT_DISABLE = 2 Const ADS_UF_PASSWD_NOTREQD = 32 Const ADS_UF_DONT_EXPIRE_PASSWD = 65536 ‘All accounts which are disabled ‘ => ADS_UF_ACCOUNT_DISABLE = 2 ‘ => ldapFilter = “(userAccountControl:1.2.840.113556.1.4.803:=2)” ‘All accounts which are NOT disabled: ‘ => ADS_UF_ACCOUNT_DISABLE = 2 ‘ => ldapFilter = “(!(userAccountControl:1.2.840.113556.1.4.803:=2))” ‘All accounts which do not need a password OR whose passwords never expire: ‘ => ADS_UF_PASSWD_NOTREQD And ADS_UF_DONT_EXPIRE_PASSWD = 32 + 65536 = 65568 ‘ => ldapFilter = “(userAccountControl:1.2.840.113556.1.4.804:=65568)” ‘All accounts which do not need a password AND whose passwords never expire: ‘ => ADS_UF_PASSWD_NOTREQD And ADS_UF_ACCOUNT_DISABLE = 32 + 2 = 34 ‘ => ldapFilter = “(userAccountControl:1.2.840.113556.1.4.803:=34)”


If this userAccountControl bit is set, the regarding user account is disabled and cannot authenticate to the domain any more. Please do not confuse this with the Intruder Lockout mechanism which locks out a user if he enter a wrong password to often in too short a time.

Disabled users and locked users

If you want to enable a disabled user by deleting the UF_ACOUNT_DISABLE flag, this will only succeed if its password complies with the current password policies. If blank passwords are prohibited in your environment and the disabled user has no password (for example because it was just created), it can not be activated: There will be a runtime error (-2147016651: LDAP_UNWILLING_TO_PERFORM). If a user can be activated in such cases, despite an empty password, then maybe the userAccountControl flag UF_DONT_EXPIRE_PASSWD is set …


If this userAccountControl bit is set, there must be the directory property ‘home drive’ set for the regarding account => the LDAP attribute homeDirectory must exist. That’s the theory. In practice, this bit may be set without the system returning a mistake, even when there is no home drive configured for the regarding user.


Caution: This bit does not work as expected!

This userAccountControl bit is supposed to indicate that the user is locked by the Intruder Lockout mechanism (the lock can only be triggered by the system itself). But this is just a leftover from Windows NT times. For Active Directory users, this bit is NEVER set for locked users – if you want to know whether an account is locked, you should use the attribute lockoutTime:

‘Unlocking a user account: Set user = GetObject(“LDAP://cn=sandra,ou=user,dc=cerrotorre,dc=de”) user.lockoutTime = 0 user.SetInfo

You can search locked accounts with this LDAP filter:

‘All accounts which are locked: ‘ => ldapFilter = “(&(objectClass=user)(lockoutTime>=0))”

If you are currently connected with a user object via LDAP, you can also examine the attribute msDS-User-Account-Control-Computed. In contrast to the userAccountControl, this shows you in the UF_LOCKOUT whether an account is actually deleted. However, it is a constructed attribute so that it cannot be used as a filter criterion in LDAP search operations.


If this userAccountControl bit is set, the user is not subject to a possibly existing policy regarding the length of password. So he can have a shorter password than it is required or it may even have no password at all, even if empty passwords are not allowed. This property is not visible in the normal GUI tools (Active Directory Users and Copmputers)!


Caution: This bit does not work as expected!

This flag is supposed to indicate that the password for that account can not be changed by the account itself. Yet nothing happens if you set the bit (However, there will be no runtime error returned… only the value of the bit remains unchanged). If you want to really make sure that the password may not be modified, you have to deny the extended right ‘Change Password’ for the account itself and each other user.

Prevent password changes

In the access control list, this deny entry is set for the ‘SELF’ trustee also. If you want to change the permissions with a batch script, you can achieve this with two DSACLS commands:

REM Prevent password change
DSACLS “cn=PhilippFoeckeler,dc=selfadsi,dc=org” /D Everyone:CA;”Change Password”

REM Allow password change
DSACLS “cn=PhilippFoeckeler,dc=selfadsi,dc=org” /G Everyone:CA;”Change Password”
DSACLS “cn=PhilippFoeckeler,dc=selfadsi,dc=org” /G SELF:CA;”Change Password”

By the way: A password change is not the same as a password reset. Of course an administrator can perform in that particular case still a password reset.


If this bit is set, the password for this user stored encrypted in the directory – but in a reversible form. As the term reversible already implies: In principle, you could also say that with this setting,the password of the user can be read with the appropriate permissions (=> security gap!!).

You need the UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED flag when an application needs to know the passwords of the users to authenticate them. This is for example the case when you want/have to use RAS (Remote Access) with the old CHAP Authentication, or if you want to use IIS Digest Authentication embedded in an Active Directory environment.

Normally, passwords are stored as irreversible hash values in the AD database. So you should NEVER use this option unless it is absolutely necessary.

Activation of the option "Store password in reversible encryption"


This bit indicates that this is a normal user account. To distinguish this type of account from other types is necessary because not only user objects have a userAccountControl attribute, but also computer objects and others representing domain controllers or trust relationships.


This userAccountControl bit indicates that this is an account which represents a trust connection to an external domain. Normally, the name of the account is the NetBIOS name of the domain with a ‘$’ at the end. This flag should never be set for a user account.


This user account control bit indicates that this is a machine account of an ordinary computer or member server in the domain. This flag should never be set for a user account.


This bit indicates that this is a domain controller account. This flag should never be set for a user account.


Is this userAccountControl bit is set, the user is not subject to an existing policy regarding a forced password change interval: The password of this account never expires.


This bit indicates that this is a Majority Node Set (MNS) account, such account are required for the operation of cluster nodes for Windows Server 2003 (and newer), in which the quorum data is not stored on a shared media drive. This flag should never be set for a user account.


This bit shows that for the regarding account only a smartcard authentication is allowed for interactive logon to the domain. Other authentication mechanisms are not allowed. If this flag is set, the password of this account never expires (he doesn’t use his domain password when loging on with the smartcard …).


This userAccountControl bit indicates that this is an account that can be used for Windows services – and in the way that the service takes on temporarily the identity of a user who are using this services. This is for example the case when the Server service has the same rights on the local disk as the user who is just accessing a shared network drive. We call this process also Impersonation.

UF_NOT_DELEGATED ( 1048576 )

This bit indicates that this is an account for which a service may NOT impersonate the identity (sort of the reverse situation to UF_TRUSTED_FOR_DELEGATION bit).

UF_USE_DES_KEY_ONLY ( 2097152 )

This bit indicates that in the Kerberos authentication of the account ONLY the algorithm DES (Data Encryption Standard) may be used for the generation of tickets. This should only be set for accounts which don’t use a Windows machine to log on to the domain (Windows will always have at least DES and RC4 available).

Actually, this shouldn’t play a big role anymore, because DES is now considered no more as the best algorithm. Since Vista and Windows Server 2008, there is the much more modern AES (Advanced Encryption Standard) algorithm for Kerberos authentication to a domain controller available. For signaling which algorithms are supported for authentication of a specific account, there is now the modern attribute msDS-SupportedEncryptionTypes available. This is used to negotiate the settings between client and domain controller regarding the encryption algorithms.


This bit indicates that there is no so-called pre-authentication necessary for Kerberos authentication of the account. This is only for older Kerberos client important, which need to login to the domain from foreign systems and which does not support Kerberos pre-authentication. For accounts that log on from a Windows machine, or just for machine accounts of Windows domain members, this flag flag should NEVER be set, for the pre-authentication prevents certain types of dictionary attacks on the Kerberos login.


Caution: This bit does not work as expected!

Normally, this user account control bit is supposed to indicate that the user’s password is expired. However, it is not set by the system when the password actually expires, nor can you force the user to change his password at the next logon by setting this bit.

If you really want to know whether the password of an account has expired or not, you can examine the attribute msDS-User-Account-Control-Computed, this is in contrast to the userAccountControl a good indicator for password expiration in the UF_LOCKOUT bit. However, this is a constructed attribute so that it cannot be used as a filter criterion in LDAP search operations.

If you want to force expiration of a password, just set user attribute pwdLastSet to -1.

It’s getting even more complicated if you want to know exactly when a password will expire. This must be calculated with the maxPwdAge attribute of the domain and the pwdLastSet attribute of the account. These are Microsoft Integer8 values that require quite an effort in handling. In Windows 2008, a new LDAP attribute is added, which saves the calculation: msDS-UserPasswordExpiryTimeComputed. This is also constructed attribute so that it cannot be used in LDAP searches nor in an LDAP filter. Take caution when calculating the expiration time AD environments with Windows Server 2008 and newer: There could be so-called Fine Grained Password Policies active.


This bit indicates that the regarding user can request a Kerberos ticket on behalf of another user. This is necessary in rare cases for service accounts, which require so-called S4U2 self-service tickets from the domain controller. This includes the spoofing of identity and goes far beyond normal impersonation, which is sometimes important for running services. For this reason you should set this flag only if it is really necessary.


This bit indicates that the regarding account can request a ticket in the Kerberos ticketing process without sending the so-called Privilege Attribute Certificate (PAC) data. The PAC data structure is a Microsoft-specific Kerberos extension and contains information about the security ID of the user and the groups in which it is member. This bit is only relevant if the account in question logs in from a foreign non-Windows machine at the domain and it does not support PAC.


This bit indicates that this is a ReadOnly domain controller account. These machines accounts always include the UF_WORKSTATION_TRUST_ACCOUNT also. This flag should never be set for a user account.


Hope this repost helps. credits to

This entry was posted in Active Directory, ldap. Bookmark the permalink.