In a perfect world, you could create user and group accounts and never have to touch them again. Unfortunately, we live in the real world. After you create accounts, you’ll spend a lot of time managing them. This chapter provides guidelines and tips to make that task easier.
Active Directory is a directory service. When you create user accounts, those accounts can have detailed contact information associated with them. The contact information is then available to anyone in the domain tree or forest, and they can use it as criteria to search for users and to create address book entries.
You can set contact information for a user account by completing the following steps:
Double-click the user name in Active Directory Users And Computers. This opens the account’s Properties dialog box.
Click the General tab, shown in Figure 10-1. Use the following fields to set general contact information:
First Name, Initials, Last Name. Sets the user’s full name.
Display Name. Sets the user’s display name as seen in logon sessions and in Active Directory directory service.
Description. Sets a description of the user.
Office. Sets the user’s office location.
Telephone Number. Sets the user’s primary business telephone number. If the user has other business telephone numbers that you want to track, click Other and then use the Phone Number (Others) dialog box to enter additional phone numbers.
E-Mail. Sets the user’s business e-mail address.
Web Page. Sets the Uniform Resource Locator (URL) of the user’s home page, which can be either on the Internet or on the company intranet. If the user has other Web pages that you want to track, click Other and then use the Web Page Address (Others) dialog box to enter additional Web page addresses.
Figure 10-1. Use the General tab to configure general contact information for the user. This information can then be used in searches and address books.
Tip
The E-Mail and Web Page fields must be filled in if you want to use the Send Mail and Open Home Page features of Active Directory Users And Computers. For more information, see the section of this chapter entitled "Updating User and Group Accounts."
Click the Address tab. Use the fields provided to set the user’s business or home address. You’ll usually want to enter the user’s business address. In this way, you can track the business locations and mailing addresses of users at various offices.
Click the Telephones tab. Type the primary telephone numbers that should be used to contact the user, such as home, pager, mobile, fax, and Internet Protocol (IP) phone.
You can configure other numbers for each type of telephone number. Click the associated Others button and then use the dialog box provided to enter additional phone numbers.
Click the Organization tab. As appropriate, type the user’s title, department, and company.
To specify the user’s manager, click Change and then select the user’s manager in the Select User Or Contact dialog box. When you specify a manager, the user shows up as a direct report in the manager’s account.
Click Apply or OK to apply the changes.
Active Directory makes it easy for you to find users in the directory and then create address book entries using the search results. Normally, these are tasks that you’ll need to help users with. You do that by completing the following steps:
With the Classic Start Menu, click Start, point to Search, select For People, and then proceed to Step 2. With the Simple Start Menu, click Start, and then select Search. In the Search Results dialog box, click Other Search Options, click Printers, Computers, or People, and then click People In Your Address Book. This opens the Find People dialog box.
Click the Look In drop-down list, select Active Directory, and then type the name or email address of the user you want to search for.
Click Find Now to begin the search. If matches are found, the search results are displayed as shown in Figure 10-2. Otherwise, type new search parameters and search again.
You can view an account’s properties by selecting a display name and then clicking Properties.
You can add contact information to an address book by selecting a display name and then clicking Add To Address Book.
User accounts can also have profiles, logon scripts, and home directories associated with them. To configure these optional settings, double-click a display name in Active Directory Users And Computers and then click the Profile tab, as shown in Figure 10-3. In the Profile tab, you can set the following fields:
Figure 10-3. The Profile tab allows you to create a user profile. Profiles let you configure the network environment for a user.
Profile Path. The path to the user’s profile. Profiles provide the environment settings for users. Each time a user logs on to a computer, that user’s profile is used to determine desktop and control panel settings, the availability of menu options and applications, and more. Setting the profile path is covered later in this chapter in the section entitled "Managing User Profiles."
Logon Script. The path to the user’s logon script. Logon scripts are batch files that run whenever a user logs on. You use logon scripts to set commands that should be executed each time a user logs on. Chapter 4, discusses logon scripts in detail.
Home Folder. The directory the user should use for storing files. Here, you assign a specific directory for the user’s files as a local path on the user’s system or a connected network drive. If the directory is available to the network, the user can access the directory from any computer on the network, and this is a definite advantage.
System environment variables often come in handy when you’re setting up the user’s environment, especially when you work with logon scripts. You’ll use environment variables to specify path information that can be dynamically assigned. The environment variables you’ll use the most are the following:
%SystemRoot%. The base directory for the operating system, such as C:WINNT. Use it with the Profile tab of the user’s Properties dialog box and logon scripts.
%UserName%. The user account name, such as wrstanek. Use it with the Profile tab of the user’s Properties dialog box and logon scripts.
%HomeDrive%. The drive letter of the user’s home directory followed by a colon character, such as C:. Use it with logon scripts.
%HomePath%. The full path to the user’s home directory on the respective home drive, such as UsersMkgGeorgej. Use it with logon scripts.
%Processor_Architecture%. The processor architecture of the user’s computer, such as x86. Use it with logon scripts.
Figure 10-4 shows how you might use environment variables when creating user accounts. Note that by using the %UserName% variable, you allow the system to determine the full path information on a user-by-user basis. If you use this technique, you can use the same path information for multiple users and all the users will have unique settings.
Logon scripts set commands that should be executed each time a user logs on. You can use logon scripts to set the system time, network drive paths, network printers, and more. Although you can use logon scripts to execute one-time commands, you shouldn’t use them to set environment variables. Any environment settings used by scripts aren’t maintained for subsequent user processes. Also, you shouldn’t use logon scripts to specify applications that should run at startup. You should set startup applications by placing the appropriate shortcuts in the user’s Startup folder.
Normally, logon scripts contain Microsoft Windows commands. However, logon scripts can be:
Windows Script Host files with the .vbs, .js, or other valid script extensions.
Batch files with the .bat extension.
Command files with the .cmd extension.
Executable programs with the .exe extension.
One user or many users can use a single logon script, and, as the administrator, you control which users use which scripts. As the name implies, logon scripts are accessed when users log on to their accounts. You can specify a logon script by completing the following steps:
Note
You can specify logon and logoff scripts using other techniques. For complete details, see the section of Chapter 4 entitled "User and Computer Script Management."
Creating logon scripts is easier than you might think, especially when you use the Windows command language. Just about any command you can type into a command prompt can be set to run in a logon script. The most common tasks you’ll want logon scripts to handle are to set the default printers and network paths for users. You can set this information with the NET USE command. The following NET USE commands define a network printer and a network drive:
net use lpt1: \zeta echmain net use G: \gammacorpfiles
If these commands were in the user’s logon script, the user would have a network printer on LPT1 and a network drive on G. You can create similar connections in a script. With VBScript, you need to initialize the variables and objects you plan to use and then call the appropriate methods of the Network object to add the connections. Consider the following example:
Option Explicit
Dim wNetwork, printerPath
Set wNetwork = WScript.CreateObject("WScript.Network")
printerPath = \zeta echmain
wNetwork.AddWindowsPrinterConnection printerPath
wNetwork.SetDefaultPrinter printerPath
wNetwork.MapNetworkDrive "G:", \gammacorpfiles
Set wNetwork = vbEmpty
Set printerPath = vbEmptyHere, you use the AddWindowsPrinterConnection method to add a connection to the TechMain printer on CorpSvr02 and the SetDefaultPrinter method to set the printer as the default for the user. You then use the MapNetworkDrive method to define on network drive on G.
Windows Server 2003 lets you assign a home directory for each user account. Users can store and retrieve their personal files in this directory. Many applications use the home directory as the default for File Open and Save As operations, which helps users find their resources easily. The command prompt also uses the home directory as the initial current directory.
Home directories can be located on a user’s local hard disk drive or on a shared network drive. On a local drive the directory is accessible only from a single workstation. On the other hand, shared network drives can be accessed from any computer on the network, which makes for a more versatile user environment.
Tip
Although users can share home directories, it’s not a good idea. You’ll usually want to provide each user with a unique home directory.
You don’t need to create the user’s home directory ahead of time. Active Directory Users And Computers automatically creates the directory for you. If there’s a problem creating the directory, Active Directory Users And Computers will instruct you to create it manually.
To specify a local home directory, complete the following steps:
Access the user’s Properties dialog box in Active Directory Users And Computers, and then click the Profile tab.
Select Local Path, and then type the path to the home directory in the associated text box. Here’s an example: C:Home\%UserName%.
To specify a network home directory, complete the following steps:
Access the user’s Properties dialog box in Active Directory Users And Computers, and then click the Profile tab.
Select the Connect option in the Home Folder section, and then select a drive letter for the home directory. For consistency, you should use the same drive letter for all users. Also, be sure to select a drive letter that won’t conflict with any currently configured physical or mapped drives. To avoid problems, you might want to use Z as the drive letter.
Type the complete path to the home directory using the Universal Naming Convention (UNC) notation, such as: \GammaUser_Dirs\%UserName%. You include the server name in the drive path to ensure that the user can access the directory from any computer on the network.
Windows Server 2003 gives you many ways to control user accounts and their access to the network. You can define logon hours, permitted workstations for logon, dial-in privileges, and more.
Windows Server 2003 lets you control when users can log on to the network. You do this by setting their valid logon hours. You can use logon hour restrictions to tighten security and prevent system cracking or malicious conduct after normal business hours.
During valid logon hours, users can work as they normally do. They can log on to the network and access network resources. During restricted logon hours, users can’t work. They can’t log on to the network or make connections to network resources. If users are logged on when their logon time expires, what follows depends on the account policy you’ve set for them. Generally, one of two things happens to the user:
Forcibly disconnected. You can set a policy that tells Windows Server 2003 to forcibly disconnect users when their logon hours expire. If this policy is set, remote users are disconnected from all network resources and logged off the system when their hours expire.
Not disconnected. Users aren’t disconnected from the network when they enter the restricted hours. Instead, Windows Server 2003 simply doesn’t allow them to make any new network connections.
To configure the logon hours, follow these steps:
Access the user’s Properties dialog box in Active Directory Users And Computers, and then click the Account tab.
Click Logon Hours. You can now set the valid and invalid logon hours using the Logon Hours dialog box shown in Figure 10-5. In this dialog box, each hour of the day or night is a field that you can turn on and off.
To change the setting for an hour, click it. Then select either Logon Permitted or Logon Denied.
Logon Hours features are listed in Table 10-1.
Table 10-1. Logon Hours Features
Feature | Function |
|---|---|
All | Allows you to select all the time periods |
Day of week buttons | Allow you to select all the hours in a particular day |
Hourly buttons | Allow you to select a particular hour for all the days of the week |
Logon Permitted | Sets the allowed logon hours |
Logon Denied | Sets the disallowed logon hours |
Tip
When you set logon hours, you’ll save yourself a lot of work in the long run if you give users a moderately restricted time window. For example, rather than explicit 9–5 hours, you might want to allow a few hours on either side of the normal work hours. This will let the early birds onto the system and allow the night owls to keep working until they finish for the day.
If you want to forcibly disconnect users when their logon hours expire, complete the following steps:
Access the group policy with which you want to work, as detailed in the section of Chapter 4 entitled "Managing Site, Domain, and Organizational Unit Policies."
Access the Security Options node by working your way down through the console tree. Expand Computer Configuration, Windows Settings, and then Security Settings. In Security Settings, expand Local Policies and then select Security Options.
Double-click Network Security: Force Logoff When Logon Hours Expire. This opens a Properties dialog box for the policy.
Select the Define This Policy Setting check box and then click Enabled. This turns on the policy restriction and enforces the logon hours. Click OK.
Windows Server 2003 has a formal policy that allows users to log on to systems locally. This policy controls whether or not a user can sit at the computer’s keyboard and log on. By default, on workstations you can use any valid user account, including the guest account, to log on locally.
As you might imagine, allowing users to log on to any workstation is a security risk. Unless you restrict workstation use, anyone who obtains a user name and password can use it to log on to any workstation in the domain. By defining a permitted workstation list, you close the opening in your domain and reduce the security risk. Now not only must hackers find a user name and password, but they must also find the permitted workstations for the account.
Note
The permitted logon workstation restrictions affect only Windows NT, Windows 2000, and Windows XP computers in the domain. If any Windows 95 or Windows 98 computers are in the domain, they aren’t subject to the restrictions, which means you need only a valid user name and password to log on to these systems.
For domain users, you define permitted logon workstations by completing the following steps:
Access the user’s Properties dialog box in Active Directory Users And Computers and then click the Account tab.
Open the Logon Workstations dialog box by clicking Log On To.
Select The Following Computers, as shown in Figure 10-6.
Type the name of a permitted workstation and then click Add. Repeat this procedure to specify additional workstations.
If you make a mistake, select the erroneous entry and then click Edit or Remove, as appropriate.
Windows Server 2003 lets you set remote access privileges for accounts using the Dial-In tab of the user’s Properties dialog box. These settings control access for dial-in and virtual private network (VPN). As shown in Figure 10-7, remote access privileges are controlled through Remote Access Policy, by default. This is the preferred method of controlling remote access. You can explicitly grant or deny dial-in privileges by selecting Allow Access or Deny Access. In any event, before users can remotely access the network, you’ll need to complete the following steps:
Install Remote Access Services using the Configure Your Server Wizard.
To enable remote access connections, access the Group Policy Object (GPO) for the site, domain, or organizational unit you want to work with, as specified in the section of Chapter 4 entitled "Creating and Editing Site, Domain, and Organizational Unit Policies." In the Group Policy Object Editor (GPOE), expand User Configuration, Administrative Templates, and then Network. Then select Network Connections. Afterward, configure the Network Connections policies as appropriate for the site, domain, or organizational unit.
Configure remote access using Routing And Remote Access. In Computer Management, expand Services And Applications, and then select Routing And Remote Access. Configure Routing And Remote Access as appropriate.
After you grant a user permission to access the network remotely, configure additional dial-in parameters using the Dial-In tab of the user’s Properties dialog box, shown in Figure 10-7, by completing the following steps:
If the user must dial in from a specific phone number, select Verify Caller-ID and then type the telephone number from which this user is required to log on. Your telephone system must support Caller ID for this feature to work.
Define callback parameters using the following options:
No Callback. Allows the user to dial in directly and remain connected. The user pays the long-distance telephone charges, if applicable.
Set By Caller. Allows the user to dial in directly, and then the server prompts the user for a callback number. Once the number is entered, the user is disconnected and the server dials the user back at the specified number to reestablish the connection. The company pays the long-distance telephone charges, if applicable.
Always Callback To. Allows you to set a predefined callback number for security purposes. When a user dials in, the server calls back the preset number. The company pays the long-distance telephone charges, if applicable, and reduces the risk of an unauthorized person accessing the network.
If necessary, you can also assign static IP addresses and static routes for dial-in connections using Assign A Static IP Address and Apply Static Routes, respectively. For more information on IP addresses and routing, see Chapter 16.
The Account tab of the user’s Properties dialog box has many options designed to help you maintain a secure network environment. Use these options to control how user accounts are used and what options are available. The options are:
User Must Change Password At Next Logon. Forces the user to change his or her password when the user logs on next.
User Cannot Change Password. Doesn’t allow the user to change the account password.
Password Never Expires. Ensures that the account password never expires, which overrides the normal password expiration period.
Store Password Using Reversible Encryption. Saves the password as encrypted clear text.
Account Is Disabled. Disables the accounts, which prevents the user from accessing the network and logging on.
Smart Card Is Required For Interactive Logon. Requires the user to log on to a workstation using a smart card. The user can’t log on to the workstation by typing a logon name and password at the keyboard.
Account Is Trusted For Delegation. Specifies that the user account can request a Kerberos service ticket on behalf of a user and that it is trusted to use another user’s authentication credentials on behalf of that user. If a service account is running under a user account rather than as a local system, you can set a user account to execute procedures on behalf of a different account, allowing the user to mimic a client to gain access to network resources.
Account Is Sensitive And Cannot Be Delegated. Specifies that the user’s account credentials cannot be delegated using Kerberos. Use this for sensitive accounts that should be carefully controlled.
Use DES Encryption Types For This Account. Specifies that the user account will use Data Encryption Standard (DES) encryption.
Do Not Require Kerberos Preauthentication. Specifies that the user account doesn’t need Kerberos preauthentication to access network resources. Preauthentication is a part of the Kerberos v5 security procedure. The option to log on without it is available in order to allow authentication from clients using a previous, or nonstandard, implementation of Kerberos.
User profiles contain settings for the network environment, such as desktop configuration and menu options. Problems with a profile can sometimes prevent a user from logging on. For example, if the display size in the profile isn’t available on the system being used, the user might not be able to log on properly. In fact, the user might get nothing but a blank screen. You could reboot the machine, go into Video Graphics Adapter (VGA) mode, and then reset the display manually, but solutions for profile problems aren’t always this easy and you might need to update the profile itself.
Windows Server 2003 provides several ways to manage user profiles:
You can assign profile paths in Active Directory Users And Computers.
You can copy, delete, and change the type of an existing local profile with the System utility in the Control Panel.
You can set system policies that prevent users from manipulating certain aspects of their environment.
In Windows Server 2003, every user has a profile. Profiles control startup features for the user’s session, the types of programs and applications that are available, the desktop settings, and a lot more. Each computer that a user logs on to has a copy of the user’s profile. Because this profile is stored on the computer’s hard disk, users who access several computers will have a profile on each of them. Another computer on the network can’t access a locally stored profile, called a local profile, and, as you might expect, this has some drawbacks. For example, if a user logs on to three different workstations, the user could have three very different profiles, one on each system. As a result, the user might get confused about what network resources are available on a given system.
To solve the problem of multiple profiles and reduce confusion, you might want to create a profile that other computers can access. This type of profile is called a roaming profile. With a roaming profile users can access the same profile no matter which computer they’re using within the domain. Roaming profiles are server-based and can be stored only on a server running Windows 2000 or Windows Server 2003. When a user with a roaming profile logs on, the profile is downloaded, which creates a local copy on the user’s computer. When the user logs off, changes to the profile are updated both on the local copy and on the server.
Real World
When your organization uses the Encrypting File System (EFS) to make file access more secure, the use of roaming profiles becomes extremely important for users who log on to multiple computers. The reason for this is that encryption certificates are stored in user profiles and the encryption certificate is needed to access and work with the user’s encrypted files. If a user has encrypted files and doesn’t have a roaming profile, that user won’t be able to work with these encrypted files on another computer (unless they use credential roaming with digital identification management service.)
As an administrator, you can control user profiles or let users control their own profiles. One reason to control profiles yourself is to make sure that all users have a common network configuration, which can reduce the number of environment-related problems.
Profiles controlled by administrators are called mandatory profiles. Users who have a mandatory profile can make only transitory changes to their environment. Here, any changes that users make to the local environment aren’t saved, and the next time they log on, they’re back to the original profile. The idea is that if users can’t permanently modify the network environment, they can’t make changes that cause problems. A key drawback to mandatory profiles is that the user can log on only if the profile is accessible. If, for some reason, the server that stores the profile is inaccessible and a cached profile isn’t accessible, the user normally won’t be able to log on. If the server is inaccessible but a cached profile is accessible, the user receives a warning message and is logged on to the local system using the system’s cached profile.
Note
Mandatory profiles are deleted when you restart a computer running Windows XP. Users may receive an unrestricted temporary profile when they log on to a computer running Windows XP. This can occur if no network connection to the domain or a domain controller is available and if a cached profile isn’t available. See Microsoft Knowledge Base article 893243 for more details (support.microsoft.com/default.aspx?scid=kb;en-us;893243).
In Windows 2000 or later, user profiles are maintained either in a default directory or in the location set by the Profile Path field in the user’s Properties dialog box. The default location for profiles depends on the workstation configuration in the following way:
Windows Upgrade Installation. The user profile is located at %SystemRoot%Profiles\%UserName%Ntuser.dat, where %SystemRoot% is the root directory for the operating system, such as C:Winnt, and %UserName% is the user name, such as wrstanek.
New Installation of Windows. The user profile is located at %SystemDrive%Documents and Settings\%UserName%.%UserDomain%, such as F:Documents and Settingswrstanek.adatumNtuser.dat. If the user logs on to a domain controller, the profile might be located at %SystemDrive%Documents and Settings\%UserName%, such as F:Documents and SettingswrstanekNtuser.dat.
If you don’t change the default location, the user will have a local profile.
Roaming profiles are stored on servers running Windows 2000 or Windows Server 2003. When users log on to multiple computers and use EFS, they’ll need a roaming profile to ensure that the certificates necessary to read and work with encrypted files are available on computers other than their primary work computers.
If you want a user to have a roaming profile, you must set a server-based location for the profile directory by completing the following steps:
Create a shared directory on a server running Windows Server 2003 and make sure that the group Everyone has at least Change and Read access.
Access the user’s Properties dialog box in Active Directory Users And Computers, and then click the Profile tab. Type the path to the shared directory in the Profile Path field. The path should have the form \server nameprofile folder name user name. An example is \ZetaUser_ProfilesGeorgej, where Zeta is the server name, User_Profiles is the shared directory, and Georgej is the user name.
The roaming profile is then stored in the Ntuser.dat file in the designated directory, such as \ZetaUser_ProfilesGeorgejNtuser.dat.
Note
You don’t usually need to create the profile directory. The directory is created automatically when the user logs on and NTFS File System (NTFS) permissions are set so that only the user has access. You can select multiple user accounts for simultaneous editing by holding down the Shift or Ctrl key when clicking the user names. When you right-click one of the selected users and select Properties, you’ll be able to edit properties for all the selected users. Be sure to use %UserName% in the profile path, such as \ZetaUser_Profiles\%UserName%.
As an optional step, you can create a profile for the user or copy an existing profile to the user’s profile folder. If you don’t create an actual profile for the user, the next time the user logs on the user will use the default local profile. Any changes the user makes to this profile will be saved when the user logs off. Thus, the next time the user logs on, the user can have a personal profile.
Mandatory profiles typically are stored on a server. If you want a user to have a server-stored mandatory profile, you define the profile as follows:
Follow Steps 1–3 in the previous section, "Creating Roaming Profiles."
Create a mandatory profile by renaming the Ntuser.dat file as %UserName%Ntuser.man. The next time the user logs on, he or she will have a mandatory profile.
To manage local profiles, you’ll need to log on to the user’s computer. Afterward, you can use the System utility in the Control Panel to manage local profiles. To view current profile information, start the System utility, click the Advanced tab, and then, under User Profiles, click Settings.
As shown in Figure 10-8, the User Profiles dialog box displays various information about the profiles stored on the local system. You can use this information to help you manage profiles.
The fields have the following meanings:
Name. The local profile’s name, which generally includes the name of the originating domain or computer and the user account name. For example, the name ADATUMwrstanek tells you that the original profile is from the domain adatum and the user account is wrstanek.
Size. The profile’s size. Generally, the larger the profile, the more the user has customized the environment.
Type. The profile type, which is either local or roaming.
Status. The profile’s current status, such as whether it’s from a local cache.
Modified. The date when the profile was last modified.
Sometimes you might want to create the profile by hand. You do this by logging on to the user account, setting up the environment, and then logging off. As you might guess, creating accounts in this manner is time-consuming. A better way to handle account creation is to create a base user account. Here, you create the base user account, set up the account environment, and then use this account as the basis of other accounts.
If you have a base user account or a user account that you want to use in a similar manner, you can copy an existing profile to the new user account. To do this, you’ll use the System Control Panel utility and complete the following steps:
Start the System Control Panel utility, click the Advanced tab, and then under User Profiles, click Settings.
Select the existing profile you want to copy using the Profiles Stored On This Computer list (see Figure 10-8).
Copy the profile to the new user’s account by clicking the Copy To button. Next, type the path to the new user’s profile directory in the Copy Profile To field (see Figure 10-9). For example, if you were creating the profile for our user, georgej, you’d type \ZetaUser_ProfilesGeorgej.
Now you need to give the user permission to access the profile. Click the Change button in the Permitted To Use area, and then use the Select User Or Group dialog box to grant access to the new user account.
Close the Copy To dialog box by clicking OK. Windows Server 2003 then copies the profile to the next location.
When you work with workgroups where each computer is managed separately, you’ll often have to copy a user’s local profile from one computer to another. Copying a profile allows users to maintain environment settings when they use different computers. Of course, in a Windows Server 2003 domain, you can use a roaming profile to create a single profile that can be accessed from anywhere within the domain. The problem is that sometimes you might need to copy an existing local profile over the top of a user’s roaming profile (when the roaming profile is corrupt) or you might need to copy an existing local profile to a roaming profile in another domain.
You can copy an existing profile to a new location by doing the following:
Log on to the user’s computer, and then start the System Control Panel utility, click the Advanced tab, and, under User Profiles, click Settings.
Select the existing profile you want to copy using the Profiles Stored On This Computer list box.
Copy the profile to the new location by clicking the Copy To button, and then type the path to the new profile directory in the Copy Profile To field. For example, if you’re creating the profile for janew, you could type \GammaUser_Profilesanew.
Now you need to give the user permission to access the profile. Click the Change button in the Permitted To Use area, and then use the Select User Or Group dialog box to grant access to the appropriate user account.
When you’re finished, close the Copy To dialog box by clicking OK. Windows Server 2003 then copies the profile to the new location.
Profiles are accessed when a user logs on to a computer. Windows Server 2003 uses local profiles for all users who don’t have roaming profiles. Generally, local profiles are also used if the local profile has a more recent modification date than the user’s roaming profile. Because of this, sometimes you might need to delete a user’s local profile. For example, if a user’s local profile becomes corrupt, you can delete the profile and assign a new one. Keep in mind that when you delete a local profile that isn’t stored anywhere else on the domain, you can’t recover the user’s original environment settings.
To delete a user’s local profile, complete the following steps:
Log on to the user’s computer using an account with Administrator privileges.
Start the System utility, click the Advanced tab and then, under User Profiles, click Settings.
Select the profile you want to delete and then click Delete. When asked to confirm that you want to delete the profile, click Yes.
Note
You can’t delete a profile that’s in use. If the user is logged on to the local system (the computer from which you’re deleting the profile), the user will need to log off. In some instances, Windows Server 2003 marks profiles as in use when they aren’t. This is typically a result of an environment change for the user that hasn’t been properly applied. To correct this, you might need to reboot the computer.
Now the next time the user logs on, Windows Server 2003 does one of two things. Either the operating system gives the user the default local profile for that system or it retrieves the user’s roaming profile stored on another computer. To prevent the use of either of these profiles, you’ll need to assign the user a new profile. To do this, you can:
Copy an existing profile to the user’s profile directory. Copying profiles is covered in the next section.
Update the profile settings for the user in Active Directory Users And Computers. Setting the profile path is covered in this chapter in the section entitled "Configuring the User’s Environment Settings."
With roaming profiles the System utility lets you change the profile type on the user’s computer. To do this, select the profile and then click Change Type. The options in this dialog box allow you to:
Change a roaming profile to a local profile. If you want the user to always work with the local profile on this computer, set the profile for local use. Here, all changes to the profile are made locally and the original roaming profile is left untouched.
Change a local profile (that was defined originally as a roaming profile) to a roaming profile. The user will use the original roaming profile for the next logon. Afterward, Windows Server 2003 treats the profile like any other roaming profile, which means that any changes to the local profile are copied to the roaming profile.
Active Directory Users And Computers is the tool to use when you want to update a domain user or group account. If you want to update a local user or group account, you’ll need to use Local Users And Groups.
When you work with Active Directory, you’ll often want to get a list of accounts and then do something with those accounts. For example, you might want to list all the user accounts in the organization and then disable the accounts of users who have left the company. One way to perform this task is to follow these steps:
In Active Directory Users and Computers, right-click the domain name and then click Find.
From the Find selection list, select Custom Search. This updates the Find dialog box to display a Custom Search tab.
Using the In selection list, select the area you want to search. To search the enterprise, select Entire Directory.
In the Custom Search tab, click Field to display a shortcut menu, select User, and then select Logon Name (Pre-Windows 2000).
Using the Condition selection list, choose Present and then click Add. If prompted to confirm, click Yes.
Click Find Now. Active Directory Users and Computers gathers a list of all users in the designated area.
You can now work with the accounts one by one or several at a time. To select multiple resources not in sequence, hold down the Ctrl key and then click the left mouse button on each object you want to select. To select a series of resources at once, hold down the Shift key, select the first object, and then click the last object.
Right-click and then select an action from the shortcut menu that’s displayed, such as Disable Account.
Tip
The actions you can perform on multiple accounts include: Add Member To Group (used to add the selected accounts to a designated group), Enable Account, Disable Account, Delete, and Move. Although Properties is listed as a possible action on the right-click shortcut menu, you can’t edit the properties of multiple accounts in Windows 2000. This feature is only in Windows Server 2003.
Use this same procedure to get a list of computers, groups, or other Active Directory resources. With computers, use a custom search, click Field, choose Computer, and then select Computer Name (Pre-Windows 2000). With groups, use a custom search, click Field, choose Group, and then select Group Name (Pre-Windows 2000).
The sections that follow examine other techniques you can use to update (rename, copy, delete, and enable) accounts as well as to change and reset passwords. You’ll also learn how to troubleshoot account logon problems.
To rename an account, complete the following steps:
Access Active Directory Users And Computers or Local Users And Groups, whichever is appropriate for the type of account you’re renaming.
Right-click the account name, and then choose Rename. Type the new account name when prompted.
When you rename a user account, you give the account a new label. As discussed in Chapter 9, user names are meant to make managing and using accounts easier. Behind the scenes, Windows Server 2003 uses security identifiers (SIDs) to identify, track, and handle accounts independently from user names. SIDs are unique identifiers that are generated when accounts are created.
Because SIDs are mapped to account names internally, you don’t need to change the privileges or permissions on renamed accounts. Windows Server 2003 simply maps the SIDs to the new account names as necessary.
One common reason for changing the name of a user account is that the user gets married and decides to change her last name. For example, if Linda Martin (lindam) gets married, she might want her user name to be changed to Linda Randall (lindar). When you change the user name from lindam to lindar, all associated privileges and permissions will reflect the name change. Thus, if you view the permissions on a file that lindam had access to, lindar will now have access (and lindam will no longer be listed).
When you change lindam to lindar, the user properties and names of files associated with the account aren’t changed. This means you should update the account information. The information you might need to change includes:
Display Name. Change the user account’s Display Name in Active Directory Users And Computers.
User Profile Path. Change the Profile Path in Active Directory Users And Computers, and then rename the corresponding directory on disk.
Logon Script Name. If you use individual logon scripts for each user, change the Logon Script Name in Active Directory Users And Computers, and then rename the logon script on disk.
Home Directory. Change the home directory path in Active Directory Users And Computers, and then rename the corresponding directory on disk.
Note
Changing directory and file information for an account when a user is logged on might cause problems. So you might want to update this information after hours or ask the user to log off for a few minutes and then log back on. You can usually write a simple Windows script that will perform the tasks for you quickly and automatically.
Creating domain user accounts from scratch every time can be tedious. Instead of starting anew each time, you might want to use an existing account as a starting point. To do this, follow these steps:
Right-click the account you want to copy in Active Directory Users And Computers, and then choose Copy. This opens the Copy Object – User dialog box.
Create the account as you would any other domain user account. Then update the properties of the account, as appropriate.
As you might expect, when you create a copy of an account, Active Directory Users And Computers doesn’t retain all the information from the existing account. Instead, Active Directory Users And Computers tries to copy only the information you’ll need and to discard the information that you’ll need to update. The properties that are retained include
City, state, ZIP code, and country values set in the Address tab
Department and company set in the Organization tab
Account options set using the Account Options fields in the Account tab
Account expiration date
Group account memberships
Profile settings
Dial-in privileges
Deleting an account permanently removes the account. Once you delete an account, you can’t create an account with the same name to get the same permissions. That’s because the SID for the new account won’t match the SID for the old account.
Because deleting built-in accounts can have far-reaching effects on the domain, Windows Server 2003 doesn’t let you delete built-in user accounts or group accounts. You could remove other types of accounts by selecting them and pressing the Delete key or by right-clicking and selecting Delete. When prompted, click OK and then click Yes.
With Active Directory Users And Computers, you can select multiple accounts by doing one of the following:
Select multiple user names for editing by holding down the Ctrl key and clicking the left mouse button on each account you want to select.
Select a range of user names by holding down the Shift key, selecting the first account name, and then clicking the last account in the range.
Note
When you delete a user account, Windows Server 2003 doesn’t delete the user’s profile, personal files, or home directory. If you want to delete these files and directories, you’ll have to do it manually. If this is a task you perform routinely, you might want to create a Windows script that performs the necessary procedures for you. However, don’t forget to back up files or data that might be needed before you do this.
As an administrator, you’ll often have to change or reset user passwords. This usually happens when users forget their passwords or when their passwords expire.
To change or reset a password, complete the following steps:
Access Active Directory Users And Computers or Local Users And Groups, whichever is appropriate for the type of account you’re renaming.
Right-click the account name, and then select Reset Password or Set Password, as appropriate.
Type a new password for the user and confirm it. The password should conform to the password complexity policy set for the computer or domain.
Double-click the account name and then clear Account Is Disabled and Account Is Locked Out, whichever is appropriate and necessary. In Active Directory Users And Computers, these check boxes are in the Account tab.
User accounts can become disabled for several reasons. If a user forgets the password and tries to guess it, the user might exceed the account policy for bad logon attempts. Or another administrator could have disabled the account while the user was on vacation. Or the account could have expired. What to do when an account is disabled, locked out, or expired is described in the following sections.
When an account is disabled, complete the following steps:
Access Active Directory Users And Computers or Local Users And Groups, whichever is appropriate for the type of account you’re restoring.
Double-click the user’s account name and then clear the Account Is Disabled check box. In Active Directory Users And Computers, this check box is in the Account tab.
When an account is locked out, complete the following steps:
Access Active Directory Users And Computers or Local Users And Groups, whichever is appropriate for the type of account you’re restoring.
Double-click the user’s account name, and then clear the Account Is Locked Out check box. In Active Directory Users And Computers, this check box is in the Account tab.
Note
If users frequently get locked out of their accounts, consider adjusting the account policy for the domain. Here, you might want to increase the value for acceptable bad logon attempts and reduce the duration for the associated counter. For more information on setting account policy, see the section of Chapter 9 entitled "Configuring Account Policies."
You can use Active Directory Users And Computers to modify the properties of multiple accounts simultaneously. Any changes you make to the property settings are made for all the selected accounts.
You can select multiple accounts by doing the following:
Select multiple user names for editing by holding down the Ctrl key and clicking the left mouse button on each account you want to select.
Select a range of user names by holding down the Shift key, selecting the first account name, and then clicking the last account in the range.
When you’re finished selecting accounts for management, right-click to display a shortcut menu. The options available include:
Add To A Group. Displays the Select Group dialog box that you can use to designate the groups of which the selected users should be members.
Disable Account. Disables all the selected accounts.
Enable Account. Enables all the selected accounts.
Move. Moves the selected accounts to a new container or organizational unit.
Properties. Allows you to configure a limited set of properties for multiple accounts.
The Properties option is the one we’ll look at in the sections that follow. As shown in Figure 10-10, the Properties On Multiple Objects dialog box has a different interface than the standard user Properties dialog box. You should note the following changes:
Account name and password fields are no longer available. You can, however, set the Domain Name System (DNS) domain name (user principal name [UPN] suffix), logon hours, computer restrictions, accounts options, account expiration, and profiles.
You must specifically select fields that you want to work with by clicking their associated check boxes. After you do this, the value you enter in the field is applied to all the selected accounts.
Figure 10-10. The Properties dialog box has a different interface when you work with multiple accounts.
You set the profile information for multiple accounts using the options in the Profile tab. One of the best reasons to work with multiple accounts in Active Directory Users And Computers is to set all their environment profiles using a single interface. To do this, you will usually rely on the %UserName% environment variable, which lets you assign paths and file names that are based on individual user names. For example, if you assign the logon script name as %UserName%.cmd, Windows replaces this value with the user name—and it does so for each user you’re managing. Thus, bobs, janew, and ericl would all be assigned unique logon scripts and those scripts would be named Bobs.cmd, Janew.cmd, and Ericl.cmd.
An example of setting environment profile information for multiple accounts is shown in Figure 10-11. Note that the %UserName% variable is used to assign the user profile path, the user logon script name, and the home folder.
Figure 10-11. Use the %UserName% environment variable to assign paths and file names that are based on individual user names.
Although you might want all users to have unique files and paths, sometimes you want users to share this information. For example, if you’re using mandatory profiles for users, you might want to assign a specific user profile path rather than one that’s dynamically created.
When you select multiple user accounts in Active Directory Users And Computers, you can manage their logon hours collectively. To do this, follow these steps:
Select the accounts you want to work with in Active Directory Users And Computers.
Right-click and then select Properties. In the Properties dialog box, click the Account tab.
Choose the Logon Hours check box and then click Logon Hours. You can then set the logon hours as discussed in the section entitled "Configuring Logon Hours," earlier in this chapter.
You set the permitted logon workstations for multiple accounts using the Logon Workstations dialog box. To access this dialog box, follow these steps:
Select the accounts you want to work with in Active Directory Users And Computers.
Right-click and then select Properties. In the Properties dialog box, click the Account tab.
Choose Computer Restrictions and then click Log On To.
If you want to allow the users to log on to any workstation, select All Computers. Otherwise, if you want to specify which workstations users are permitted to use, select The Following Computers option button and then enter the names of up to eight workstations. When you click OK, these settings are applied to all the selected user accounts.
Users accounts have many options that control logon, passwords, and account expiration. You set these values in the Account tab of the Properties dialog box. When you work with multiple accounts, you must enable the option you want to work with by selecting the corresponding check box in the leftmost column. You now have two options:
Set the option by selecting its check box. This enables the option. For example, if you were working with the Password Never Expires option, a flag is set so that the password for the selected users won’t expire when you click OK.
Don’t set the option, which effectively clears the option. For example, if you were working with the Account Is Disabled option, the accounts for the selected users are reenabled when you click OK.
If you want to set the expiration date of the selected accounts, you start by selecting Account Expires and then you select the appropriate expiration value. The Never option removes any existing account expiration values. You use the End Of option to set a specific expiration date.
The previous section listed ways in which accounts can become disabled. Beyond the typical reasons for an account being disabled, some system settings can also cause access problems. Specifically, you should look for the following:
User gets a message that says that the user can’t log on interactively. The user right to log on locally isn’t set for this user and the user isn’t a member of a group that has this right.
The user might be trying to log on to a server or domain controller. If so, keep in mind that the right to log on locally applies to all domain controllers in the domain. Otherwise, this right only applies to the single workstation.
If the user should have access to the local system, configure the Logon Locally user right as described in the section of Chapter 9 entitled "Configuring User Rights Policies."
User gets a message that the system could not log the user on. If you’ve already checked the password and account name, you might want to check the account type. The user might be trying to access the domain with a local account. If this isn’t the problem, the global catalog server might be unavailable, and, as a result, only users with administrator privileges can log on to the domain.
User has a mandatory profile and the computer storing the profile is unavailable. When a user has a mandatory profile, the computer storing the profile must be accessible during the logon process. If the computer is shut down or otherwise unavailable, users with mandatory profiles may not be able to logon. See the section titled "Local, Roaming, and Mandatory Profiles," earlier in this chapter.
User gets a message saying the account has been configured to prevent the user from logging on to the workstation. The user is trying to access a workstation that isn’t defined as a permitted logon workstation. If the user should have access to this workstation, change the logon workstation information as described in the section of this chapter entitled "Setting Permitted Logon Workstations."
As you know from previous discussions, user, group, and computer accounts are represented in Active Directory as objects. Active Directory objects have standard and advanced security permissions. These permissions grant or deny access to the objects. You can view advanced security permissions for objects by completing the following steps:
Start Active Directory Users And Computers, and then display advanced options by selecting Advanced Features from the View menu. Next, right-click the user, group, or computer account with which you want to work.
Select Properties from the shortcut menu, and then click the Security tab in the Properties dialog box.
Select the user, computer, or group whose permissions you want to view in the Name list box. If the permissions are dimmed, it means the permissions are inherited from a parent object.
Advanced permissions for Active Directory objects aren’t as straightforward as other permissions. Different types of objects can have sets of permissions that are specific to the type of object. They can also have general permissions that are specific to the container in which they’re defined.
To set advanced permissions for Active Directory objects, follow these steps:
Start Active Directory Users And Computers and then right-click the user, group, or computer account with which you want to work.
Select Properties from the shortcut menu, and then click the Security tab in the Properties dialog box, as shown in Figure 10-12.
Users or groups with access permissions are listed in the Name list box. You can change permissions for these users and groups by doing the following:
Select the user or group you want to change.
Use the Permissions list box to grant or deny access permissions.
When inherited permissions are dimmed, override inherited permissions by selecting the opposite permissions.
To set access permissions for additional users, computers, or groups, click Add. Then use the Select Users, Computers, Or Groups dialog box to add users, computers, or groups.
Select the user, computer, or group you want to configure in the Name list box, click Add, and then click OK. Then use the fields in the Permissions area to allow or deny permissions. Repeat for other users, computers, or groups. Click OK when you’re finished.
