I needed this today for use in querying a large AD.
Repost. Credits go to http://www.selfadsi.org/ads-attributes/user-userAccountControl.htm
you can query with this e.g. with powershell and do some counting:
(Get-ADUser -LDAPFilter “(&(sAMAccountName=*)(!userAccountControl:1.2.840.1135188.8.131.523:=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.
|Data type||Integer (DWORD – 4 Bytes)|
|In Global Catalog?||Yes|
|AD DB attribute name||User-Account-Control|
|ADSI datatype||7 – Integer|
|LDAP syntax||184.108.40.206.4.1.14220.127.116.11.27 – 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:
Here are the single flags, you find some annotations afterwards:
|Flag value (binary)||(decimal)|
|0000000000000000000000000000000x||1||Reserved, the value must always be 0|
|00000000000000000000000000000×00||4||Reserved, the value must always be 0|
|00000000000000000000000×00000000||256||Reserved, the value must always be 0|
|000000000000000000000×0000000000||1024||Reserved, the value must always be 0|
|00000000000000000×00000000000000||16384||Reserved, the value must always be 0|
|0000000000000000×000000000000000||32768||Reserved, the value must always be 0|
|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|
|User whose password never expires|
To set or erase bits in the userAccountControl attribute, this is what you could do:
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:
UF_ACCOUNT_DISABLE ( 2 )
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.
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.
UF_LOCKOUT ( 16 )
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:
You can search locked accounts with this LDAP filter:
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.
UF_PASSWD_NOTREQD ( 32 )
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)!
UF_PASSWD_CANT_CHANGE ( 64 )
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.
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.
UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED ( 128 )
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.
UF_NORMAL_ACCOUNT ( 512 )
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.
UF_INTERDOMAIN_TRUST_ACCOUNT ( 2048 )
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.
UF_WORKSTATION_TRUST_ACCOUNT ( 4096 )
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.
UF_SERVER_TRUST_ACCOUNT ( 8192 )
This bit indicates that this is a domain controller account. This flag should never be set for a user account.
UF_DONT_EXPIRE_PASSWD ( 65536 )
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.
UF_MNS_LOGON_ACCOUNT ( 131072 )
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.
UF_SMARTCARD_REQUIRED ( 262144 )
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 …).
UF_TRUSTED_FOR_DELEGATION ( 524288 )
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.
UF_DONT_REQUIRE_PREAUTH ( 4194304 )
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.
UF_PASSWORD_EXPIRED ( 8388608 )
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.
UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION ( 16777216 )
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.
UF_NO_AUTH_DATA_REQUIRED ( 33554432 )
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.
UF_PARTIAL_SECRETS_ACCOUNT ( 67108864 )
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 http://www.selfadsi.org