Managing Active Directory OUs, Users, and Groups

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.

Figure 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 [*]
Account	X		Significant properties: Properties that control user access to the network or define network services for the user
Profile	X
Published Certificates	X
COM+	X
Member Of [**]	X
Dial-in	X
General	X	X	Informational properties Properties that contain information for human beings or are meant for some applications to use
Address	X	X
Telephones	X	X
Organization	X	X
Member Of	X	X

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.

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

Figure 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

Property	LDAP Name	Maximum Length (Characters)	Required	Unique	Description
First name	givenName	64		No	Purely informational.
Initials [*]	initials	6		No	Purely informational.
Last name	sn (Surname)	64		No	Purely informational.
Full name	name (RDN) and cn (Common-Name)	64	X	Within OU	This becomes the object's common name in the OU tree. The wizard suggests "firstname initials. last name". [**]
Display name	display-Name	256		No	Purely informational, initially the same as Full name. You can change it later independent of Full name.
User logon name	user-Principal-Name	1,024	X	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)	sAMAccount-Name	256 (schema rule), 20 (SAM rule) [***]	X	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.

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.

Figure 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).

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.

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

Property/Setting	LDAP Name	Syntax	Description
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)	sAMAccount-Name	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 [**]	logonHours	(Binary)	Weekdays and hours in one-hour increments during which the user is allowed to log on.
Log On To/Logon Workstations	user-Workstations	Text (1,024)	A list of computer NetBIOS names that the user is allowed to log on to.
Account options	userAccount-Control	Yes/No	These 11 settings are described in Table 3.10.
Account expires	account-Expires	Date	The date after which the user account is no longer usable (although it doesn't vanish then). You can use this for temporary users.

Figure 3.12 The Account tab of the user Jack Brown

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

Setting	Description
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	Self-explanatory.
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.

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:

NET USER JackB

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.

Figure 3.13 The Profile tab of the user Jack Brown

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

Property	LDAP Name	Description
Profile path	profilePath	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	scriptPath	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	homeDirectory	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	homeDrive	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.

Figure 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).

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

Property	LDAP Name	Syntax (Characters)	Index	GC	Comments
General Tab
First name	givenName	Text (64)	X	X
Initials	initials	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)	X	X
Display name	displayName	Text (256)	X	X	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.
Description	description	Text (1,024)	X
Office	physical-Delivery-OfficeName	Text (128)	X
Telephone number	telephone-Number	Text (64)		X	This is the primary office phone number.
Phone Number (Others)	other-Telephone	Text (64)			These are the other office phone numbers.
E-mail	mail	Text (256)	X	X
Web page	wWWHomePage	Text (2048)			http://something, ftp://something, file://something.
Web Page Address (Others)	url	Text			A list of multiple values.
Address Tab
Street	street-Address	Text (1,024)
P.O. Box	post-OfficeBox	Text (40)
City	l (Locality-Name)	Text (128)	X	X
State/province	st (State-Or-Province-Name)	Text (128)		X
Zip/Postal Code	postalCode	Text (40)
Country/region	co (Text-Country)	Text (128)			For example, "UNITED STATES."
	c (Country-Name)	Text (3)		X	For example, "US."
	countryCode	Integer			For example, "840."
Telephones Tab
Home	homePhone	Text (64)		X
Home Phone Number (Others)	otherHome-Phone	Text (64)			A list of multiple values.
Pager	pager	Text (64)
Pager Number (Others)	otherPager	Text (64)			A list of multiple values.
Mobile	mobile	Text (64)
Mobile Number (Others)	otherMobile	Text (64)			A list of multiple values.
Fax	facsimile-Telephone-Number	Text (64)
Fax Number (Others)	other Facsimile-Telephone-Number	Text (64)			A list of multiple values.
IP phone	ipPhone	Text (64)		X
IP Phone Number (Others)	other-IpPhone	Text		X	A list of multiple values.
Notes	info	Text (1,024)
Organization Tab
Title	title	Text (64)
Department	department	Text (64)
Company	company	Text (64)
Manager	manager	DN; you select a user or contact from a list		X	Setting this doesn't give the manager any permissions.
Direct reports	direct-Reports	DN			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.

Figure 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

Category	Properties
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.

Figure 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.

Figure 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.