- Active Directory after Installation
- Administering OUS
- Administering Users and Contacts
- Administering Computer Objects
- Administering Groups
- Tips on Tools
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Administering Users 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.
){kind=link}
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 seven 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.
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.
TABLE 3.7 The Nature of User and Contact Objects
|
Tab Name |
User Object |
Contact Object |
Category* |
|
Account |
X |
|
Significant properties: Properties that control |
|
Profile |
X |
|
user access to the network or define network |
|
Published Certificates |
X |
|
services for the user |
|
Member Of** |
X |
|
|
|
Dial-in |
X |
|
|
|
General |
X |
X |
Informational properties: Properties that |
|
Address |
X |
X |
contain information for human beings or are |
|
Telephones |
X |
X |
meant for some applications to use |
|
Organization |
X |
X |
|
|
Member Of |
X |
X |
|
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.
When you start to manage users and contacts, your tasks will include some or all of the following.
Create users and contacts.
Set user and contact properties.
Copy users, and move, rename, and delete users 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.
){kind=link}
){kind=link}
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.
WARNING
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 generation qualifier (Jr., Sr., III, and so on).
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. lastname".***. |
|
Display name |
displayName |
256 |
|
No |
Purely informational, initially the same as Full name. You can change it later, independently of Full name. |
|
User logon name |
userPrincipal- Name |
"Without" limit |
X |
Within forest |
User can log on using this name on a Windows 2000 computer. This name is often the same as the user's e-mail address. |
|
User logon name (pre- Windows 2000) |
sAMAccount- Name |
256 |
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. This name also becomes the name of the user's profile folder when she logs on for the first time. |
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 2001 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 Programs, 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 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.
){kind=link}
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 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 207 properties and a contact object can have 138 properties. Fortunately, the only required properties are a few names (which we mentioned in our discussion of creating users).
NOTE
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 "138 properties" than "well over 100 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.
NOTE
Windows 2000 provides context-sensitive help for each of the settings. In addition, many of the setting names are self-explanatory.
Unfortunately, you can only edit properties for one user or contact at a time. A future version of the snap-in may enable you to edit several users at once.
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.
){kind=link}
Figure 3.12 The Account tab of the user Jack Brown
TABLE 3.9 Significant Properties of a User Object: The Account Tab
|
Property/Setting |
LDAP Name |
Syntax |
Description |
|
User logon name |
userPrincipalName |
Text |
User can log on using this name on a Windows 2000 computer. This name is often the same as user's e-mail address. |
|
User logon name (pre-Windows 2000) |
sAMAccountName |
Text (256)* |
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. Also, this name becomes the name of user's profile folder when she logs on to each Windows NT/2000 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 |
userWorkstations |
Text (1024) |
A list of computer NetBIOS names that the user is allowed to log on to. |
|
Account options |
userAccountControl |
Yes/No |
These 11 settings are described in Table 3.10. |
|
Account expires |
accountExpires |
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. |
NOTE
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 10 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.
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 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. |
|
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 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 uses 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. |
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 of 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
NOTE
The minimum length of a password for domain users is set using Group Policy, which is discussed in Chapter 7.
If you test the settings in Table 3.10, the Users and Computers snap-in doesn't always keep up with you. For example, if you select "User must change password at next logon," click Apply, then deselect it, click Apply again, and finally click OK, the setting will remain in the selected state, even though you deselected it and clicked both Apply and OK.
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.
){kind=link}
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 workstation he logs onto 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 removes all permissions from the folder and gives Administrators and the user Full Control. 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 will become handy when Microsoft adds support to 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.
){kind=link}
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. 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 reign 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.
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).
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 89 properties.
TIP
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
|
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 (1024) |
|
X |
|
|
Office |
physical- DeliveryOffice- Name |
Text (128) |
X |
|
|
|
Telephone number |
telephoneNumber |
Text (64) |
|
X |
This is the primary office phone number. |
|
Phone Number (Others) |
otherTelephone |
Text (64) |
|
|
These are the other office phone numbers. |
|
|
|
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 |
streetAddress |
Text (1024) |
|
|
|
|
P.O. Box |
postOfficeBox |
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 (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 |
otherMobile |
Text (64) |
|
|
A list of multiple values. |
|
(Others) |
|
|
|
|
|
|
Fax |
facsimile- |
Text (64) |
|
|
|
|
|
TelephoneNumber |
|
|
|
|
|
Fax Number (Others) |
otherFacsimile- TelephoneNumber |
Text (64) |
|
|
A list of multiple values. |
|
IP phone |
ipPhone |
Text |
|
X |
|
|
IP Phone Number (Others) |
otherIpPhone |
Text |
|
X |
A list of multiple values. |
|
Notes |
info |
Text (1024) |
|
|
|
|
Organization Tab |
|||||
|
Title |
title |
Text (64) |
|
|
|
|
Department |
department |
Text (64) |
|
|
|
|
Company |
company |
Text (64) |
|
|
|
|
Manager |
manager |
DN; you select a user or contact from list |
|
X |
Setting this doesn't give the manager any permissions. |
|
Direct reports |
directReports |
DN |
|
|
The current snap-in doesn't allow you to set this. |
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.
Other Operations to Manage Users and Contacts
After you have created a number of users and contacts 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, not contacts)
- Move
- Rename
- Delete
- Disable an account (only users, not contacts)
- Reset a password (only users, not contacts)
- Open a home page
- Send e-mail
Copying Users
You can copy an existing user to create a new user. You do this by right-clicking the user object and then selecting Copy. This launches a wizard similar to the one that enables you to create users from scratch.
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 32 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 userWorkstations (Logon Workstations) |
|
Copied but not visible in the snap-in (12 properties) |
Assistant, codePage, division, 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 (6 properties) |
description, directReports, facsimileTelephoneNumber (Fax), otherFacsimileTelephoneNumber (Fax Number (Others)), physicalDeliveryOfficeName (Office), and streetAddress (Street) |
|
Not a user property |
EmployeeType |
The remaining 12 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 32 copied properties. Table 3.13 lists six such properties.
NOTE
One of the properties defined to be copied when copying a user, the employee Type property, is not a user property at all.
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 and Contacts
Every now and then you may want to move some users or contacts from one OU to another. You move them within a domain by right-clicking the object and then selecting Move. Then you choose the destination from the OU tree that appears and click OK. Note that
Permissions that are assigned for the user object being moved move with the object.
Group policies and permissions that are inherited by the user 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 the Support Tools command-line tool MoveTree, which is discussed in Chapter 6.
Renaming Users and Contacts
You can rename a user 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 Figure 3.15 and 3.16 show.
){kind=link}
){kind=link}
Figure 3.15 When you rename a user, 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.16 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 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 is a security principal: It may have security group memberships and permissions for resources. Each user object 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 recreate 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 Accounts
The context menu for a user 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 6 months, you could freeze his user account but still not delete it.
When you see a red X icon on the user, the account is already disabled. In this case the context menu has an operation called "Enable Account."
Resetting User Passwords
You will never see your users' 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 and Contacts
If a user has a home page, and the corresponding property is defined in his user 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 and Contacts
If a user has an e-mail address, and the corresponding property is defined in her user object, you can send her e-mail with the "Send mail" operation in the context menu.