SysOp Tools Learning Guide:
Managing and Updating the UserAccountControl AD Attribute
Problem: User Accounts in Active Directory are flagged as ‘System’ Accounts and do not Require
An issue we see regularly with domains that contain user accounts which were migrated from NT4 or rdNovell using 3-party migrations tools is, when the accounts are migrated the useraccountcontrol attribute
is not properly set to 512 (an active normal user account object that requires a password) or 514 (a disabled normal user account object) for the accounts. We also see this happen frequently with home-grown user account creation scripts or software that does not set the user account attribute correctly on creation.
If this attribute is not specified for the object at time of creation, Active Directory assigns the account an attribute value of 544 and classifies it as a „System‟ object. Not good. With this incorrect attribute, many
enterprise software tools for AD will not identify these user accounts properly and you may be left scratching your head wondering why.
For example, our password expiration reminder software will not send Password Reminder PRO
expiring password reminders to System accounts, because system accounts are not supposed to belong to a human user. Or perhaps your other user account management software is not categorizing the accounts properly as well.
What is useraccountcontrol and why is it important?
The actual attribute field for AD user accounts we're discussing here is called useraccountcontrol.
This field identifies whether the user object should be treated by AD as a non-user "system" account or treated as a normal user account. A "system" account tells AD that a password is not required by the
account (even though it may have a password set), and the password is probably managed by the system process which created that account. These system accounts are typically created, managed and used by an integrated root service or inter-domain process (IIS, for example). .
The useraccountcontrol field value for a normal domain user account is 512 (password is required), but the accounts in question may be set to 544 which is 512 plus 32 (a password is not required). This presents a potential security risk by allowing a user to maintain a domain logon account with a blank password.
To fix the issue of normal user accounts having an incorrect attribute set, you will have to go through the schema with ADSIEDIT and change these user objects' useraccountcontrol value to 512, and the problem will be resolved. Changing this field value will not affect anything that your users will notice. However, using ADSIEDIT is dangerous and should be used with care as you are basically editing the „registry‟ of
your domain! Additionally, doing this one-by-one can take a long time if you have many incorrectly flagged accounts.
Below you will find a VB Script that you can easily modify, point to an OU of user objects, and force-set the correct attribute of 512. This is much easier! But do be careful- you DO NOT want to run this script on
your entire domain, or you will break the real „system‟ accounts that need to be there. ONLY run it on an OU that you know contains problem user objects.
Next Page - Let’s change things!
Prerequisites for editing the useraccountcontrol attribute
Logon to a DC or member server as a domain administrator and run the below script.
Instructions for setting userAccountControl
1. Copy and paste the example script below into notepad.
2. Change the value for “OU=MyUsers,OU=BadAccounts, “ to point to the OU of your
problem user objects. You must leave a comma and space after the OU name and before the
end quote. Always start OU= with the downlevel OU first (backwards from how it is laid out in
your AD Users and Computers).
3. “intAccValue” is set to 512, which means normal active user account
4. Save the file with a .vbs extension, for example: ChangeUser .vbs.
5. Double click ChangeUser .vbs to run the script on the users in the specified OU and set the
user account attributes to 512, making them normal user objects. You can also drag/drop the
script into an open CMD prompt window then hit enter.
Sample Script to Set userAccountControl (copy area in blue and paste in notepad)
' ChangeUser .vbs ' Sample VBScript to change user account attributes ' SysOp Tools, Inc – Offered ‘as-is’ – use with care ' Version 1.0 – March 2007 ' --------------------------------------------------------------' Option Explicit Dim objOU, objUser, objRootDSE Dim strContainer, strLastUser, strDNSDomain, intAccValue ' Bind to Active Directory Domain Set objRootDSE = GetObject("LDAP://RootDSE") strDNSDomain = objRootDSE.Get("DefaultNamingContext") ' Here is where we set the value to enable the account ' 512 = Enable as normal user account, 514 = Disable as normal user account. intAccValue = 512 ' -------------------------------------------------------------' ' Important - change “OU=MyUsers,OU=BadAccounts, “ to the proper OU path for your user accounts ' -------------------------------------------------------------' strContainer = "OU=MyUsers,OU=BadAccounts, " strContainer = strContainer & strDNSDomain set objOU =GetObject("LDAP://" & strContainer ) For each objUser in objOU If objUser.class="user" then ' The heart of this script - Enable users objUser.Put "userAccountControl", intAccValue objUser.SetInfo End if next ' End of Free Sample UserAccountControl VBScript
Next Page – Making Changes
Making Changes With The Above Script:
UserAccountControl needs a numeric value in order to set the account. The two common 1.
values for user accounts are: 512 = enable and 514 = disable account. If you are scripting
computer accounts substitute a value of 4096. Read the MS Article on all possible attribute
values for useraccountcontrol
Purely for testing, I suggest setting userAccountControl = 514 and setting the script to point to a 2.
new OU called TEST with one test user account in it. Then open up Active Directory Users and
Computers at the OU that corresponds to strContainer “OU=TEST”. What you are looking for is a
red X over the account because 514 sets the account to disabled. Naturally, you could enable
the account by setting the intAccValue= back to 512 and running the script again. Incidentally,
Active Directory Users and Computers does not always refresh with F5, so right click and select
Refresh from the shortcut menu if you want to refresh the user account view after re-running the
Remember, our task is to change all accounts in the OU from an incorrect attribute of 544 to a 3.
normal user attribute of 512.
If you are having a tough time finding all of your incorrectly-attributed user accounts in AD, and 4.
would like an easy method to globally-view and validate successful changes made by the script,
please feel free to use our Password Reminder PRO software as it contains a user account audit
console that will display (1) all user accounts with the incorrect attribute and (2) show them as
fixed if the script was successful. Our software is FREE to use for 60 days, more than enough
time for you to plan and execute domain-wide fixes, no catch or purchase involved.
Before running the script, run Password Reminder PRO's User Reports Console and notice
that all of the incorrectly attributed user objects show under the 'Misc Accounts' tab view, with the
box on far right under the column of 'SystemAccount' checked. These accounts will be the focus
of your fix as the check mark indicates the account has an attribute of 544 (system account).
After you run the above script on these accounts and set the attribute to 512, you will see them 5.
disappear from the Misc Accounts view and appear under 'Licensed Users' view. Success!
SysOp Tools, Inc
Copyright 2007 SysOp Tools, Inc