Home > Articles

This chapter is from the book

Administering Users, InetOrgPersons, and Contacts

The traditional reason for creating user accounts is to give your users a means to log on to the network. The properties of a user's account control the user's access to the network, and the properties can define some network services for the user in question. Examples of these properties are the password, the account expiration date, a requirement for a smart card logon, and the network path of the user's home folder.

Directory services such as Active Directory have brought a second aspect to user accounts. At this point, we tend to refer to them as "user objects" instead of "accounts." In addition to being a means of access to the network and its services, a user object can store additional information about the user. Some of this information is meant for other human beings—for example, the user's fax number, title, or Web home page address. As a container of such "contact" properties, a user object can function much like an address book entry. A user object can also include properties for use by directory-enabled applications (e.g., Exchange e-mail, a faxing application, personnel-management software, and so on).

In addition to user objects, you can create contact objects. Typically you create a user object for each employee of your organization and a contact object for each person outside your organization whose contact information you want to store. A contact object can contain a subset of the properties that a user object can contain, as you can see in Figure 3.8 and Table 3.7.

03fig08.gifFigure 3.8 Contact object properties on the left are shown in five tabs. User object on the right has the same five tabs of a contact object and eight additional tabs. The five tabs that appear in both screen shots (General, Address, Telephones, Organization, and Member Of) contain the same properties except that the Member Of tab contains a Primary Group setting only for user objects.

Table 3.7. The Nature of User and Contact Objects

Tab Name

User Object

Contact Object

Category [*]




Significant properties: Properties that control user access to the network or define network services for the user




Published Certificates






Member Of [**]









Informational properties Properties that contain information for human beings or are meant for some applications to use










Member Of



The Users and Computers snap-in shows the properties of a contact and user object in a number of tabs in the properties dialog box, as shown in Figure 3.8.

Table 3.7 lists the tabs shown in Figure 3.8, except for the tabs Remote control, Terminal Services Profile, Environment, and Sessions, which are related to Terminal Services. (We don't cover them in this book about Active Directory.) Table 3.7 introduces the terms significant properties and informational properties and shows that a user object can contain both types of properties, but a contact object can contain only the latter.

The Users and Computers snap-in contains tabs for user and/or contact objects that are not shown in Figure 3.8.

  • The Published Certificates tab is visible only when you turn on Advanced Features from the View menu.

  • Turning on Advanced Features also makes the Object and Security tabs visible. Because they are common to all object types, we don't include them in this discussion of user and contact objects.

  • Applications can add tabs. For example, if you install Exchange 2000, it will add some tabs, such as Exchange General and Exchange Features.

To summarize the functions for user objects (and to add a couple of functions):

  • A user object is an account that a user can log on with (using the corresponding significant properties).

  • A user object is a placeholder for a collection of informational properties.

  • A user object is a security principal. This means that you can give permissions to the user for resources and assign security group memberships to the user.

  • The location of a user object in Active Directory dictates which group policies apply to the corresponding user.

A contact object (actually, the person who corresponds to the object) can never log on to the network. Also, a contact object is not a security principal, so it cannot have any permissions. Of course, even if a contact object had permissions, no one would be able to use them, because a contact object cannot be used to log on.

The third type of people is the inetOrgPerson object, which is new to AD2003. An inetOrgPerson object is identical to a user object in practically every way. For more information, see the "Creating InetOrgPersons" section a little later in this chapter.

When you start to manage users and contacts, your tasks will include some or all of the following.

  • Create users, inetOrgPersons, and contacts.

  • Set user, inetOrgPerson, and contact properties.

  • Copy users and inetOrgPersons, and move, rename, and delete users, inetOrgPerson, and contacts.

  • Assign Group Policy and permissions, and delegate administration.

The next sections cover the first three items, but as mentioned earlier, the last item will be discussed in later chapters (Chapter 7 and Chapter 4).

If you want to try the management tasks discussed in this section, create a test OU where you can create test users.

Creating Users

When you choose to create a user with the Users and Computers snap-in, you use a three-page wizard to do so. Figure 3.9 shows the first page of the wizard, where you enter the various names of the new user. Figure 3.10 shows the second page of the wizard, where you can specify a password and some password settings. For example, you can require that a new user change her password at first logon so that only the user knows it and only she can legitimately log on with that account. Alternatively, you can specify that the user cannot change the password. This capability is useful, for example, when several users use the same account. With this setting, you can prevent any of the users from changing the common password. The third page of the wizard displays a summary of what you have selected.

03fig09.gifFigure 3.9 On the first page of the user creation wizard, you enter the various names of the new user.

03fig10.gifFigure 3.10 On the second page of the user creation wizard, you can specify a password and the way it will be used.

Table 3.8 describes the different name properties shown in the first page of the user creation wizard. All the name properties in the table are Unicode strings, and all, except Initials, are indexed and part of the global catalog.

Table 3.8. Name Properties of a User Object



Maximum Length (Characters)




First name





Purely informational.

Initials [*]





Purely informational.

Last name

sn (Surname)




Purely informational.

Full name

name (RDN) and cn (Common-Name)



Within OU

This becomes the object's common name in the OU tree. The wizard suggests "firstname initials. last name". [**]

Display name





Purely informational, initially the same as Full name. You can change it later independent of Full name.

User logon name




Within forest

User can log on using this name on a Windows 2000 or later computer. This name is often the same as the user's e-mail address.

User logon name (pre-Windows 2000)


256 (schema rule), 20 (SAM rule) [***]


Within domain

User can log on using this name on any old or new Windows machine. Despite its label, this name can be used throughout Windows 2000 and later. This name also becomes the name of the user's profile folder when she logs on for the first time.

Experience with Windows NT shows that using even common European characters, such as ä, in names may cause problems. Even though they are supported in principle, many command-line and graphical utilities can't handle them.

In addition to the name properties in Table 3.8, each object has a distinguished name and a canonical name (see Chapter 1). Furthermore, there are two name properties in the base schema that the snap-in doesn't display: the middle name and the generation qualifier (Jr., Sr., III, and so on).

In most cases, you create one user object for each network user. However, some situations call for a second user account.

  • If a user is an administrator, he might have two user accounts: one with normal privileges for everyday use and another one with administrative privileges. It is safer if he uses the latter account only when performing administrative tasks.

  • If a user needs to use several forests and there is no explicit trust between them, she needs a user account in each forest.

  • If a user accesses the network with a mobile device through the Mobile Information Server, he may have a second account with fewer rights and permissions for this mobile access than his normal account has.

  • If a user has a stand-alone server or workstation that is in a workgroup instead of a domain, he will need a local user account in that machine. Active Directory user accounts cannot be used when the computer hasn't joined a domain.

UPN Suffixes

User logon names consist of two parts: the actual user name (e.g., jack.brown) and a UPN suffix (e.g., @sanao.com). For the first part you can enter any text, but for the second part you must choose the UPN suffix from a fixed list. By default, the list contains the name of the domain (e.g., sales.sanao.com) and the name of the root domain (e.g., sanao.com).

An enterprise administrator of a forest can add UPN suffixes to the list using the Domains and Trusts snap-in (click the Start button and then select Administrative Tools, Active Directory Domains and Trusts). Once the snap-in has started, the enterprise administrator right-clicks the uppermost line of the left pane (i.e., Active Directory Domains and Trusts) and selects Properties. The dialog box that appears enables the administrator to define additional UPN suffixes.

If the root domain is corp.sanao.com, for example, the administrator can add a UPN suffix sanao.com, so the users in the forest can have logon names such as jack.brown@sanao.com instead of jack.brown@corp.sanao.com.

Creating InetOrgPersons

AD2003 includes a new object type (that is, object class), inetOrg-Person, which is identical to the user object type in practically every way. InetOrgPerson was defined in RFC 2798 to represent a standard network user, and many other directory services use it for this purpose. Therefore, inetOrgPerson was brought along to Active Directory so that it would be easier to interoperate with these other products or to migrate them to Active Directory.

Although inetOrgPerson should be identical to user, Microsoft recommends that you test it with your applications that would use Active Directory as an authentication method, and your other projected usage scenarios, before you actually start using inetOrgPerson objects.

If inetOrgPerson objects are not needed in your forest, you can modify the forest schema so that InetOrgPerson doesn't appear in the New context menu of the Users and Computers snap-in. You would need to change the defaultHidingValue property of the inetOrgPerson schema class definition to TRUE. This setting affects all administrators of the forest, unless they use some other tool to create objects. For more information, see Chapter 9 or Microsoft Knowledge Base article 311555 at http://www.microsoft.com.

Creating Contacts

To create a contact, you use the contact creation wizard in the Users and Computers snap-in. The wizard has only one page, which is shown in Figure 3.11. A contact object is like an address book entry for e-mail and other applications, and it contains only informational properties. It usually represents a person who is not working for your company, and a contact cannot log on to your network. Therefore, you don't specify a logon name for a contact object. The "Full name" entry becomes the common name of the object in the OU tree.

03fig11.gifFigure 3.11 When you create a contact, you don't specify logon names. Also, there is no second page, which would have the password settings (i.e., significant properties) that you saw when creating a user object.

Setting User, InetOrgPerson, and Contact Properties

You can define more than 50 settings for each user and more than 30 settings for each contact. Behind the scenes, a user object can have 257 properties (207 in AD2000) and a contact object can have 165 properties (138 in AD2000). Fortunately, the only required properties are a few names (which we mentioned in our discussion of creating users).

Although we mention exact counts here and in many other places, you don't have to know the exact numbers. We use exact counts because it is simply easier to express "165 properties" than "well over 150 properties." It is not always possible to be precise, however. We say that you can define "more than 50" settings. In this case, there is more than one way to count the settings in the user interface.

Of the many possible settings, the major significant properties of a user object are set in the Account, Profile, and Dial-in tabs. The major informational properties of user and contact objects are set in the General, Address, Telephones, and Organization tabs. The Member Of tab is covered in the "Administering Groups" section of this chapter.

Windows provides context-sensitive help for each of the settings. In addition, many of the setting names are self-explanatory.

Significant Properties of a User Object: The Account Tab

Figure 3.12 shows the contents of the Account tab, which sets significant properties of a user. It includes settings that control how and when the user can log on, as well as a few settings that control passwords. Table 3.9 lists other settings, except the 11 yes/no check boxes, which appear in Table 3.10.

Table 3.9. Significant Properties of a User Object: The Account Tab





User logon name

userPrincipal- Name

Text (1,024)

User can log on using this name on a Windows 2000 or later computer. This name is often the same as the user's e-mail address.

User logon name (pre-Windows 2000)


Text (256 [schema rule], 20 [SAM rule]) [*]

User can log on using this name on any old or new Windows machine. Despite its label, this name can be used throughout Windows 2000 and later. Also, this name becomes the name of the user's profile folder when she logs on to each Windows NT/2000/XP/Server 2003 computer for the first time.

Logon Hours [**]



Weekdays and hours in one-hour increments during which the user is allowed to log on.

Log On To/Logon Workstations


Text (1,024)

A list of computer NetBIOS names that the user is allowed to log on to.

Account options



These 11 settings are described in Table 3.10.

Account expires



The date after which the user account is no longer usable (although it doesn't vanish then). You can use this for temporary users.

03fig12.gifFigure 3.12 The Account tab of the user Jack Brown

Table 3.10. Significant Properties of a User Object: The Account Options



Account is locked out

If someone tries to log on and enters a wrong password too many times, the account is locked either for a specified time or until the administrator unlocks it. You define the acceptable number of wrong attempts and associated time periods using Group Policy.

User must change password at next logon

After you assign a password to a user, it is a good practice to require the user to change it as soon as he logs on. Then you won't know it anymore.

User cannot change password

This is useful, for example, if several users use one account. You can use this setting to prevent them from changing the password.

Password never expires

You can force users to change their passwords periodically (e.g., every 30 days), but then use this setting to exempt some users from this policy. This is useful, for example, when defining passwords for service accounts. In that case, there is no human being to change the password every month.

Store password using reversible encryption

Normally Active Directory stores passwords using irreversible encryption, meaning that the user's clear-text password cannot be calculated (except through a special "dictionary attack"). You must enable this setting if the corresponding user is using a Macintosh workstation or if she wants to use IIS digest authentication to be able to pass a firewall.

Account is disabled

If a user is away a long time, you can "freeze" the user's account for that time but still not delete it.

Smart card is required for interactive logon


Account is trusted for delegation

This setting is described in Chapter 4 in the "Impersonation and Delegation" section. Note that when the domain is on the Windows Server 2003 functional level, this setting appears on the Delegation tab, and that tab is only visible for accounts that have been assigned service principal names.)

Account is sensitive and cannot be delegated

This setting is described in Chapter 4 in the "Impersonation and Delegation" section.

Use DES encryption types for this account

This setting causes Windows 2000 and later to use Kerberos DES-CBC-MD5 instead of the default RSADSI RC4-HMAC for this user account. The setting affects how Kerberos ticket-granting tickets (TGTs) are encrypted. Data Encryption Standard (DES) is used to encrypt both the ticket and the key of the initial TGT, and DES is also used to encrypt the key of the forwarded TGT. However, RSA is used to encrypt the ticket of the forwarded TGT.

Do not require Kerberos preauthentication

Normally Windows 2000 and later use preauthentication with Kerberos authentication, but it is not compatible with all implementations of Kerberos. Consequently, you must not require preauthentication if the corresponding user account is going to use such an implementation. Selecting this option may expose the user account to denial-of-service attacks.

Because Logon Hours is internally stored as GMT/UTC, an administrator who looks at a user's settings will see the hours as local to the administrator's time zone, regardless of where that is. For example, if a Boston administrator allows a user in Boston to log on between 8:00 AM and 3:00 PM, an administrator in Belgium (6 hours ahead of Boston) who checks that user's setting for logon hours would see times between 2:00 PM and 9:00 PM. There are no adjustments for daylight saving time, however. This is good because this way the allowed logon hours won't change twice a year, when daylight saving time and standard time start.

Table 3.10 lists the yes/no settings in the Account tab. You cannot set the first setting—you can only clear it. The other ten settings you can either set or clear. Eight of the 11 settings are stored in a property called userAccountControl so that one bit represents each setting.

The setting "Account is locked out" is stored in the lockoutTime property, the setting "User must change password at next logon" is stored in the pwdLastSet property, and the setting "User cannot change password" is determined by permissions. You can learn more about the way settings are stored in Chapter 11.

There is one password setting that is not visible in the Users and Computers snap-in. You could type the following command on the command line when sitting at a domain controller:

NET USER JackB /PasswordReq:No

This command relieves JackB from having a password. For example, even though other users of the domain would be required to use at least a six-character password, he would not. Note that you must use the pre–Windows 2000 name of the user in this command.

Even though this command relieves Jack from having a password, he cannot clear his password—an administrator must do this. If Jack later changes his password to "abcdef," he cannot change it back to empty.

You can see the current setting for Jack using the following command:


The minimum length of a password for domain users is set using Group Policy, which is discussed in Chapter 7.

Microsoft has prepared a long and thorough online document called Account Passwords and Policies, which you can access at the address http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx.

Significant Properties of a User Object: The Profile Tab

Figure 3.13 shows the contents of the Profile tab. The Profile tab is not about control as the Account tab is—it's about providing services to users. Table 3.11 lists the Profile tab's four significant properties. They all may contain an "unlimited" number of Unicode characters.

03fig13.gifFigure 3.13 The Profile tab of the user Jack Brown

Table 3.11. Significant Properties of a User Object: The Profile Tab




Profile path


This specifies a Uniform Naming Convention (UNC) name, such as \\Server\Prof$\JackB, to be the network folder where the user's roaming profile is stored. This way, Jack's roaming profile is downloaded to whichever Windows NT/2000/XP workstation he logs on to, and it is uploaded back to the server when he logs off. The dollar sign ($) in the Prof$ sharename makes it invisible so that users don't browse it.

Logon script


This field is the old (i.e., Windows NT) way to define a logon script for a user. The new way (i.e., Active Directory) is to use Group Policy. An example of this path is Logon.Bat. The name is relative to the UNC path \\anydomaincontroller\Netlogon.

Home folder: Local path/To


You can assign each user a private or shared folder on some server. The To field defines the path—for example, \\Server\Users JackB. If possible, the snap-in creates the folder for you. It also gives Administrators and the user Full Control. The snap-in doesn't, however, remove the inherited permissions, so it is quite possible that the Users group will have Read permission for the new home folder. A home folder is an alternative to the My Documents folder, which you can also store on a server using Group Policy. When saving documents, newer applications usually default to My Documents, whereas some may use the %homedrive% and %homepath% environment variables. The "Local path" field defines a path such as D:\JackB, but that path exists on only one local machine.

Home folder: Connect


A drive letter that connects (or maps) to the user's home folder.

You may use the %username% environment variable in the "Profile path" and "Home folder: To" fields. Its value will be the user's logon name (pre–Windows 2000)—that is, his "downlevel logon name." For example, the path \\Server\Prof$\%username% actually means \\Server\Prof$\JackB. This variable is handy when you edit several users at once. At that time, for example, you will be able to set the home folder for several users at once.

Significant Properties of a User Object: The Dial-in Tab

The settings in the Dial-in tab define whether the user may use dial-in or virtual private network (VPN) connections, and if so, in what way. These significant properties apply more to managing communication settings than to managing user settings. Therefore, this tab is outside the scope of this book. The screen shot in Figure 3.14 is provided here for reference.

03fig14.gifFigure 3.14 The Dial-in tab defines whether the user may use dial-in or VPN connections.

Informational Properties of Users and Contacts

As previously stated, the informational properties don't affect the network user (unless you create a query-based group with the Authorization Manager snap-in and base that group on some otherwise informational property). They provide information for other people and for applications that use them. Consequently, these two criteria dictate how you use each of the informational properties. We cannot tell you here the rules to use each informational property, but we can offer a few general guidelines.

If you or any of your users are not interested in these properties, and if you don't have applications to take advantage of them, you can simply leave all the informational properties blank.

Except for Country/region and Manager, both of which you select from a list, you edit all the informational properties in text fields that have very little format checking. These fields have no stringent requirements for acceptable entries. This means that you could fill in the property fields with just about anything, such as your favorite recipes or the hair color of each user, even though the property label indicates a phone number.

Although you have free rein in determining informational properties, the following are some guidelines to keep in mind.

  • Use each property consistently. Ideally, you have a written document that describes which properties are in use in your company and in what format the information should be entered.

  • Some of the properties can be used in search operations. Here, consistency is especially important.

  • Some of the properties can be used in query-based groups. Here, consistency is even more important.

  • By default, each user can see all of his or her properties. Each user can also change those properties that are categorized as Personal Information and Web Information (together consisting of 43 properties, and the same number in AD2000).

  • By default, every logged-on user can see certain properties of all other users. These properties are categorized as General Information, Public Information, Personal Information, and Web Information, and they consist of a total of 93 properties (89 in AD2000).

The information categories mentioned here (Personal Information, General Information, and so on) are used in the management of permissions. Therefore, they are covered in detail in the next chapter, which deals with securing Active Directory. Unfortunately, the categories are quite different from the tabs in user properties. For example, General Information doesn't have anything to do with the General tab.

Table 3.12 lists the properties in the four tabs containing informational properties. We don't include screen shots, because they would show just a number of text boxes.

Table 3.12. Informational Properties of User and Contact Objects



Syntax (Characters)




General Tab

First name


Text (64)





Text (6)


Even though the creation wizard treats this as a middle-name initial, you can enter "JB" for an existing Jack Brown.

Last name

sn (Surname)

Text (64)




Display name


Text (256)



This is not the common name (cn) you see in the OU tree. The user's display name is shown in the Computer Locked dialog box, for example.



Text (1,024)




Text (128)



Telephone number


Text (64)



This is the primary office phone number.

Phone Number (Others)


Text (64)


These are the other office phone numbers.



Text (256)




Web page


Text (2048)


http://something, ftp://something, file://something.

Web Page Address (Others)




A list of multiple values.

Address Tab



Text (1,024)


P.O. Box


Text (40)



l (Locality-Name)

Text (128)





st (State-Or-Province-Name)

Text (128)




Zip/Postal Code


Text (40)



co (Text-Country)

Text (128)


For example, "UNITED STATES."


c (Country-Name)

Text (3)



For example, "US."





For example, "840."

Telephones Tab



Text (64)




Home Phone Number (Others)


Text (64)


A list of multiple values.



Text (64)


Pager Number (Others)


Text (64)


A list of multiple values.



Text (64)


Mobile Number (Others)


Text (64)


A list of multiple values.



Text (64)


Fax Number (Others)

other Facsimile-Telephone-Number

Text (64)


A list of multiple values.

IP phone


Text (64)




IP Phone Number (Others)





A list of multiple values.



Text (1,024)


Organization Tab



Text (64)




Text (64)




Text (64)




DN; you select a user or contact from a list



Setting this doesn't give the manager any permissions.

Direct reports




This property is read-only in the snap-in. If you set Jill to be Jack's manager, Jack will appear in the direct reports of Jill.

The "Country/region" field has a fixed set of options from which you choose. The result is stored in three properties, as described in the table.

Editing Multiple Users

The Windows Server 2003 version of the Users and Computers snap-in enables you to edit multiple objects at the same time. Typically, you would use this feature for user objects (or possibly for inetOrgPerson objects). For other object types, you can edit only the description text.

As you see in Figure 3.15, you can edit quite a few properties for multiple users simultaneously.

03fig15.gifFigure 3.15 You can edit quite a few properties for multiple users simultaneously.

Other Operations to Manage Users, InetOrgPersons, and Contacts

After you have created a number of users and contacts (and possibly inetOrgPersons) and packed them full of properties, you are ready to perform other operations. Open the context menu by right-clicking with your mouse or press a shortcut key to manipulate existing users and contacts in the following ways:

  • Copy (only users and inetOrgPersons, not contacts)

  • Move

  • Rename

  • Delete

  • Disable an account (only users and inetOrgPersons, not contacts)

  • Reset a password (only users and inetOrgPersons, not contacts)

  • Open a home page

  • Send e-mail

Copying Users and InetOrgPersons

You can copy an existing user or inetOrgPerson to create a new one. You do this by right-clicking the object and then selecting Copy. This launches a wizard similar to the one that enables you to create users from scratch. For brevity, we only talk here about users, because inetOrgPersons be have identically.

Copying a user saves time if the new user will have many of the same properties as an existing one. When you copy the user, by default 33 properties of the existing user are copied to the new one. However, only 20 of these properties are visible in the Users and Computers snap-in. Table 3.13 lists these properties, as well as some other categories.

Table 3.13. Properties That Are Copied When Users Are Copied



Copied and visible in the snap-in (20 properties)

accountExpires, c (Country/region) [*] , co (Country/region), company, countryCode (Country/region), department, homeDirectory, homeDrive, l (City), logonHours, manager, memberOf, postalCode (Zip/Postal Code), postOfficeBox, primaryGroupID, profilePath, scriptPath (Logon script), st (State/province), userAccountControl (Account options), and user Workstations (Logon Workstations)

Copied but not visible in the snap-in (13 properties)

Assistant, codePage, division, employeeType, localeID, logonWorkstation, maxStorage, otherLoginWorkstations, postalAddress, preferredOU, showInAddressBook, showInAdvancedViewOnly, and street

Not copied but visible in the snap-in and would be nice to be copied (5 properties)

description, facsimileTelephone Number (Fax), otherFacsimile TelephoneNumber (Fax Number (Others)), physicalDelivery OfficeName (Office), and street Address (Street)

The remaining 13 properties may have values to copy if you have set them programmatically with ADSI Edit or with some other means. However, it's not likely that you have done so.

Obviously, several properties (e.g., names and phone numbers) are personal and therefore not meaningful to copy. On the other hand, there are properties that would be nice to copy, but which are by default not included in the 33 copied properties. Table 3.13 lists five suchproperties.

If you anticipate needing to create several similar user objects, you can create user templates. A user template is a normal user object that represents a typical user of some department. When you need a new user for that department, you can copy the user template to be the new user and modify it as necessary.

The copied properties are defined in the schema. You can add attributes (e.g., streetAddress) to the list, as Chapter 9 will explain.

Moving Users, InetOrgPersons, and Contacts

Every now and then you may want to move some users, inetOrgPersons, or contacts from one OU to another. You move them within a domain either (a) by dragging the object to a new location with the mouse, (b) by using cut/paste with the keyboard or mouse, or (c) by right-clicking the object, selecting Move, and then choosing the destination from the OU tree that opens up and clicking OK. Note that

  • Permissions that are assigned for the object being moved move with the object.

  • Group policies (regarding users and inetOrgPersons) and permissions that are inherited by the object from above do not move with the object being moved. Instead, the moved object inherits the new group policies and permissions in its new location.

You can move several sibling objects at once. Select them in the right-hand pane of the snap-in by using the Shift and/or Ctrl keys. Then proceed as usual.

It is possible to move objects to another domain in your forest. To do so, you need to use another tool, such as the Support Tools command-line tool MoveTree, which is discussed in Chapter 6.

Renaming Users, InetOrgPersons, and Contacts

You can rename a user, inetOrgPerson, or contact by right-clicking the object and selecting Rename or by selecting the object and pressing F2. A third way is to click an already selected object. After you type the new name, press Enter. Because these objects have many names, you have a chance to change one or all of the names in a dialog box, as Figures 3.16 and 3.17 show.

03fig16.gifFigure 3.16 When you rename a user or an inetOrgPerson, you are prompted with a dialog box that enables you to change a number of names at once. The first field, Full name, refers to the common name of the object.

03fig17.gifFigure 3.17 When you rename a contact, you are prompted with a dialog box that enables you to change a number of names at once. The first field, Full name, refers to the common name of the object.

After you rename a user, the old name still appears in the following properties: E-mail, Web page, Profile path, Logon script (if using personal), and Home folder. Also, the corresponding physical folders, as well as the local copy of the user's profile (i.e., C:\Documents and Settings\username), will keep the old name. If you want all of these to reflect the new name, you must change each of them manually.

Deleting Users, InetOrgPersons, and Contacts

You delete an object by right-clicking it and selecting Delete or by selecting the object and pressing the Delete key. As a safety mechanism, you need to confirm the delete but you cannot undo it.

A user object or an inetOrgPerson object is a security principal: It may have security group memberships and permissions for resources. Each security principal has a security ID (SID), which is the identifier to be used in these assignments. A SID is a long number and a SID is never reused. If you delete a user object and then re-create it, it will have a new SID, so the new user has none of the memberships or permissions of the old user. You must assign memberships and permissions specifically to the new user.

Disabling User or InetOrgPerson Accounts

The context menu for a user object or an inetOrgPerson object contains an operation called "Disable Account." It has the same effect as the "Account is disabled" check box in the Account tab of the properties dialog box. This operation is usually used for a limited time. For example, if someone is out of the company for six months, you could freeze his user account but still not delete it.

When you see a red X icon on the account, it is already disabled. In this case the context menu has an operation called "Enable Account."

Resetting User or InetOrgPerson Passwords

You will never see your users' or inetOrgPersons' passwords, but you can change them using the "Reset Password" operation in the context menu. The most obvious reason to do this is because a user has forgotten his password.

Opening Home Pages of Users, InetOrgPersons, and Contacts

If someone has a home page, and the corresponding property is defined in his object, you can open the home page in a browser using the "Open home page" operation in the context menu.

Sending E-mail to Users, InetOrgPersons, and Contacts

If someone has an e-mail address, and the corresponding property is defined in her object, you can send her e-mail with the "Send mail" operation in the context menu.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020