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

Find and List Duplicate UPN (userPrincipalName) Entries in Active Directory

Download the full article with screenshots: http://www.sysoptools.com/support/files/Find%20Duplicate%20UPN%20(userPrincipalName)%20Entries%20in%20Active%20Directory%20-%20the%20userPrincipalName%20AD%20attribute.doc

Symptom:
Users are unable to log in to Password Reset PRO, OWA (Outlook Web Access), MOSS (SharePoint), domain computers, or any other system by using their UPN (userPrincipalName, e.g. user@domain.com). An error event is logged on domain controllers referring to the following AD attribute "DS_USER_PRINCIPAL_NAME":
Cause:
You may have one or more duplicate user account UPNs in AD, which must be cleaned up. Here is a KB link from Microsoft which covers the issue: http://support.microsoft.com/kb/251359/EN-US/ . If you have duplicate UPNs (or missing UPNs), a lot of things may not work right in your domain in regards to user logons- e.g OWA logons, SharePoint logons, any system that uses the newer UPN authentication method (like our self service software), domain trusts, etc.
About the UPN attribute: http://msdn.microsoft.com/en-us/library/cc220979(PROT.13).aspx

Resolution:
Ensure that UPNs are configured and unique on all employee user accounts in the domain. System Accounts and the Builtin accounts may not need a UPN since they are typically not used by a human user for logon purposes (e.g Administrator, Guest, etc). An easy way to clean up your AD of duplicate UPNs is to use scripting, an LDAP search in Active Directory Users and Computers, or the Microsoft LDP.exe utility that ships with the Windows Server 2003 Support Tools. Information on the ldp.exe utility can be found here: http://technet.microsoft.com/en-us/library/cc772839(WS.10).aspx



Using LDP.exe to list all UPN (userPrincipalName) account information in the domain
Run ldp.exe from any domain member server, it is fastest if you run it on the primary DC directly. Launch ldp.exe and configure to connect to your primary DC (Connection > Connect)

Then you must bind to LDAP with proper permissions (Connection > Bind):

It may take a few minutes at this point to load LDAP data from the DC, just wait until it is done.


Now set your search parameter (Browse > Search): Set your configuration the same as the highlighted areas below to run this search on entire domain.

Click "Options" in the screen above, the screen below opens. Here we will add the "userPrincipalName" property to the beginning of the search string:
First, copy the existing search parameters and paste into notepad for safekeeping. Then delete the search parameters and type in "userPrincipalName;" **Make sure to add a semicolon after userPrincipalName**

Viewing Results:


Now click "OK" to close the options screen, then click "Run" on the search screen to execute the search, then click "Close". Your results will look like below, you can copy the screen text for distribution / sorting. This search only lists UPNs in the domain making it easy to spot duplicate or missing UPNs on your employee user accounts.

Using ADUC to find all UPNs in domain


We'll need to set up two things here, first define a custom LDAP search and then set up a custom view in ADUC
Open ADUC, right click on the Saved Searches folder.
Select "new" > "query"

Now configure the name of your search and the query root, then click "define query"

Select "Custom Search" from the drop list and select the Advanced tab:

In the "Enter LDAP Query" field, paste this query string exactly as shown: (objectCategory=person)(objectClass=user)(userPrincipalName=*)
Click OK, then OK to save. You should see a new saved query on left, and all of the query results on right.



Define your custom view in ADUC:
In ADUC, add the column called "User Logon Name" to the list of Displayed Columns in order to see the found UPN data from your custom search. In ADUC, Click the "User Logon Name" column to sort data and look for duplicates. Remove any duplicates by editing the Account tab of the duplicate account and setting the UPN to something unique.

 

Provided by:

SysOp Tools, Inc

       www.sysoptools.com

Copyright 2009 SysOp Tools, Inc

Bulk-Adding a Unique SMTP Email Address to NT User Accounts

Download the full article here including screenshots: http://www.sysoptools.com/support/files/Automate%20bulk-adding%20of%20Active%20Directory%20User%20Accounts%20with%20SMTP%20Mailbox%20Address.doc



Problem: Expiring user accounts in Active Directory do not have an email address, and Password Reminder PRO cannot send a password expiration reminder email to the user.


If you need to bulk-add an SMTP email addresses to your non-Exchange-enabled NT user accounts in order to use Password Reminder PRO and other 3rd-party AD management tools, you can now do so very easily with this simple yet powerful script.


The big question: How do I auto-create the first portion of each users email address since it is unique? Each email address has to be the same as the user's NT logon name! How do I easily insert these addresses into the NT account properties for hundreds or thousands of accounts?


Fear not! The below .vbs script looks up the SamAccountName from each user accounts' UPN (logonname@domain.com), and then writes it into the accounts e-Mail field properties of the General tab. Neat-O!


In the script below, you have option to set the portion of '@domain.com' to your environment, as well as the domain and OU path the script should run against. You can do one user, one OU, or the entire domain!
OK- Let's change things!
*Disclaimer- Always test scripts first in a non-production environment!


Prerequisites for editing the user account Mail attribute
Logon to a DC as a domain administrator and run the below script.
Instructions for setting and testing the script

1. Copy and paste the example script below into notepad.
2. Change the value in RED for 'yourdomain.com' to your email domain
3. Change the RED value for LDAP path to point to correct OU and root domain
4. Save the file with a .vbs extension, for example: AddMailAddress .vbs
5. Open a CMD prompt, drag/drop the script into the CMD window and hit enter

NOTES:

ALWAYS TEST FIRST! To test script results, create a test user account under a test OU called "TestOU" as in the script below. Run script and you will see the email address inserted under the General properties for that user account. Check that it is the result that you want.

CAUTION! If you run this script against accounts that already have an email address in the e-Mail field of the General tab / user account properties, the existing address will be overwritten!

Sample Script to Batch-Set the Mail Attribute for AD User Objects
(copy area in blue and paste in notepad)

 

' AddMailAddress.vbs
' Sample VBScript to bulk-add email address to AD non mail-enabled user accounts in a domain
' SysOp Tools, Inc – Offered 'as-is' – use with care
' Version 1.0 – August 2007
' --------------------------------------------------------------'

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2

Set objConnection = CreateObject("ADODB.Connection")

Set objCommand = CreateObject("ADODB.Command")

objConnection.Provider = "ADsDSOObject"

objConnection.Open "Active Directory Provider"

Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Page Size") = 1000

objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

objCommand.CommandText = _

"SELECT AdsPath,samAccountName,userPrincipalName FROM " & _

"'LDAP://OU=TestOU,dc=yourdomain,dc=com' WHERE objectCategory='user'"

Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF

strUser = objRecordSet.Fields("ADsPath").Value

strNewUPN = objRecordSet.Fields("samAccountName").Value & "@" & "yourdomain.com"

Set objUser = GetObject(strUser)

objUser.Mail = strNewUPN

objUser.SetInfo

objRecordSet.MoveNext

Loop

' -------------------------------------------------------------'
' Important - change LDAP:// path to reflect the proper user, OU, or domain the script should modify
' -------------------------------------------------------------'
' End of Free Sample AddMailAddress VBScript

Need help?

Our dedicated support team is always available to assist you with setup, installation and deployment of our software during your trial period. Your success is our success!

Provided by:

Enterprise Support Team

SysOp Tools, Inc

http://www.sysoptools.com/
Copyright 2007 SysOp Tools, Inc

How and Where to Configure the Domain Password Expiration Policy in 2003 / 2008 Active Directory; A Must Read for any Windows System Administrator.

Updated March 20, 2010
*Content for this guide was provided with permission by Clint Boessen, MCSE, from his original article "The Low Down on Password Polices". Visit Clint's blog site at http://clintboessen.blogspot.com/ for more topics and information related to Active Directory and Exchange.


Summary
In this guide we will cover some of the important "where, how and whys" of setting up the domain password expiration and lockout policies in AD 2000, 2003, 2008 as well as the new granular Password Settings Objects (PSO's) available in 2008 Active Directory. There are many articles on the Internet with information on setting up password policies for windows networks, however most of these articles do not cover several key points which are vital to ensuring these extremely important policies are set up and applied correctly. These commonly missing key points will be the main focus, and by the end of this guide you should have enough of an understanding to be able to set up these policies in your own environment.
We would like to advise a strong word of caution, however, before making changes to policies in Active Directory. Enabling the password expiration policy in an existing domain without first formulating a sound game plan can be a nightmare for your users and IT staff. Review our guide here for a few basic password policy deployment approaches that can save you some time and headache.




Contents


Where do I link the password policy and lockout policy in the domain tree?
Do I create a new GPO or use the existing default group policy objects?
So what are these Password Settings Objects in Server 2008?
Audit Policies - How to see who is logging in and out of the domain

Where do I link the password policy and lockout policy in the domain tree?

The domain password expiration policy, lockout policy, and other related policy settings must be configured at specific locations within the AD tree structure in order to function properly. Password policies are applied to computer objects, not user objects in active directory. There can only be one password policy "per account database", e.g. "per domain". This holds true for 2000 through 2008 domains.

Microsoft says:

There can be only a single password policy for each account database. An Active Directory domain is considered a single account database, as is the local account database on stand alone computers. There can be only a single password policy for each account database. An Active Directory domain is considered a single account database, as is the local account database on stand alone computers.

Taken from: http://technet.microsoft.com/en-us/library/cc875814.aspx

Scenario 1: If you were to link your password policy to the "Domain Controllers" OU, this would mean that your password policy would apply only to domain user accounts in Active Directory.

Scenario 2: If you were to link your password policy at the root domain level, this would hit all computer objects in the active directory database including domain controllers (assuming you do not have block policy inheritance set on the domain controllers organizational unit). The password policy will hit the local SAM database for all member workstations / servers in the active directory domain, meaning that in addition to domain user accounts using the password policy, all machine-local user accounts on domain member workstations and servers will also now adhere to the domain password policy.

Microsoft recommends always linking your password policy at the root domain level (Scenario 2) to ensure the password policy uniformly covers local machine user accounts as well as active directory domain user accounts for obvious reasons. Think about it- Why enforce a strict password expiration policy for your domain user accounts but not for your local user accounts? If someone cracked a local user account on a member workstation or server they could install a rootkit, which they could then use as an access point to attack the active directory domain. If your company is under current compliance requirements for SOX, PCI, HIPAA, etc, more than likely you will need to apply your password expiration policies at the root level. Check your compliance requirements to confirm.

The above scenarios also hold true for the domain lockout policy. Also note that child domains of the parent root domain must have their own separately configured polices. Here is a quick "Best Practice" structure from Microsoft on where to properly link your different policies:

Default Domain (root level) Security Policy Settings:
- Password Policy
- Domain Account Lockout Policy
- Domain Kerberos Policy

Default Domain Controller (Domain Controllers OU) Security Policy Settings:
- User Rights Assignment Policy
- Audit Policy

Taken from: http://technet.microsoft.com/en-us/library/cc773164.aspx

Do I create a new GPO or use the existing default group policy objects?

Microsoft recommends never modifying the "default domain policy" and "default domain controllers policy". Create a new group policy object called something like "Corporate Password Policy" and link it at the root domain level. Ensure to assign it a higher priority than the Default Domain Policy to ensure the settings override.

Taken from Microsoft:

It is a best practice to avoid modifying these built-in GPOs, if you need to apply password policy settings that diverge from the default settings, you should instead create a new GPO and link it to the root container for the domain or to the Domain Controllers OU and assign it a higher priority than the built-in GPO: If two GPOs that have conflicting settings are linked to the same container, the one with higher priority takes precedence.

Reference: http://technet.microsoft.com/en-us/library/cc875814.aspx

The reason behind this is because doing so makes it much easier to recover from serious problems with security settings. If the new security settings create problems, you can temporarily disable the new Group Policy object until you isolate the settings that caused the problems.

What are these new Password Settings Objects in Server 2008 AD?

As I mentioned above, password policies apply on a database level meaning that every account in the Active Directory database needs to adhere to a password policy. In Server 2000/2003 if you want to have a different password policy for different departments or user groups, the only way to achieve this was to create another domain (or child domain) within the same forest.

Windows 2008 gets around this with the new Password Settings Objects (called PSO's for short). PSO's can be configured to effect specific users and groups in an active directory domain.

PSO's sometimes get referred to as "Granular Password Settings" or "Fine-Grained Password Policy". One thing I would like to point out, a PSO is not a policy. A PSO is an object in the active directory database much like a user account or computer account. There are two AD Classes that make this work:
- Password Settings Container
- Password Setting Objects

To use PSO's your domain functional level must be server 2008. With PSO's they do not replace your domain password policy - you still need to configure this at the appropriate level in AD. It is there more as a fallback in case the PSO does not get applied to particular users or groups.
For a step by step guide on how to configure Password Settings Objects in 2008 AD please read these two articles by Jakob H. Heidelberg from windowsecurity.com:http://www.windowsecurity.com/articles/Configuring-Granular-Password-Settings-Windows-Server-2008-Part-1.html


http://www.windowsecurity.com/articles/Configuring-Granular-Password-Settings-Windows-Server-2008-Part2.html

Audit Policies - How to see who is logging in and out of the domain

This section is not part of configuring the domain password policies, however configuring appropriate audit policies for specific events in the domain can be beneficial when you need to find key information on past events.
Audit policies should be configured on the Domain Controllers OU level.

Two audit policies which are frequently used are "Audit logon events" and "Audit account logon events". These policies can tell you who logged in (or failed login) to the domain, and who accessed which network resource (or failed to access). Since these two audit policies sound somewhat similar, it is a bit confusing on the differences between the two.

The "Audit account logon events" policy covers when user accounts try to authenticate against a domain controller. It can log success or failure depending on how you configure it. This policy basically checks that the user's login credentials are correct (correct domain username and password) at time of login to the domain.

The "Audit logon events" policy generates events for the creation and destruction of logon sessions. For example, triggers for these events are things like accessing a shared directory. The user is already "authenticated" on the network and using their issued kerberos key to access shared network resources.

For further information on the various audit policies see this post:http://www.enterprisenetworkingplanet.com/netos/article.php/624921

Tip- Only configure audit policies that you actually need. Do not audit everything, otherwise your event logs will be spammed and you will be sifting through meaningless events looking for the important items. Start with "Audit account logon events" in order to see when people logged in and out of the network as well as any failed logon attempts. From there, you can add other audit polices as required for your environment.
-End of guide


Looking for a good proactive management tool to assist with managing your password expiring users?

Password Reminder PRO

Expiring Password Reminder & User Account Auditing Software for Active Directory

Complete proactive solution to reliably notify users of Windows password expiration & expiring logon accounts. Daily event report allows admins to stay ahead of common user issues. Hot! 

Download today and reduce expired password help calls..

Need a secure, easy to deploy web based self service solution to allow user password resets and account unlocks?

Password Reset PRO
The Best, Easiest to Use Web Based Self Service Software for Active Directory Users

Our Web Based Self Service solution allows users to easily reset an expired or forgotten password, account lockout, and contact IT staff for help. Easy to deploy, no user training, highly secure!

Download the hottest solution for web based self service..

Instructions for Creating Active Directory-Aware User Accounts from an Excel Spreadsheet

There may be an occasion where you need to bulk-create new user accounts from a list given to you by HR. Using the below Excel spreadsheet method combined with an AD-aware VB script can solve your headache in short order. 

Step 1 - Build the Excel Spreadsheet

1. Each user will occupy one row, for example John Evans, Row 3.  Each attribute will always be in the same column, for example givenName in Column C.
2. Mandatory LDAP attributes: sAMAccountName and CN (ObjectClass is taken care of by VBScript).
3. Important LDAP attributes: givenName, sn
4. Optional LDAP attributes: physicalDeliveryOfficeName, email, phone, description, displayName.
5. Note how you can use the power of Excel's functions to derive one column from another, for example, sAMAccountName could be build up from the first three letters of the givenName added to the 4 left most characters of the sn. See =LEFT(C3,3)&LEFT(D3,4) in the above diagram. 

Step 2 - Copy and Edit the VBScript

1. You need access to a Windows Active Directory domain.
2. Copy and paste the example script below into notepad or a VBScript editor.
3. Amend the file path for strSheet.  Example: strSheet = "E:\scripts\CreateUserSpreadsheet.xls"
4. Save the file with a .vbs extension, for example: CreateUserSpreadsheet.vbs.
5. Double click CreateUserSpreadsheet.vbs and check the Computers container for strComputer.

Example Script to create User Accounts from a spreadsheet

' CreateUserSpreadsheet .vbs
' Sample VBScript to create User accounts from a spreadsheet

' ------------------------------------------------------'
Option Explicit
Dim objRootLDAP, objContainer, objUser, objShell
Dim objExcel, objSpread, intRow
Dim strUser, strOU, strSheet
Dim strCN, strSam, strFirst, strLast, strPWD

' -------------------------------------------------------------'
' Important change OU= and strSheet to reflect your domain
' -------------------------------------------------------------'

strOU = "OU=Accounts7 ," ' Note the comma
strSheet = "E:\scripts\UserSpread1.xls"

' Bind to Active Directory, Users container.
Set objRootLDAP = GetObject("LDAP://rootDSE")
Set objContainer = GetObject("LDAP://" & strOU & _
objRootLDAP.Get("defaultNamingContext"))

' Open the Excel spreadsheet
Set objExcel = CreateObject("Excel.Application")
Set objSpread = objExcel.Workbooks.Open(strSheet)
intRow = 3 'Row 1 often contains headings

' Here is the 'DO...Loop' that cycles through the cells
' Note intRow, x must correspond to the column in strSheet
Do Until objExcel.Cells(intRow,1).Value = ""
   strSam = Trim(objExcel.Cells(intRow, 1).Value)
   strCN = Trim(objExcel.Cells(intRow, 2).Value)
   strFirst = Trim(objExcel.Cells(intRow, 3).Value)
   strLast = Trim(objExcel.Cells(intRow, 4).Value)
   strPWD = Trim(objExcel.Cells(intRow, 5).Value)

   ' Build the actual User from data in strSheet.
   Set objUser = objContainer.Create("User", "cn=" & strCN)
   objUser.sAMAccountName = strSam
   objUser.givenName = strFirst
   objUser.sn = strLast
   objUser.SetInfo

   ' Separate section to enable account with its password set to expire via policy, you can set the value to 514 to have the accounts set to disabled
   objUser.userAccountControl = 512
   objUser.pwdLastSet = 0
   objUser.SetPassword strPWD
   objUser.SetInfo

intRow = intRow + 1
Loop
objExcel.Quit

WScript.Quit

' End of example CreateUserSpreadsheet VBScript.

VBScript Tutorial – Notes on Using Excel Spreadsheet

 Note 1: In this example, the basic Excel spreadsheet has just 5 columns of properties / LDAP attributes.  Trace how each of the 5 columns is used in the VBScript, see line 33 onwards.  Once you master the concept, then you can add many more columns of LDAP properties.
Note 2: As I mentioned earlier, I love the power of Excel to calculate one column from another.  Column A, sAMAccountName (logon name) is derived from the first three letters of the givenName, joined with an & to the first 4 letters of the sn column. =Left(C3,3)&LEFT(D3,4).  The beauty of this technique is that you can then use Excel's fill down to calculate the rest of the users.
Note 3: I always reserve Row 2 for indexing the Column letters, e.g. A = 1, B=2 etc.  This makes it easier to reference .cell properties, for example,  intRow, 4).Value) corresponds to Column D.
Note 4: It is worth commenting on what is not explicitly required in the spreadsheet.  VBScript takes care of the objectClass ("User").  It also calculates the DN (Distinguished Name) from the name of the OU and the DNS domain as specified by objContainer.

Note 1:  In this example see how CreateObject("Excel.Application") creates an instance of Excel.  Equally see how objExcel.Quit closes Excel at the end of the script.
Note 2:  Here we employ the Open method, just as if we clicked on the File menu: objExcel.Workbooks.Open(strSheet)
Note 3: It is worth studying the Do.. Loop from lines 33-54.  If you break the loop into 3 sections, you can see at the first section where it interacts with the spreadsheet, extracting the values with the aid of the trim function to get rid of any spaces.
The second section builds most of the user, while the third section deals with setting the password and enabling the account with userAccountControl = 512
Note 4: objExcel.Quit prevents zillions of instance of Excel in the Task Manger when running the script, do not remove it.  However, do watch out for numerous instances of Excel in your Task manager as a precaution, some of these may prevent you editing your spreadsheet.  If the script fails for any reason, then you will get an orphaned Excel instance running which you'll need to zap with Task Manager.

END OF GUIDE