Managing and Updating the userAccountControl AD Attribute - Fixing User Accounts Set as System Accounts

Download the full article here: http://www.sysoptools.com/support/files/Fixing%20user%20accounts%20flagged%20as%20system%20accounts%20-%20the%20UserAccountControl%20AD%20attribute.doc


Problem: User Accounts in Active Directory flagged as 'System' Accounts
An issue we see regularly with domains that contain user accounts which were migrated from NT4 or Novell using 3^rd-party migrations tools is, when the accounts are migrated using the 3^rd-party tool 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). 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.



What you may end up with is user accounts that have an attribute set to 544 with tells AD that it is a 'system' account. With this incorrect attribute set, many enterprise software tools for AD will not identify these incorrectly flagged accounts properly and will not operate properly with them.

For example, our password expiration reminder software Password Reminder PRO will not send expiring password reminders to System accounts, because system accounts are not supposed to belong to a human user.


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.







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 strContainer.  Naturally, to be effective you must have a user object or two in the OU specified by strContainer.

3.       Change the value for intAccValue or leave at the default of 512 (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.

 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= to reflect the proper user OU name in your domain
' -------------------------------------------------------------'
strContainer = "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

Making Changes With The Above Script:

1.       UserAccountControl needs a numeric value in order to set the account.  The two common 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

2.       Purely for testing, I suggest setting userAccountControl = 514 and setting the script to point to a 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 script.

3.      Remember, our task is to change all accounts in the OU from an incorrect attribute of 544 to a normal user attribute of 512.

4.   If you are having a tough time finding all of your incorrectly-attributed user accounts in AD, and 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 'System Account' checked. These accounts will be the focus of your fix as the check mark indicates the account has an attribute of 544 (system account).  

 5.  After you run the above script on these accounts and set the attribute to 512, you will see them disappear from the Misc Accounts view and appear under 'Licensed Users' view. Success!

Provided by:

SysOp Tools, Inc

       www.sysoptools.com



Copyright 2007 SysOp Tools, Inc