Active Directory’s normal user property pages are fine for routine administration, but they hide an important reality: many account states are driven by raw LDAP attributes under the surface. The Attribute Editor tab in Active Directory Users and Computers (ADUC) gives you direct access to those attributes, including userAccountControl, which is the bitmask that governs enabled or disabled state, password behavior, delegation-related flags, and several other account settings. Microsoft’s current Windows Server documentation also notes that the Attribute Editor exposes attributes that are not surfaced in the standard property UI. (Microsoft Learn)
That is exactly why the Attribute Editor is useful and risky at the same time. userAccountControl is not a friendly “status code” field with one meaning per number. It is a cumulative flag value. A number like 514 is not a magic code by itself; it is simply 512 (NORMAL_ACCOUNT) plus 2 (ACCOUNTDISABLE). Likewise, 66048 is 512 plus 65536, which means a normal user account whose password is set to never expire. Microsoft’s flag tables and ADSI enumeration make that bitwise model explicit. (Microsoft Learn)
That distinction matters because many admins search for values such as userAccountControl 512, 514, or 66048 as though each number were a standalone account type. In practice, the safer mental model is this: start with the current value, decode the flags that are already present, then decide which flag you want to add or remove. If you treat the field as a one-number lookup without understanding the bits behind it, you can overwrite a valid combination with a simpler but wrong value. Microsoft’s documentation also warns that some userAccountControl values are system-managed or should not be assigned by direct manual editing. (Microsoft Learn)
When the Attribute Editor is the right tool
The Attribute Editor is the right tool when you need to inspect the exact raw value on an object, verify what a GUI checkbox actually did, troubleshoot unexpected account behavior, or work with attributes that ADUC does not expose cleanly on its normal tabs. Microsoft documents that the Attribute Editor tab appears in ADUC when View > Advanced Features is enabled, and that it allows direct editing of account attributes.
For common account changes, though, direct raw editing is usually not the best first move. Microsoft provides cmdlets such as Set-ADAccountControl specifically to modify UAC-related settings, and Set-ADUser for broader user changes. Those cmdlets expose named parameters such as -Enabled and -PasswordNeverExpires, which is safer than hand-editing a cumulative integer unless you are deliberately doing attribute-level work.
Before you change anything
Before editing userAccountControl, confirm three things.
First, make sure you are opening the actual object properties in ADUC with Advanced Features enabled so the Attribute Editor tab is available. Microsoft’s Windows Server documentation states that the tab is part of the user account properties view when Advanced Features is turned on.
Second, record the current userAccountControl value before you change it. Because the flags are cumulative, the current value may already include combinations such as DONT_EXPIRE_PASSWD, SMARTCARD_REQUIRED, or NOT_DELEGATED. Replacing the field with a memorized number can silently remove one of those existing flags. That cumulative behavior is explicitly documented by Microsoft.
Third, decide whether the state you care about is actually stored in userAccountControl or computed elsewhere. Microsoft documents that lockout and password-expired behavior moved to msDS-User-Account-Control-Computed in Windows Server 2003-based domains, and the schema reference for msDS-User-Account-Control-Computed explains that it can hold non-persisted computed bits such as lockout and password expired. In other words, some account states are not reliable raw write targets in userAccountControl.
Step-by-step: using Attribute Editor to inspect or change userAccountControl
- Open Active Directory Users and Computers.
- In the menu, enable View > Advanced Features.
- Browse to the user object and open Properties.
- Open the Attribute Editor tab.
- Locate
userAccountControlin the attribute list. - Note the current value before editing.
- Calculate the exact flag change you want, based on the current value and the flags you need to add or remove.
- Apply the new value only after confirming the resulting combination.
- Re-open the account properties or query the object in PowerShell to verify the final state. The tab itself, and its purpose for direct attribute editing, are documented by Microsoft; the cumulative-flag behavior is documented in Microsoft’s
userAccountControlreferences.
A good operational rule is to use the Attribute Editor to inspect first, edit second. For routine account enablement, disablement, password-never-expires, and similar tasks, named admin tools are safer. Use raw editing when you need precision, forensic visibility, or you are validating how the directory actually stores the setting. That division of labor follows Microsoft’s own separation between direct attribute views and purpose-built account control cmdlets.
The values most admins actually search for
userAccountControl 512 means a standard enabled user account. 512 maps to NORMAL_ACCOUNT, which Microsoft describes as the default account type for a typical user.
userAccountControl 514 means a standard user account that is disabled. It is 512 (NORMAL_ACCOUNT) plus 2 (ACCOUNTDISABLE). Microsoft’s current troubleshooting article uses this exact example when explaining how 514 is formed.
userAccountControl 66048 means a standard enabled user account with Password never expires set. It is 512 (NORMAL_ACCOUNT) plus 65536 (DONT_EXPIRE_PASSWD). This is one of the most commonly misunderstood values in search results, but Microsoft’s official flag mapping supports this interpretation directly.
A related value worth knowing is 66050, which is 66048 plus 2. In practical terms, that is a disabled normal user account whose password is also configured to never expire. That follows directly from the same cumulative bit model Microsoft documents for all UAC flags. (learn.microsoft.com)
Another value that appears in the wild is 544, which is 512 plus 32. That means a normal account with PASSWD_NOTREQD. Microsoft documents PASSWD_NOTREQD as a distinct flag, and in most environments it should raise a security question rather than be treated as a routine user state.
The technical nuance most quick guides miss
The biggest mistake in most userAccountControl guides is treating every visible account condition as though it lives in the same raw field. Microsoft explicitly documents exceptions. LOCKOUT and PASSWORD_EXPIRED are called out as conditions that, in Windows Server 2003-based domains, are represented through msDS-User-Account-Control-Computed rather than simply being edited like ordinary persisted flags. The schema documentation for msDS-User-Account-Control-Computed reinforces that it contains extra bits that are not persisted.
A second mistake is assuming every named flag can be safely forced by writing a number. Microsoft’s schema and troubleshooting references state that some values cannot be assigned by directly editing userAccountControl. A good example is PASSWD_CANT_CHANGE, which Microsoft says cannot be set by directly modifying the attribute. That is a strong reason to prefer the appropriate UI or PowerShell parameter over raw integer editing when the platform already exposes a safer administrative path.
A third mistake is forgetting that account-type flags are not a grab bag. Microsoft’s security-properties documentation states that only one account-type value should be set, such as NORMAL_ACCOUNT, WORKSTATION_TRUST_ACCOUNT, or INTERDOMAIN_TRUST_ACCOUNT. So when you edit a user object’s userAccountControl, you are not just toggling booleans; you are preserving a valid object identity while modifying its behavioral flags.
Safer PowerShell equivalents for common changes
If the goal is simply to disable a user, enable a user, or set Password never expires, PowerShell is usually the cleaner tool.
Set-ADAccountControl -Identity jsmith -Enabled $false
Set-ADAccountControl -Identity jsmith -PasswordNeverExpires $true
Set-ADUser -Identity jsmith -ChangePasswordAtLogon $true
Microsoft documents Set-ADAccountControl as the cmdlet for modifying UAC values directly, and Set-ADUser as the cmdlet for modifying user properties, including values not surfaced as dedicated parameters through -Add, -Remove, -Replace, and -Clear.
If you only need to read what is currently stored, querying the user first is the safest workflow, because it lets you confirm both the raw userAccountControl value and any adjacent account state before you touch anything. That read-first approach aligns with the cumulative nature of the attribute documented by Microsoft.
Practical reference workflow for a parallel admin screen
Use this condensed flow when you need a quick operational check.
Start by reading the current userAccountControl value. If it is 512, the user is a normal enabled account. If it is 514, the account is disabled. If it is 66048, the account is enabled and configured so the password never expires. If the state you are investigating is lockout or password expiry, do not assume the raw UAC number tells the whole story; Microsoft documents those as computed-state scenarios in modern AD behavior.
When changing a value, do not replace it with a memorized search-engine number unless you have decoded the existing flags first. The right question is not “What does 66048 mean?” but “What flags are already present, and which one am I trying to add or remove?” That is the difference between precision administration and accidental configuration drift. Microsoft’s documentation on cumulative UAC flags is the foundation for that workflow.
Final takeaway
The Attribute Editor elevates control because it exposes the directory as it really is: a set of attributes, not just a set of checkboxes. But with userAccountControl, that extra control only helps if you think in flags, not labels. 512, 514, and 66048 are not mysterious codes. They are readable bit combinations. Once you understand that model, the Attribute Editor becomes a precise troubleshooting and administration tool instead of a risky last resort.