Managing and Updating the useraccountcontrol AD attribute

By Lisa Roberts,2014-04-10 18:38
5 views 0
Managing and Updating the useraccountcontrol AD attribute

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

    a Password

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!

     Provided by:

    SysOp Tools, Inc

     Copyright 2007 SysOp Tools, Inc

Report this document

For any questions or suggestions please email