The default location for user objects in a domain is the cn=Users container directly off the domain root. You can, of course, create user objects in other containers and organizational units in a domain, or move them to these containers after they’ve been created. Table 6-1 contains a list of some of the interesting attributes that are available on user objects. This is by no means a complete list. There are many other informational attributes that we haven’t included.

You want to modify how the default display name gets generated when you create a new user through the ADUC snap-in or through the Active Directory Administrative Center.

When you create a new user object in ADUC or ADAC, it will automatically fill in the Full Name field as you type in the First Name, Initials, and Last Name fields. As a convenience, you may want to alter that behavior so that it automatically fills in a different value. To do that, you need to modify the User-Display display specifier, which has the following distinguished name:

cn=user-Display,cn=<Locale>,cn=DisplaySpecifiers,cn=Configuration,<ForestRootDN>

<Locale> should be replaced with your language-specific locale, and <ForestRootDN> should contain the distinguished name for your forest root domain. You need to modify the createDialog attribute, which by default has no value. Replacement variables are presented by %<attribute>, where attribute is an attribute name. For example, if you wanted the default to be “LastName, FirstName”, you would use the following value:

%<sn>, %<givenName>

MS KB 250455 (XADM: How to Change Display Names of Active Directory Users)

You want to create a user object.

To make a user account immediately available for a user, you’ll need to make sure the account is enabled, which is accomplished by setting userAccountControl to 512 after you’ve set a password that follows any password complexity rules in place for the user (order is important in this case). If you set only the attributes shown in the command-line and PowerShell examples, then the user accounts will be disabled by default.

You can also create user accounts using the inetOrgPerson class, which is described in Creating an inetOrgPerson User. inetOrgPerson objects can be used for user authentication and restricting access to resources in much the same way as user objects.

Creating a Large Number of Users for creating users in bulk; Creating an inetOrgPerson User for creating an inetOrgPerson user; Setting a User’s Account Options (userAccountControl); MSDN: ADS_USER_FLAG_ENUM

You want to create a large number of user objects, either for testing purposes or to initially populate Active Directory with your employee, customer, or student user accounts.

Using ADSI, PowerShell, and the command-line utilities, you can create hundreds and even thousands of users far more easily and quickly than you would be able to do through a graphical user interface. You can also modify the examples to pull real data from a data source, such as an employee database.

Creating a User for creating a user; MS KB 263911 (How to Set a User’s Password using LDIFDE)

You want to create an inetOrgPerson object, which is the standard LDAP object class to represent users.

The inetOrgPerson object class was defined in RFC 2798. It is the closest thing in the LDAP world to a standard representation of a user, and most LDAP vendors support the inetOrgPerson class. Unfortunately, Microsoft did not support inetOrgPerson with the initial release of Active Directory. Even though it provided an add-on later to extend the schema to support it, the damage had been done. Most Active Directory implementations were already using the user object class and were unlikely to convert, which required vendors to build in support for the user class.

You can create inetOrgPerson objects for your users, who can use them to authenticate just like accounts of the user object class. If you haven’t deployed Active Directory yet and you plan to integrate a lot of third-party LDAP-based applications that rely on inetOrgPerson, you may want to consider using it instead of the user class. You won’t be losing any information or functionality because the inetOrgPerson class inherits directly from the user class. For this reason, the inetOrgPerson class has even more attributes than the Microsoft user class.

The one potential downside is that some of the Microsoft tools, such as the DS utilities, do not support modifying inetOrgPerson objects. (You can, however, use AdMod to perform these modifications.)

Creating a User for creating a user; MS KB 314649; RFC 2798 (Definition of the InetOrgPerson LDAP Object Class)

You want to convert one or more user objects to inetOrgPerson objects to improve interoperability in a heterogeneous environment.

In a heterogeneous environment, you may wish to convert one or more Active Directory user objects to inetOrgPerson objects. Since the inetOrgPerson class inherits from the user class, making this modification is a simple matter of adding the "inetOrgPerson" value to an object’s objectClass attribute. It’s important to note that this is the only instance in which you can modify structural classes in this manner; you can’t simply modify a user object with whatever class you wish, even if that class inherits from the user class.

You can easily modify the command-line and PowerShell solutions to convert all user accounts in your domain (or just in a particular OU) to inetOrgPerson objects. For example, the following combination of adfind and admod will search for all user accounts in the Marketing OU and convert each one to an inetOrgPerson object (the -unsafe switch is necessary if you need to modify more than 10 objects at a time; you can also use the -safety X switch and specify the actual number of objects that you expect to modify for X):

adfind -default -rb "ou=Marketing" -f↵
"(&(objectcategory=person)(objectclass=User))" | admod↵
objectcategory:+:inetOrgPerson -unsafe

MS KB 307998 (Changing the Naming Attribute of the inetOrgPerson Class)

You want to modify an attribute for several users at once.

It is often necessary to update several users at once due to an organizational, geographic, or fileserver change. In each solution, we showed how to modify all users within a parent container, but you may need to use different criteria for locating the users.

Within ADUC, it may appear that you are limited to modifying multiple users that reside in the same container. However, you can create a saved query that returns users based on any criteria you specify. You can then highlight those users and modify them as described in the GUI solution.

With the CLI solution, you can modify the dsquery user command to search on whatever criteria you want. The same applies in the PowerShell solution by using a filter or an LDAP filter.

Searching for Objects in a Domain for more information on searching AD

You want to delete a user object.

This recipe covers deleting individual users. If you want to delete a container or OU and all the objects in it, take a look at Deleting a Container That Has Child Objects.

Deleting a Container That Has Child Objects for deleting a container; MSDN: IADsContainer::Delete; MSDN: IADsDeleteOps:: DeletesObject

You want to set one or more of the user profile attributes.

The four attributes that make up a user’s profile settings are:

When you set the homeDirectory attribute, the folder being referenced needs to already exist. For an example on creating shares for users, see MS KB 234746.

Modifying an Attribute for Several Users at Once for methods to modify the attributes for multiple users

You want to move a user object to a different container or OU.

Moving a user object between OUs in the same domain has no direct impact on the actual user in terms of any security or distribution groups that the user is a member of. The things to be cautious of when moving the user to a new OU are different security settings, different GPOs, and the possibility of breaking applications that have the user’s DN hardcoded into them.

Moving an Object to a Different OU or Container for moving objects between OUs

You want to redirect all new users from the default location (cn=Users) into a different location that you specify.

Most modern methods for creating user accounts, including the Active Directory Administrative Center, ADUC MMC snap-in, AdFind, and DSAdd, allow you to specify which OU a new user should be created in. However, some utilities, such as net user or the WinNT ADSI provider, still rely on a legacy API that will create a user only in its default location until an administrator manually moves it to another OU. The default location is the cn=Users container; this can create issues applying Group Policy to new user objects since the Users container cannot have a GPO linked to it. To ensure that all newly created users receive the necessary Group Policy settings as soon as they are created, use the redirusr.exe utility to redirect all new users that are not otherwise placed into a designated OU into the destination OU that you specify. You need to run this utility only once per domain, and the destination OU needs to exist before you run the utility.

“Redirect Users and Computers”

You want to rename a user.

Renaming a user object can have a couple of different meanings in Active Directory. In the generic object sense, renaming an object consists of changing the RDN for the object to something else, as when cn=jsmith becomes cn=joe. Typically, though, you need to rename more than that with users. For example, let’s say you had a username naming convention of FirstInitialLastName, so Joe Smith’s username would be jsmith. Let’s pretend that Joe decides one day that Smith is way too common and he wants to be unique by changing his last name to Einstein. Now his username should be jeinstein. The following attributes would need to change to complete a rename of his object:

While this example may be contrived, it shows that renaming Joe Smith to Joe Einstein can take up to five attribute changes in Active Directory, or more if you include updates to proxy addresses and other attributes that are typically tied to the user’s name. It is also important to note that if you change any of the first three in the bulleted list (RDN, SAM Account Name, or UPN), you should have the user log off and log back on after the changes have replicated. Since most applications and services rely on user GUID or SID, which doesn’t change during a user rename, the person should not be affected, but you want to have him log off and back on anyway, just in case.

Renaming an Object for renaming objects

You want to copy an existing user account, which may be serving as a template, to create a new account.

Copying a user consists of copying the attributes that are common among a certain user base, which can include department, address, and perhaps even organizational information. ADUC actually uses attributes that are marked in the schema as “Copied when duplicating a user” to determine which attributes to copy. If you are interested in finding the attributes that are configured in the schema to get copied, see Modifying the Attributes That Are Copied When Duplicating a User.

Modifying the Attributes That Are Copied When Duplicating a User for finding the attributes that should be copied when duplicating a user

You want to find users whose accounts are locked out.

Despite the deceptively simple commands just shown, finding the accounts that are currently locked out is a surprisingly complicated task. You would imagine that you could run a query using DSQuery or AdFind (similar to the one to find disabled users in Finding Disabled Users), but unfortunately, it is not that easy.

The lockoutTime attribute is populated with a timestamp when a user is locked. One way to find locked-out users would be to find all users that have something populated in lockoutTime (i.e., lockoutTime=*). That query would definitely find all the currently locked users, but it would also find all the users that subsequently became unlocked and have yet to log in since being unlocked; the lockoutTime attribute doesn’t get reset until the next time the user logs on successfully. This is where the complexity comes into play.

To determine the users that are currently locked out, you have to query the attribute lockoutDuration stored on the domain object (e.g., dc=adatum,dc=com). This attribute defines the number of minutes that an account will stay locked before becoming automatically unlocked. You need to take this value and subtract it from the current time to derive a timestamp that would be the outer marker for which users could still be locked. You can then compare this timestamp with the lockoutTime attribute of the user object. The search filter to find all locked users once you’ve determined the locked timestamp would look something like this:

(&(objectcategory=Person)(objectclass=user)(lockoutTime>DerivedTimestamp))

For any users that have a lockoutTime that is less than the derived timestamp, their account has already been automatically unlocked per the lockoutDuration setting.

None of the current standard GUI or CLI tools incorporates this kind of logic, but fortunately joe Richards wrote the unlock.exe utility, which does. And as its name implies, you can also unlock locked accounts with it. Thanks, joe!

“Details of Account Lockout Settings and Processes”

You want to unlock a locked-out user.

If you’ve enabled account lockouts for an Active Directory domain (see Finding Locked-Out Users), some users may eventually get locked out. A user can get locked out for a number of reasons, but generally it is because a user mistypes her password a number of times, changes her password and does not log off and log on again, or has services or scheduled tasks running under the security context of her individual user account rather than a service account.

You can use ADSI’s IADsUser::IsAccountLocked method to determine whether a user is locked out. You can set IsAccountLocked to FALSE to unlock a user. You can also query the msDS-User-Account-Control-Computed attribute of an object.

Finding Locked-Out Users for finding locked-out users; Troubleshooting Account Lockout Problems for viewing the account lockout policy; MSDN: Account Lockout

A user is having account lockout problems and you need to determine from where and how the account is getting locked out.

The lockoutstatus.exe utility is just one of many that is available in the Account Lockout and Management tool set provided by Microsoft. These lockout tools are intended to help administrators with account lockout problems that were very difficult to troubleshoot in the past. Along with the tool mentioned in , here are a few others that are included in the set:

All the Account Lockout tools are available for download from the Microsoft Download Center.

Account Lockout Best Practices White Paper and Troubleshooting Account Lockout the PSS Way

You want to view the domain-wide account lockout and password policies for a domain.

Several parameters controlling account lockout and password complexity can be set on a domain-linked Group Policy Object such as the Default Domain Policy. The properties that can be set for the password and account lockout policies include:

The properties that can be set for the Password Policy include:

In Windows Server 2003 and legacy versions of Windows, administrators can configure only one password and account lockout policy for domain users, per domain. If a group of users requires a different policy, a separate domain (and all of the hardware requirements and administrative overhead associated with managing that separate domain) is needed. Windows Server 2008 and later versions of Windows allow for the creation of Fine-Grained Password Policies (FGPPs), which allow you to configure multiple password policies within a single domain.

“Account Lockout Best Practices White Paper”; MSDN: DOMAIN_PASSWORD_INFORMATION; “Pwd–Properties attribute (Windows)”

You want to apply a Fine-Grained Password Policy (FGPP) to a user object.

Once an FGPP has been created, you can modify the password and account lockout settings controlled by the object, as well as the users and groups that it should apply to. Since the PasswordSettingsObject is an Active Directory object class, these modifications can be made using any interface that can modify objects. When working from the command line, the psomgr tool from joeware allows you to modify one or multiple PSOs at a time, and can also create “starter” PSOs using the -quickstart command-line switch. The full syntax for psomgr.exe can be obtained by typing psomgr.exe /? at a command prompt, or by visiting the joeware website.

Chapter 9

You want to determine which FGPP is in effect for a particular user.

Within a domain, each user object contains a constructed backlink attribute called msDS-ResultantPSO that indicates which PasswordSettingsObject is in effect for that user. The precedence rules for PasswordSettingsObjects are as follows:

Viewing the Fine-Grained Password Policy That Is in Effect for a User Account; Creating a Fine-Grained Password Policy

You want to enable or disable a user account.

Account status is used to control whether a user is allowed to log on or not. When an account is disabled, the user is not allowed to log on to his workstation with the account or to access AD controlled resources. Much like the lockout status, the account status is stored as a flag in the userAccountControl attribute (see Setting a User’s Account Options (userAccountControl)).

There is an IADsUser::AccountDisabled property that allows you to determine and change the status. Set the method to FALSE to enable the account or to TRUE to disable it.

Finding Disabled Users for finding disabled users; Setting a User’s Account Options (userAccountControl) for more on the attribute userAccountControl

You want to find disabled users in a domain.

Users in Active Directory can be either enabled or disabled. A disabled user cannot log in to the domain. Unlike account lockout, which is an automatic process that is based on the number of times a user incorrectly enters a password, an account has to be manually enabled or disabled.

All disabled user accounts have the bit that represents 2 (0010 base 2) set in their userAccountControl attribute. This doesn’t mean that the attribute will be equal to 2, it just means that the bit that equals 2 will be enabled—other bits may also be set. See Searching with a Bitwise Filter and Modifying a Bit-Flag Attribute for a more detailed explanation of bit flags.

Searching with a Bitwise Filter; Modifying a Bit-Flag Attribute; Enabling and Disabling a User for enabling and disabling users

You want to view the group membership of a user.

The memberOf attribute on user objects is multivalued and contains the list of distinguished names for groups of which the user is a member. memberOf is actually linked with the member attribute on group objects, which holds the distinguished names of its members. For this reason, you cannot directly modify the memberOf attribute; you must instead modify the member attribute on the group.

The primary group of a user, which the user is technically a member of, will not be shown in the CLI or solutions except in the case of the MemberOf utility. This is due to the fact that the primary group is not stored in the memberOf attribute like the rest of the groups. See Recipes and for more on finding the primary group of a user.

Changing a User’s Primary Group; Viewing the Nested Members of a Group for more on viewing the nested members of a group; Resolving a Primary Group ID; Finding the Linked Attributes for more information on linked attributes

You want to remove all group membership information from a user object.