User Account Attributes in AD: Part 5 ADUC Account Tab

This article is the fifth in a series the offers a reference point between User Account attributes and associated displayed values within various interfaces. This particular post is going to be a little tricky, mainly because a number of the values that are displayed on the account tab are not actually individual attributes – quite a few are bits set within a value; None-the-less; I will attempt to describe the tab as best as possible.

In this post we look at the Account Tab within the standard Active Directory for Users and Computers interface. If you are looking for a representation of LDAP fields in Outlook, or other ADUC tabs see these posts:

Outlook Attributes

Outlook Address Book General Tab LDAP Attributes Mapping (Part 1)
Outlook Address Book Phone/Notes Tab – Ldap Attributes Mapping (Part 2)

ADUC Attributes

Active Directory Users and Computers – General Tab (Part 3)
Active Directory Users and Computers – Address Tab (Part 4)

As mentioned in a previous post, if you’re looking for information or a complete list of User Account Attributes in Active Directory for Users and Computers, a simple search of the web should provide you with what you need.

Active Directory – User Account Attributes – ADUC Account Tab

As the name suggests, the Account tab within DSA.MSC (expressed in other words, DSA.MSC is the MMC snap-in that opens up ADUC or Active Directory for Users and Computers) contains logon information, account control related data:

[Move to General Tab] [Move to Address Tab]

**See notes below

Notes

userPrincipalName Attribute

Within the GUI, this value is split over two fields, the field to the left being the username (which can be different to the sAMAccountName), the field to the right – the domain suffix. The actual value that is stored within AD is a combination of both (eg; JohnSmith@my.domain.com would show as JohnSmith to the left and @my.domain.com to the right in the GUI). Within the GUI, a prepopulated domain suffix list will be available for selection; if the user belongs to a child domain, any parent domain may be listed as an available domain suffix to choose from (eg; JohnSmith might be able to use a domain suffix of @my.domain.com or @domain.com). As mentioned before, the left and right fields are added together and stored as the UserPrincipalName attribute.

Now with Office 365, I often hear people asking about creating a new UPN Suffix that matches a customer’s external domain name – this can quite easily be achieved (make sure you test it first to make sure any internal apps that rely on existing name mappings don’t break). In any case, a new UPN Suffix can also be added via Active Directory Domains and Trusts – See KB243629 for details (edit: Seems Microsoft have removed their article, here’s a capture of that article in 2015, alternatively they now provide details for this process here). Joe Palarchio also talks about experiences with this in this post here – I can relate to some of the pain in environments where emails do not match UPNs.

NOTE: Be aware that a UPN is not physically constrained at the directory level – ie: external tools can actually write anything in place of the UPN Suffix. I have seen deployments where UPNs are populated from an external tool; resulting in completely invalid UPNs like “John.Smith@hotmail.com”.

sAMAccountName Attribute (User logon name (pre-Windows 2000))

The field to the left is a prepopulated NETBIOS DOMAIN name value and cannot be set (eg: DOMAIN), the field to the right is the Pre-Windows 2000 account name attribute – the sAMAccountName. Be aware that this value is limited in length (20 characters or less), whereas the UserPrincipalName attribute is not so limited. A number of legacy systems rely heavily on the sAMAccountName attribute to map user accounts.

logonHours Attribute (Logon Hours…)

If you need to automate the management of this field, click here for an article that provides a power shell script example.

userWorkstations Attribute (Log on To…)

Some of the attributes on this tab are not as straightforward to modify as others. Click here for an article that provides a couple of powershell scripts that modify this field.

Unlock Account

The account lockout information for an account is stored within the UserAccountControl attribute as a flag or bit. Commonly, this is referred to as ADS_UF_LOCKOUT. For more information on the UserAccountControl Attribute, see further down in this article. Check out this great Scripting-Guy article on how to find locked out accounts in Powershell – why bother trying to work with the UAC bits, when you can simply fire off a powershell commandlet?

Account Options

In this section we discuss the various check boxes that are present towards the bottom section of the Account panel within the GUI.
A number of these options can be easily manipulated through the PowerShell Commandlet set-aduser.

User must change password at next Logon

This tickbox actually relates to the pwd-last-set attribute.  If this value is set to 0 and the User-Account-Control attribute does not contain the UF_DONT_EXPIRE_PASSWD flag, then the user must set a password at the next logon.

User Cannot change password

This is not actually a true UAC flag –  DO NOT try to modify the ADS_UF_PASSWD_CANT_CHANGE flag/bit; it is a computed bit based on a combination of security permissions. It can get a little tricky manipulating this setting via script. Check this article for more information on how you might achieve this. The simplest thing to do is to use the Powershell Commandlet set-aduser; Scary thought; you don’t need to know any of this stuff anymore; just let the little Commandlet do it for you… one press, no mess; no fuss..!

Password Never Expires

This value is governed by the ADS_UF_DONT_EXPIRE_PASSWD FLAG. Easiest way to manipulate is via the Powershell Commandlet set-aduser.

…More on the UserAccountControl Attribute (Unlock account/Account Options)

Now for the fun part (remeber; you do NOT need to know or understand this to live a fulfilled life). A number of the Account Options (including Unlock account) are not individual attributes; they are simply “bits” stored within a larger value. This concept is quite simple and makes sense to anyone who has spent time working in assembly language – and once you understand the concept it is quite clever.  These days with Powershell we really needn’t understand how this attribute works, we can simply issue a command to achieve the desired result.

I’m going to assume that since you are still reading, you may not fully understand how the attribute works; so I’ll try to explain it as best as I can.

Often, the values stored within the UserAccountControl Attribute are expressed as decimal or hex. Yes, you can simply add each value together to get the end result. However; in order to fully understand how this attribute works, it would be best if we could see the data in binary. Unfortunately, once someone understands how the value works, they don’t bother expressing it in binary – which can make things difficult for someone who might be trying to follow along  in order to understand how the attribute actually works.

Let’s start by saying that the maximum value that the UserAccountControl can hold is:

• 4,294,967,295 (decimal)
• FF FF FF FF (hex)  or
• 1111 1111 1111 1111 1111 1111 1111 1111 (Binary).

As you can see, the binary version of the number is quite long and seemingly meaningless which is another reason that we probably don’t see the UserAccountControl attribute expressed this way. The higher bits of the UserAccountControl attribute are ignored. With all the possible flags/bits in the table below set, the maximum value that the UserAccountControl will ever reach is:

• 67,058,683 (Decimal)
• 3 FF 3B FB (HEX)  or
• 11 1111 1111 0011 1011 1111 1011 (Binary)

Again, this probably seems a little meaningless. Let’s try and look at this in a different light. With our binary number, each bit from right to left has some significance (with four notable exceptions – the bits with an “x” indicate bits that are ignored within the UserAccountControl attribute; perhaps they were earmarked for something and then removed at the last minute.. who knows?) .

Take a look at the image below to see a breakdown of each bit (counting in binary from right to left – apologies if this makes things even more confusing, it may be a little easier to read if the image is opened in a new window):

Each of the flags (or in other terms bits) are added together and stored within a single larger value. Each flag can either be on (1) or off (0). So as an example, if a normal account was disabled and locked out, the following flags would be set:

• ADS_UF_ACCOUNTDISABLE (0000 0010 Binary  || 2 Decimal || 2 Hex)
• ADS_UF_LOCKOUT (0001 0000 Binary || 16 Decimal || 10 Hex)
• ADS_UF_NORMAL_ACCOUNT (0010 0000 0000 Binary || 512 Decimal || 200 Hex)

This would mean that our UserAccountControl value would be those three values combined. In other words our full UserAccountControl value would look like this (if only these values were set):

• 00 0000 0000 0000 0010 0001 0010 (Binary)
• 530 (Decimal) or
• 212 (Hex)

Here’s how the value would look in terms of the visual representation earlier:

Here’s an article that talks about how to use the UserAccount Control Attribute to manipulate accounts. You’ll note that the second article actually has an extra flag listed that isn’t in the first article (I’ve included here on this page – it is the ADS_UF_PARTIAL_SECRETS_ACCOUNT flag… Relax, you probably have no need to worry about it anyway, as it relates to Read Only Domain Controllers). The article also makes reference to a “new” attribute that has been exposed since Windows 2003 Active Directory – msDS-User-Account-Control-Computed; I am not going to go into this here; this post has gone oversize and over time.

ADS_UF_SCRIPT                                  = 1,        // 0x1
  ADS_UF_ACCOUNTDISABLE                          = 2,        // 0x2
  ADS_UF_HOMEDIR_REQUIRED                        = 8,        // 0x8
  ADS_UF_LOCKOUT                                 = 16,       // 0x10
  ADS_UF_PASSWD_NOTREQD                          = 32,       // 0x20
  ADS_UF_PASSWD_CANT_CHANGE                      = 64,       // 0x40
  ADS_UF_ENCRYPTED_TEXT_PWD                      = 128,      // 0x80
  ADS_UF_TEMP_DUPLICATE_ACCOUNT                  = 256,      // 0x100
  ADS_UF_NORMAL_ACCOUNT                          = 512,      // 0x200
  ADS_UF_INTERDOMAIN_TRUST_ACCOUNT               = 2048,     // 0x800
  ADS_UF_WORKSTATION_TRUST_ACCOUNT               = 4096,     // 0x1000
  ADS_UF_SERVER_TRUST_ACCOUNT                    = 8192,     // 0x2000
  ADS_UF_DONT_EXPIRE_PASSWD                      = 65536,    // 0x10000
  ADS_UF_MNS_LOGON_ACCOUNT                       = 131072,   // 0x20000
  ADS_UF_SMARTCARD_REQUIRED                      = 262144,   // 0x40000
  ADS_UF_TRUSTED_FOR_DELEGATION                  = 524288,   // 0x80000
  ADS_UF_NOT_DELEGATED                           = 1048576,  // 0x100000
  ADS_UF_USE_DES_KEY_ONLY                        = 2097152,  // 0x200000
  ADS_UF_DONT_REQUIRE_PREAUTH                    = 4194304,  // 0x400000
  ADS_UF_PASSWORD_EXPIRED                        = 8388608,  // 0x800000
ADS_UF_TRUSTED_AUTH_DELEGATION                 = 16777216, // 0x1000000
ADS_UF_PARTIAL_SECRETS_ACCOUNT                 = 67108864, // 0x4000000

LDAP Query for bitwise flags

What if you needed to run an LDAP query to identify any account where the password has expired?
We can achieve this by using one of the associated LDAP Matching rules (edit: seems that article has moved here) Assuming you are familiar with standard LDAP queries, you could simply add the following to find accounts that have ADS_UF_PASSWORD_EXPIRED set:
(&(existingLDAPQuery)(userAccountControl:1.2.840.113556.1.4.803:=8388608))

There are two bitwise operators you can use:

• ‘1.2.840.113556.1.4.803’ for Logical AND operations.
• ‘1.2.840.113556.1.4.804’ for Logical OR operations.

Be aware that using these operators requires the use of decimal, so don’t key in hex or binary values (as if you would use binary!). Better yet; just use Powershell and don’t bother with any of this stuff. I apologise if I have made any mistakes in this article – feel free to pick it to pieces, or offer suggestions.

Seeya round.