Managing existing user and group accounts - Windows Server 2012 R2 Essentials & Configuration (2014)

Windows Server 2012 R2 Essentials & Configuration (2014)

Chapter 10. Managing existing user and group accounts

§ Managing user contact information

§ Configuring the user’s environment settings

§ Setting account options and restrictions

§ Managing user profiles

§ Updating user and group accounts

§ Managing multiple user accounts

§ Troubleshooting logon problems

§ Viewing and setting Active Directory permissions

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.

Managing user contact information

Active Directory Domain Services (AD DS) 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 for anyone in the domain tree or forest to use as criteria to search for users and to create address book entries.

Setting contact information

You can set a user’s contact information in Active Directory Users And Computers by following these steps:

1. Double-tap or double-click the user name in Active Directory Users And Computers. This opens the account’s Properties dialog box.

2. Tap or click the General tab, shown in Figure 10-1. Set general contact information in the following boxes:

o First Name, Initials, Last Name. The user’s full name.

o Display Name. The user’s display name as shown in logon sessions and in Active Directory.

o Description. A description of the user.

o Office. The user’s office location.

o Telephone Number. The user’s primary business telephone number. If the user has other business telephone numbers you want to track, tap or click Other, and then enter additional phone numbers in the Phone Number (Others) dialog box.

o E-Mail. The user’s business email address.

o Web Page. The URL of the user’s home page, which can be on the Internet or on the company intranet. If the user has other webpages you want to track, tap or click Other, and then enter additional webpage addresses in the Web Page Address (Others) dialog box.

Screen shot of the Properties dialog box for a user in Active Directory Users and Computers, where you can configure general contact information for the user on the General tab.

Figure 10-1. Configure general contact information for the user on the General tab.

TIP

You must fill in the E-Mail and Web Page boxes if you want to use the Send Mail and Open Home Page features of Active Directory Users And Computers. For more information, see the “Updating user and group accounts” section later in this chapter.

3. Tap or click the Address tab. Set the user’s business or home address in the boxes provided. You’ll usually want to enter the user’s business address. You can then track the business locations and mailing addresses of users at various offices.

NOTE

You need to consider privacy issues before you enter users’ home addresses. Discuss the matter with your human resources and legal departments. You might also want to get user consent before releasing home addresses.

4. Tap or click the Telephones tab. Enter the primary telephone numbers that should be used to contact the user, such as home, pager, mobile, fax, and IP phone.

5. You can configure other numbers for each type of telephone number. Tap or click the associated Other buttons, and then enter additional phone numbers in the dialog box provided.

6. Tap or click the Organization tab. As appropriate, enter the user’s job title, department, and company.

7. To specify the user’s manager, tap or 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.

8. Tap or click Apply or OK to apply the changes.

You also can set contact information by using Active Directory Administrative Center. Double-tap or double-click the user name. In the account’s Properties dialog box, tap or click Organization to display the Organization panel. As Figure 10-2 shows, this panel provides a one-stop location for setting general, address, telephone, and organization details.

Screen shot of the Organization panel, showing general address, telephone, and organization details.

Figure 10-2. The Organization panel provides a one-stop location for setting general, address, telephone, and organization details.

The Web Page box sets the URL of the user’s home page, which can be on the Internet or on the company intranet. If the user has other webpages you want to track, tap or click Other Web Pages and then enter additional webpage addresses in the Web Page Address (Others) dialog box.

Under Phone Numbers, enter the primary telephone numbers that should be used to contact the user, such as main, home, mobile, fax, pager, and IP phone. You can configure other numbers for each type of telephone number. Tap or click Other Phone Numbers, and then enter additional phone numbers in the dialog box provided.

If the user has a manager set, this is listed in the Manager box. If no manager is set or you want to change the manager, tap or click the Edit button next to Manager to specify 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.

If the user has direct reports, they are listed under Direct Reports. You can add and remove direct reports by using the related Add and Remove buttons. To add a direct report, tap or click Add, specify the direct report in the Select User Or Contact dialog box, and then tap or click OK. To remove a direct report, tap or click the name in the list, and then tap or click Remove.

Searching for users and groups in Active Directory

Active Directory makes it easy for you to find users and groups in the directory, which you can do by following these steps:

1. In Active Directory Users And Computers, press and hold or right-click the domain or container, and then tap or click Find.

2. In the Find Users, Contacts, And Groups dialog box, the In list shows the previously selected domain or container. If you want to search the entire directory instead, select Entire Directory, or tap or click Browse to select a domain or container to search.

3. On the Users, Contacts, And Groups tab, enter the name of the user, contact, or group you want to search for.

4. Tap or click Find Now to begin the search. If matches are found, the search results are displayed, as shown in Figure 10-3. Otherwise, enter new search parameters and search again.

5. To manage an account, press and hold or right-click its entry. If you press and hold or right-click an account entry and then select Properties, you can open the account’s Properties dialog box.

Screen shot of the Find Users, Contacts, And Groups dialog box, where you can search for users in Active Directory.

Figure 10-3. Search for users in Active Directory, and then use the results to create address book entries.

You can also search for users and groups by using the filter and global search features of Active Directory Administrative Center. For more information, see the “Active Directory Administrative Center and Windows PowerShell” section in Chapter 8, “Core Active Directory administration.”

Configuring the user’s environment settings

User accounts can also have profiles, logon scripts, and home directories associated with them. To configure these optional settings, double-tap or double-click a display name in Active Directory Users And Computers, and then tap or click the Profile tab, shown in Figure 10-4. On the Profile tab, you can provide the following settings:

§ 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 in the “Managing user profiles” section later in this chapter.

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

§ 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 on a connected network drive. If the directory is available to the network, the user can access the directory from any computer on the network, which is a definite advantage.

Screen shot of the Properties dialog box for a user, showing the Profile tab, where you can create a user profile and configure the network environment for the selected user.

Figure 10-4. The Profile tab allows you to create a user profile and thereby configure the network environment for a user.

In Active Directory Administrative Center, you configure a user’s environment settings by using the options in the Profile panel. To configure these settings, double-tap or double-click a display name in Active Directory Administrative Center, and then tap or click Profile to display the Profile panel, shown in Figure 10-5.

Screen shot of the Profile panel, where you can configure the user‘s environment settings by setting the user‘s profile path, logon script, and home folder.

Figure 10-5. Configure the user’s environment settings by using the options in the Profile panel.

System environment variables

System environment variables are often helpful when you’re setting up the user’s environment, especially when you work with logon scripts. You use environment variables to specify path information that can be dynamically assigned. You use the following environment variables the most:

§ %SystemRoot%. The base directory for the operating system, such as C:\Windows. 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, 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 \Users\Mkg\Georgej. 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-6 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.

Screen shot of the Profile tab, showing the usage of environment variables to create an account based on another account.

Figure 10-6. When you use the Profile tab, environment variables can lessen the information you need to enter, especially when you create an account based on another account.

Logon scripts

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 Windows commands. However, logon scripts can be any of the following:

§ Windows PowerShell scripts with a .ps1 or other valid extension

§ Windows Script Host files with .vbs, .js, or another valid script extension

§ 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. 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 following these steps:

1. Open the user’s Properties dialog box in Active Directory Users And Computers, and then tap or click the Profile tab.

2. Enter the path to the logon script in the Logon Script box. Be sure to set the full path to the logon script, such as \\Zeta\User_Logon\Eng.vbs.

Creating logon scripts is easier than you might think, especially when you use the Windows command language. Just about any command you can enter 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\techmain

net use G: \\gamma\corpfiles

If these commands were in the user’s logon script, the user would have a network printer on LPT1 and a network drive on drive G. You can create similar connections in a script. With Microsoft Visual Basic Scripting Edition (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\techmain"

wNetwork.AddWindowsPrinterConnection printerPath

wNetwork.SetDefaultPrinter printerPath

wNetwork.MapNetworkDrive "G:", "\\gamma\corpfiles"

Set wNetwork = vbEmpty

Set printerPath = vbEmpty

Here, you use the AddWindowsPrinterConnection method to add a connection to the TechMain printer on Zeta, and you use the SetDefaultPrinter method to set the printer as the default for the user. You then use the MapNetworkDrive method to define a network drive on drive G.

Assigning home directories

Windows Server 2012 R2 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 File 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 drive or on a shared network drive. On a local drive, the directory is accessible only from a single workstation; however, 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, doing so is 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, follow these steps:

1. Open the user’s Properties dialog box in Active Directory Users And Computers, and then tap or click the Profile tab.

2. Select Local Path in the Home Folder section, and then enter the path to the home directory in the associated box, such as C:\Home\%UserName%.

To specify a network home directory, follow these steps:

1. Open the user’s Properties dialog box in Active Directory Users And Computers, and then tap or click the Profile tab.

2. In the Home Folder section, select the Connect option, 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.

3. Enter the complete path to the home directory by using Universal Naming Convention (UNC) notation, such as \\Gamma\User_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.

NOTE

If you don’t assign a home directory, Windows Server 2012 R2 uses the default local home directory.

Setting account options and restrictions

Windows Server 2012 R2 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.

Managing logon hours

Windows Server 2012 R2 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 typically 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 happens 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 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 their logon hours expire. Instead, Windows Server doesn’t allow them to make any new network connections.

Configuring logon hours

To configure the logon hours, follow these steps:

1. Open the user’s Properties dialog box. In Active Directory Users And Computers, tap or click the Account tab, and then tap or click Logon Hours. In Active Directory Administrative Center, tap or click Log On Hours in the Account panel.

2. You can now set the valid and invalid logon hours by using the Log On Hours dialog box, shown in Figure 10-7. In this dialog box, you can turn on or off each hour of the day or night:

o Hours that are allowed are filled in with a dark bar—you can think of these hours as being turned on.

o Hours that are disallowed are blank—you can think of these hours as being turned off.

Screen shot of the Log On Hours dialog box, showing the logon hours set from 1:00 A.M. to 11:00 P.M. Monday through Friday.

Figure 10-7. Configure logon hours for users.

3. To change the setting for an hour, tap or click it and then select either Logon Permitted or Logon Denied.

Table 10-1 lists Log On Hours dialog box options.

Table 10-1. Log On Hours Dialog Box Options

FEATURE

FUNCTION

All

Allows you to select all the time periods

Days of the 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:00 A.M. to 5:00 P.M. hours, you might want to allow a few hours on either side of the normal work hours. This lets early birds onto the system and allows night owls to keep working until they finish for the day.

Enforcing logon hours

To forcibly disconnect users when their logon hours expire, follow these steps:

1. Access the Group Policy Object (GPO) you want to work with, as detailed in the “Managing site, domain, and organizational unit policies” section in Chapter 6

2. Open the Security Options node by working your way down through the console tree. Expand Computer Configuration\Windows Settings\Security Settings. In Security Settings, expand Local Policies, and then select Security Options.

3. Double-tap or double-click Network Security: Force Logoff When Logon Hours Expire. This opens a Properties dialog box for the policy.

4. Select the Define This Policy Setting check box, and then tap or click Enabled. This turns on the policy restriction and enforces the logon hours. Tap or click OK.

Setting permitted logon workstations

Windows Server 2012 R2 has a formal policy that allows users to log on to systems locally. This policy controls whether a user can log on to the computer while sitting at the computer’s keyboard. By default, you can use any valid user account, including the Guest account, to log on locally to a workstation.

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

For domain users, you define permitted logon workstations by following these steps:

1. Open the user’s Properties dialog box. In Active Directory Users And Computers, tap or click the Account tab, and then tap or click Log On To. In Active Directory Administrative Center, in the Account panel, tap or click Log On To.

2. For the This User Can Log On To option, select The Following Computers, as shown in Figure 10-8.

Screen shot of the Log On To dialog box, where you can restrict access to workstations by specifying the permitted logon workstations.

Figure 10-8. To restrict access to workstations, specify the permitted logon workstations.

3. Enter the name of a permitted workstation, and then tap or click Add. Repeat this procedure to specify additional workstations.

4. If you make a mistake, select the erroneous entry and then tap or click Remove.

Setting dial-in and VPN privileges

Windows Server 2012 R2 lets you set remote access privileges for accounts on the Dial-In tab of the user’s Properties dialog box. These settings control access for dial-in and virtual private networks (VPNs). Remote access privileges are controlled through Network Policy Server (NPS) Network 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 need to follow these steps:

1. In Server Manager, add the role of Network Policy And Access Services.

2. To enable remote access connections, access the GPO for the site, domain, or organizational unit you want to work with, as specified in the “Managing site, domain, and organizational unit policies” section in Chapter 6. In the policy editor, expand User Configuration\Administrative Templates\Network. Select Network Connections, and then configure the Network Connections policies as appropriate for the site, domain, or organizational unit.

3. Configure remote access by 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.

REAL WORLD

Binaries needed to install roles and features are referred to as payloads. With Windows Server 2012 R2, you remove the payloads for roles and features that you are uninstalling by using the –Remove parameter of the Uninstall-WindowsFeature cmdlet. Restore a removed payload by using the Install-WindowsFeature cmdlet. By default, payloads are restored via Windows Update. Use the –Source parameter to restore a payload from a Windows Imaging (WIM) format mount point. In the following example, you restore the NPS and Routing And Remote Access Service (RRAS) binaries via Windows Update:

install-windowsfeature -name npas-policy-server

-includemanagementtools

install-windowsfeature -name remoteaccess

-includeallsubfeature -includemanagementtools

After you grant a user permission to access the network remotely, follow these steps to configure additional dial-in parameters on the Dial-in tab of the user’s Properties dialog box (as shown in Figure 10-9):

1. If the user must dial in from a specific phone number, select Verify Caller-ID, and then enter the telephone number from which this user is required to log on. Your telephone system must support Caller ID for this feature to work.

NOTE

In Active Directory Administrative Center, the Dial-in tab is accessed from the Extensions panel. Tap or click Extensions and then tap or click Dial-in.

2. Define callback parameters by using the following options:

o No Callback. Allows the user to dial in directly and remain connected. The user pays the long-distance telephone charges, if applicable.

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

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

NOTE

You shouldn’t assign callback numbers for users who dial in through a switchboard. The switchboard might not allow the user to properly connect to the network. You also shouldn’t use preset callback numbers with multilinked lines. The multilinked lines won’t function properly.

If necessary, you can also assign static IP addresses and static routes for dial-in connections by selecting Assign Static IP Addresses and Apply Static Routes, respectively.

Screen shot of the Dial-In tab in the Properties dialog box for a selected user, where you can control remote access to the network by changing dial-in privileges.

Figure 10-9. Dial-in privileges control remote access to the network.

Setting account security options

The Account tab/panel of the user’s Properties dialog box has the following options, which are designed to help you maintain a secure network environment and control how user accounts are used:

§ User Must Change Password At Next Logon. Forces the user to change his 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.

CAUTION

Selecting this option creates a security risk on the network. Although you might want to use Password Never Expires with administrator accounts, you usually shouldn’t use this option with normal user accounts.

§ Store Password Using Reversible Encryption. Saves the password as encrypted clear text.

§ Account Is Disabled. Disables the account, which prevents the user from accessing the network and logging on (Active Directory Users And Computers only).

§ Smart Card Is Required For Interactive Logon. Requires the user to log on to a workstation by using a smart card. The user can’t log on to the workstation by entering a logon name and password at the keyboard.

§ Account Is Sensitive And Cannot Be Delegated. Specifies that the user’s account credentials cannot be delegated by using Kerberos. Use this for sensitive accounts that should be carefully controlled.

§ Use Kerberos DES Encryption Types For This Account. Specifies that the user account will use Data Encryption Standard (DES) encryption.

§ This Account Supports Kerberos AES 128 Bit Encryption. Specifies that the account supports Advanced Encryption Standard (AES) 128-bit encryption.

§ This Account Supports Kerberos AES 256 Bit Encryption. Specifies that the account supports AES 256-bit encryption.

§ Do Not Require Kerberos Preauthentication. Specifies that the user account doesn’t need Kerberos preauthentication to access network resources. Preauthentication is part of the Kerberos V5 security procedure. The option to log on without it allows authentication from clients who are using a previous, or nonstandard, implementation of Kerberos.

REAL WORLD

AES is one of several encryption standards. Another encryption standard is Data Encryption Standard (DES). Most computers running earlier versions of Windows support DES.

Computers running current releases of Windows support AES, which provides more secure encryption than DES. Although US versions support both 128-bit and 256-bit AES, versions exported for use outside the United States typically support only 128-bit encryption.

Managing user profiles

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 restart the computer, go into VGA mode, and then reset the display manually. However, solutions for profile problems aren’t always this easy, and you might need to update the profile itself.

Windows Server 2012 R2 provides several ways to manage user profiles:

§ You can assign profile paths in Active Directory Users And Computers or Active Directory Administrative Center.

§ You can copy, delete, and change the type of an existing local profile with the System utility in Control Panel.

§ You can set system policies that prevent users from manipulating certain aspects of their environment.

Local, roaming, and mandatory profiles

In Windows Server 2012 R2, 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 have a profile on each computer. 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.

Working with roaming and mandatory profiles

To reduce the confusion caused by multiple profiles, you can create a profile that other computers can access. This type of profile is called a roaming profile. By default, 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 on any server running Windows. 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. This is because 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 she uses credential roaming with Digital ID Management Service (DIMS).

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

REAL WORLD

When a user has a mandatory profile, a temporary profile (meaning they are logged on as a guest), or a system profile, Windows 8.1 and Windows Server 2012 R2 block deployment of app packages by default. To permit app deployment when using one of these special profiles, you can enable Allow Deployment Operation In Special Profiles in the Administrative Templates policies for Computer Configuration under the Windows Components\App Package Deployment.

Restricting roaming profiles

Typically, users can access their roaming profiles no matter which computer they’re using within the domain. Windows 8.1 and Windows Server 2012 R2 allow you to modify this behavior by specifying from which computers a user can access roaming profiles and redirected folders. You do this by designating certain computers as primary computers and then configuring domain policy to restrict the downloading of profiles, redirected folders, or both to primary computers.

A primary computer is a computer that has been specifically designated as permitted for use with redirected data. You designate a primary computer by editing the advanced properties of a user or group in Active Directory and then setting the msDS-PrimaryComputer property to the name of the permitted computers. You then turn on the primary computer restriction for roaming profiles by enabling the Download Roaming Profiles On Primary Computers Only policy found in the Administrative Templates policies for Computer Configuration under System\User Profiles. You also can turn on the primary computer restriction for redirected folders by enabling the Redirect Folders On Primary Computers Only policy found in the Administrative Templates policies for Computer Configuration under System\Folder Redirection.

The goal of these policies is to protect personal and corporate data when users log on to computers other than the ones they use regularly for business. Data security is improved by not downloading and caching this data on computers a user doesn’t usually use. To set the msDS-PrimaryComputer of a user or group, follow these steps:

1. In Active Directory Administrative Center, open the Properties dialog box for the user or group and then tap or click Extensions. Or in Active Directory Users And Computers, ensure Advanced Features is selected on the View menu, and then open the Properties dialog box for the user or group.

2. On the Attribute Editor tab, scroll through the list of attributes. Tap or click msDS-PrimaryComputer and then tap or click Edit.

3. In the Multi-Valued String Editor dialog box, enter the name of the first primary computer and then click Add. Repeat this process until you’ve added all primary computers. Tap or click OK twice.

Creating local profiles

User profiles are maintained either in a default directory or in the location set by the Profile Path box in the user’s Properties dialog box. For Windows 7 and later, the default location for profiles is %SystemDrive%\Users\%UserName%\. A key part of the profile is the Ntuser.dat file in this location, such as C:\Users\wrstanek\Ntuser.dat. If you don’t change the default location, the user will have a local profile.

Creating roaming profiles

Roaming profiles are stored on servers running Windows. When users log on to multiple computers and use EFS, they 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 following these steps:

1. Create a shared directory on a server running Windows Server, and make sure that the group Everyone has at least Change and Read access.

2. In Active Directory Users And Computers or Active Directory Administrative Center, open the user’s Properties dialog box, and then access the Profile tab/panel. Enter the path to the shared directory in the Profile Path box. The path should have the form \\server name\profile folder name\user name. An example is \\Zeta\User_Profiles\Georgej, 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 \\Zeta\User_Profiles\Georgej\Ntuser.dat.

NOTE

You don’t usually need to create the profile directory. The directory is created automatically when the user logs on, and NTFS permissions are set so that only the user has access. You can select multiple user accounts for simultaneous editing. One way to do this is by holding down the Shift key or the Ctrl key when tapping or clicking the user names. Then when you right-click one of the selected users and then tap or click Properties, you can edit properties for all the selected users. Be sure to use %UserName% in the profile path, such as \\Zeta\User_Profiles\%UserName%.

3. 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, he will use the default local profile. Any changes the user makes to this profile are saved when the user logs off. The next time the user logs on, he has a personal profile.

Creating mandatory profiles

Mandatory profiles are stored on servers running Windows Server. If you want a user to have a mandatory profile, you define the profile as follows:

1. Follow steps 1 and 2 in the procedure in the previous section, “Creating roaming profiles.”

2. Create a mandatory profile by renaming the Ntuser.dat file as %UserName%\Ntuser.man. The next time the user logs on, she will have a mandatory profile.

NOTE

Ntuser.dat contains the registry settings for the user. When you change the extension for the file to Ntuser.man, you tell Windows Server to create a mandatory profile.

Using the System utility to manage local profiles

To manage local profiles, you need to log on to the user’s computer. Then you can use the System utility in Control Panel to manage local profiles. To view current profile information, tap or click System And Security in Control Panel and then tap or click System. On the System page in Control Panel, tap or click Advanced System Settings. In the System Properties dialog box, under User Profiles, tap or click Settings.

As shown in Figure 10-10, the User Profiles dialog box displays information about the profiles stored on the local system. You can use this information to help you manage profiles. The dialog box lists the following information:

§ 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 ADATUM\Wrstanek tells you that the original profile is from the domain adatum and the user account is wrstanek.

NOTE

If you delete an account but don’t delete the associated profile, an entry that says Account Deleted or Account Unknown might be displayed. Don’t worry—the profile is still available for copying if you need it, or you can delete the profile here.

§ 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 that the profile was last modified.

Screen shot of the User Profiles dialog box, showing existing local profiles.

Figure 10-10. The User Profiles dialog box lets you manage existing local profiles.

Creating a profile manually

Sometimes you might want to create the profile manually. 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, set up the account environment, and then use this account as the basis of other accounts.

Copying an existing profile to a new user account

If you have a base user account or a user account you want to use in a similar manner, you can copy an existing profile to the new user account. To do this, follow these steps to use the System Control Panel utility:

1. Start the System Control Panel utility. On the System page in Control Panel, tap or click Advanced System Settings. In the System Properties dialog box, under User Profiles, tap or click Settings.

2. Select the profile you want to copy from the Profiles Stored On This Computer list. (See Figure 10-10.)

3. Copy the profile to the new user’s account by tapping or clicking Copy To. In the Copy Profile To box, shown in Figure 10-11, enter the path to the new user’s profile directory. For example, if you were creating the profile for georgej, you’d enter \\Zeta\User_Profiles\Georgej.

Screen shot of the Copy To dialog box, where you can browse to find or enter a location for the profile directory, or assign access permissions to the user by selecting Change.

Figure 10-11. In the Copy To dialog box, enter the location of the profile directory and assign access permissions to the user.

4. Now you need to give the user permission to access the profile. In the Permitted To Use area, tap or click Change, and then use the Select User Or Group dialog box to grant access to the new user account.

TIP

If you know the name of the user or group you want to use, you can save time by entering it directly into the Name box.

5. Tap or click OK to close the Copy To dialog box. Windows then copies the profile to the new location.

Copying or restoring a profile

When you work with workgroups where each computer is managed separately, you 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 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 to replace a user’s roaming profile (when the roaming profile becomes corrupt), or you might need to copy an existing local profile to create a roaming profile in another domain.

You can copy a profile to a new location by following these steps:

1. Log on to the user’s computer, and start the System Control Panel utility. On the System page in Control Panel, tap or click Advanced System Settings. In the System Properties dialog box, under User Profiles, tap or click Settings.

2. In the Profiles Stored On This Computer list, select the profile you want to copy.

3. Copy the profile to the new location by tapping or clicking Copy To, and then enter the path to the new profile directory in the Copy Profile To box. For example, if you’re creating the profile for janew, you could enter \\Gamma\User_Profiles\Janew.

4. To give the user permission to access the profile, tap or click the Change button in the Permitted To Use area, and then grant access to the appropriate user account in the Select User Or Group dialog box.

5. When you have finished, tap or click OK to close the Copy To dialog box. Windows then copies the profile to the new location.

Deleting a local profile and assigning a new one

Profiles are accessed when a user logs on to a computer. Windows Server 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. Therefore, 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, follow these steps:

1. Log on to the user’s computer by using an account with administrator privileges, and then start the System utility.

2. Tap or click Advanced System Settings. In the System Properties dialog box, under User Profiles, tap or click Settings.

3. Select the profile you want to delete, and then tap or click Delete. When asked to confirm that you want to delete the profile, tap or 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 you’re deleting the profile from), the user needs to log off before you can delete the profile. In some instances, Windows Server marks profiles as in use when they aren’t. This typically results from an environment change for the user that wasn’t properly applied. To correct this, you might need to restart the computer.

The next time the user logs on, Windows Server 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 need to assign the user a new profile. To do this, you can do one of the following:

§ Copy an existing profile to the user’s profile directory. Copying profiles is covered in the “Copying or restoring a profile” section earlier in this chapter.

§ Update the profile settings for the user in Active Directory Users And Computers. Setting the profile path is covered in the “Creating roaming profiles” section earlier in this chapter.

Changing the profile type

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 tap or click Change Type. The options in this dialog box allow you to do the following:

§ Change a roaming profile to a local profile. If you want the user to always work with the local profile on this computer, specify that the profile is for local use. All changes to the profile are then made locally, and the original roaming profile is left untouched.

§ Change a local profile (defined originally as a roaming profile) to a roaming profile. The user will use the original roaming profile for the next logon. Windows Server then treats the profile like any other roaming profile, which means that any changes to the local profile are copied to the roaming profile.

NOTE

If these options aren’t available, the user’s original profile is defined locally.

Updating user and group accounts

Active Directory Administrative Center and Active Directory Users And Computers are the tools to use when you want to update a domain user or group account. If you want to update a local user or group account, 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:

1. In Active Directory Users And Computers, press and hold or right-click the domain name and then tap or click Find.

2. In the Find list, select Custom Search. This updates the Find dialog box to display a Custom Search tab.

3. In the In list, select the area you want to search. To search the enterprise, select Entire Directory.

4. On the Custom Search tab, tap or click Field to display a menu. Select User, and then select Logon Name (Pre–Windows 2000).

TIP

Be sure to select Logon Name (Pre–Windows 2000). Don’t use Logon Name. User accounts aren’t required to have a logon name, but they are required to have a pre–Windows 2000 logon name.

5. In the Condition list, select Present, and then tap or click Add. If prompted to confirm, tap or click Yes.

6. Tap or click Find Now. Active Directory Users And Computers gathers a list of all users in the designated area.

7. You can now work with the accounts one by one or several at a time. One way to select multiple resources not in sequence is to hold down the Ctrl key and then click each object you want to select. One way to select a series of resources at one time is to hold down the Shift key, click the first object, and then click the last object.

8. Press and hold or right-click a user account, and then select an action on the shortcut menu that’s displayed, such as Disable Account.

TIP

The actions you can perform on multiple accounts include Add To Group (used to add the selected accounts to a designated group), Enable Account, Disable Account, Delete, Move, and Send Mail. By choosing Properties, you can edit the properties of multiple accounts.

Use this same procedure to get a list of computers, groups, or other Active Directory resources. With computers, do a custom search, tap or click Field, choose Computer, and then select Computer Name (Pre–Windows 2000). With groups, do a custom search, tap or 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 and change and reset passwords. You’ll also learn how to troubleshoot account logon problems.

Renaming user and group accounts

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 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 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 Heidi Steen (heidis) gets married, she might want her user name to be changed to Heidi Jensen (heidij). When you change the user name from heidis to heidij, all associated privileges and permissions will reflect the name change. If you view the permissions on a file that heidis had access to, heidij now has access (and heidis is no longer listed).

To simplify the process of renaming user accounts, Active Directory Users And Computers provides a Rename User dialog box you can use to rename a user’s account and all the related name components. This dialog box currently isn’t in Active Directory Administrative Center, so you need to open the Properties dialog box and enter the new name properties for each box as appropriate.

To rename an account, follow these steps:

1. Find the user account you want to rename in Active Directory Users And Computers.

2. Press and hold or right-click the user account, and then tap or click Rename. Active Directory Users And Computers highlights the account name for editing. Press Backspace or Delete to erase the existing name, and then press Enter to open the Rename User dialog box, shown inFigure 10-12.

Screen shot of the Rename User dialog box, where you can change the Full Name, First Name, Last Name, Display Name, User Logon Name, and User Logon Name (pre-Windows 2000).

Figure 10-12. Fully rename an account.

3. Make the necessary changes to the user’s name information, and then tap or click OK. If the user is logged on, a warning prompt is displayed telling you that the user should log off and then log back on by using the new account logon name.

4. The account is renamed, and the SID for access permissions remains the same. You might still need to modify other data for the user in the account Properties dialog box, including the following:

o User Profile Path. Change the Profile Path in Active Directory Users And Computers, and then rename the corresponding directory on disk.

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

o 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. 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 can perform the tasks for you automatically.

Copying domain user accounts

Creating domain user accounts from scratch can be tedious. Instead of starting anew each time, you might want to use an existing account as a starting point. This option currently isn’t in Active Directory Administrative Center. To do this in Active Directory Users And Computers, follow these steps:

1. Press and hold or right-click the account you want to copy, and then tap or click Copy. This opens the Copy Object—User dialog box.

2. Create the account as you would any other domain user account, and 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 need and to discard the information that you need to update. The following properties are retained:

§ City, state, postal code, and country values set on the Address tab

§ Department and company set on the Organization tab

§ Account options set by using the Account Options boxes on the Account tab

§ Logon hours and permitted logon workstations

§ Account expiration date

§ Group account memberships

§ Profile settings

§ Dial-in privileges

NOTE

If you used environment variables to specify the profile settings in the original account, the environment variables are also used for the copy of the account. For example, if the original account used the %UserName% variable, the copy of the account will also use this variable.

Importing and exporting accounts

Windows Server 2012 R2 includes the Comma-Separated Value Directory Exchange (CSVDE) command-line utility for importing and exporting Active Directory objects. For import operations, CSVDE uses a comma-delimited file as the import source. You can run CSVDE by using these general parameters:

§ –i. Turns on import mode (rather than export, which is the default mode)

§ –f filename. Sets the source for an import or the output file for an export

§ –s servername. Sets the server to use for the import or export (rather than the default domain controller for the domain)

§ –v. Turns on verbose mode

For import operations, the source file’s first row defines the list of Lightweight Directory Access Protocol (LDAP) attributes for each object defined. Each successive line of data provides the details for a specific object to import and must contain exactly the attributes listed. Here is an example:

DN,objectClass,sAMAccoutName,sn,givenName,userPrincipalName

"CN=William Stanek,OU=Eng,DC=cpandl,DC=com",user,williams,William,Stanek,

williams@cpandl.com

Given this listing, if the import source file is named newusers.csv, you could import the file into Active Directory by entering the following command at an elevated command prompt:

csvde -i -f newusers.csv

For export operations, CSVDE writes the exported objects to a comma-delimited text file. You can also run CSVDE by using the general parameters listed previously as export-specific parameters, which include the following:

§ –d RootDN. Sets the starting point for the export, such as –d "OU=Sales,DC=domain,DC=local". The default is the current naming context.

§ –l list. Provides a comma-separated list of attributes to output.

§ –r Filter. Sets the LDAP search filter, such as –r "(objectClass=user)".

§ –m. Configures output for the Security Accounts Manager (SAM) rather than Active Directory.

To create an export file for the current naming context (the default domain), you could enter the following at an elevated command prompt:

csvde -f newusers.csv

However, this could result in a very large export dump. Thus, in most cases, you should specify at a minimum the RootDN and an object filter, as shown here:

csvde -f newusers.csv -d "OU=Service,DC=cpandl,DC=com" –r

"(objectClass=user)"

Deleting user and group accounts

Deleting an account permanently removes the account. After you delete an account, you can’t create an account with the same name to restore 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 2012 R2 doesn’t let you delete built-in user accounts or group accounts. You can remove other types of accounts by selecting them and pressing the Delete key, or by pressing and holding or right-clicking and selecting Delete. When prompted, tap or click Yes.

With Active Directory Users And Computers, one way to work with multiple accounts is by doing one of the following:

§ Select multiple user names for editing by holding down the Ctrl key and tapping or clicking 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 tapping or clicking the last account in the range.

NOTE

When you delete a user account, Windows Server 2012 R2 doesn’t delete the user’s profile, personal files, or home directory. If you want to delete these files and directories, you have to do it manually. If this is a task you perform routinely, you might want to create a 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.

Changing and resetting passwords

As an administrator, you 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, follow these steps:

1. Open Active Directory Users And Computers, Active Directory Administrative Center, or Local Users And Groups (whichever is appropriate).

2. Press and hold or right-click the account name, and then tap or click Reset Password or Set Password.

3. Enter a new password for the user and confirm it. The password should conform to the password-complexity policy set for the computer or domain.

4. User Must Change Password At Next Logon forces the user to change his password when the user logs on next. If you don’t want the user to have to change his password, clear this check box.

5. The Account Lockout Status On This Domain Controller property shows whether the account is locked or unlocked. If the account is locked, select Unlock The User’s Account to unlock it. Tap or click OK.

Enabling user accounts

User accounts can become disabled for several reasons. If a user forgets her password and tries to guess it, the user might exceed the account policy for bad logon attempts. Another administrator could have disabled the account while the user was on vacation, or the account could have expired. The following sections describe what to do when an account is disabled, locked out, or expired.

Account disabled

Active Directory Users And Computers and Active Directory Administrative Center depict disabled accounts with an arrow next to the user icon in the main view. When an account is disabled, follow these steps to enable it:

1. Open Active Directory Users And Computers, Active Directory Administrative Center, or Local Users And Groups (whichever is appropriate).

2. Press and hold or right-click the user’s account name. Select the appropriate option for the tool you are using, either Enable or Enable Account.

TIP

To quickly search the current domain for disabled accounts, enter dsquery user –disabled at a command prompt.

You can select multiple accounts at the same time and then use the options on the shortcut menu to enable or disable them. In Active Directory Users And Computers, enable all selected accounts by using the Enable Account option, or disable them by selecting Disable Account. In Active Directory Administrative Center, enable the accounts by using the Enable All option, or disable them by using Disable All.

Account locked out

When an account is locked out, follow these steps to unlock it:

1. Open Active Directory Users And Computers, Active Directory Administrative Center, or Local Users And Groups (whichever is appropriate).

2. Double-tap or double-click the user’s account name, and then select the Unlock Account check box. In Active Directory Users And Computers, this check box is on the Account tab.

In Active Directory Administrative Center, you can unlock multiple accounts at the same time. Simply select the accounts and then use the Unlock All option on the shortcut menu to unlock the accounts.

NOTE

If users frequently get locked out of their accounts, consider adjusting the account policy for the domain. You might want to increase the value for acceptable bad logon attempts and reduce the duration for the associated counter. For more information about setting account policy, see the “Configuring account policies” section in Chapter 9.

Account expired

Only domain accounts have an expiration date. (Local user accounts don’t have an expiration date.) When a domain account expires, follow these steps to change the expiration date:

1. Open Active Directory Users And Computers or Active Directory Administrative Center.

2. Double-tap or double-click the user’s account name. Open the Account tab or panel.

3. Under Account Expires, select End Of, and then tap or click the arrow on the related list box. With Active Directory Users And Computers, this displays a calendar you can use to set a new expiration date. With Active Directory Administrative Center, enter the date in the format shown.

Managing multiple user accounts

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 applied to all the selected accounts. When you press and hold or right-click the selected accounts, the following options are available:

§ Add To A Group. Displays the Select Group dialog box, which you can use to designate the groups the selected users should be members of

§ 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

§ Cut. Moves the selected accounts to a new container or organizational unit when you later select Paste

§ Delete. Deletes the selected accounts from the directory

§ Properties. Allows you to configure a limited set of properties for multiple accounts

In Active Directory Administrative Center, the options are similar. Add To Group, Disable All, Enable All, Unlock All, Move, Delete, and Properties are displayed.

The Properties option is the one you’ll examine in the sections that follow. As shown in Figure 10-13, the Properties For Multiple Items dialog box has a different interface from the Properties dialog box for standard users.

Screen shot of the Properties dialog box that is displayed when you select multiple users.

Figure 10-13. The Properties dialog box has a different interface when you work with multiple accounts.

NOTE

The examples shown here and in the sections that follow are for Active Directory Users And Computers. The management techniques are similar for Active Directory Administrative Center.

You should note the following differences:

§ Account name and password boxes are no longer available. You can, however, set the Domain Name System (DNS) domain name (user principal name [UPN] suffix), logon hours, computer restrictions, account options, account expiration, and profiles.

§ You must specifically select properties you want to work with by selecting the properties’ check boxes. After you do this, the value you enter in the box is applied to all the selected accounts.

Setting profiles for multiple accounts

You set the profile information for multiple accounts with the options on the Profile tab. One of the best reasons to work with multiple accounts in Active Directory Users And Computers is that you can set all their environment profiles by using a single interface. To do this, you 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, the users named bobs, janew, and ericl would all be assigned the following unique logon scripts: Bobs.cmd, Janew.cmd, and Ericl.cmd.

Figure 10-14 shows an example of setting environment profile information for multiple accounts. Note that the %UserName% variable is used to assign the user profile path, the user logon script name, and the home folder.

Screen shot of the Profile tab in the Properties dialog box when you select multiple users, where you can use the %UserName% environment variable to assign paths and file names based on individual user names.

Figure 10-14. Use the %UserName% environment variable to assign paths and file names based on individual user names.

Although you might want all users to have unique file names 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.

Setting logon hours for multiple accounts

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:

1. Select the accounts you want to work with in Active Directory Users And Computers.

2. Press and hold or right-click the highlighted accounts, and then tap or click Properties. In the Properties dialog box, tap or click the Account tab.

3. Select the Logon Hours check box, and then tap or click Logon Hours. You can then set the logon hours as discussed in “Configuring logon hours” earlier in the chapter.

NOTE

Active Directory Users And Computers doesn’t tell you the previous logon hour designations for the selected accounts, and it doesn’t warn you if the logon hours for the accounts are different.

Setting permitted logon workstations for multiple accounts

You set the permitted logon workstations for multiple accounts with the Logon Workstations dialog box. To open this dialog box, follow these steps:

1. Select the accounts you want to work with in Active Directory Users And Computers.

2. Press and hold or right-click the highlighted accounts, and then tap or click Properties. In the Properties dialog box, tap or click the Account tab.

3. Select the Computer Restrictions check box, and then tap or click Log On To.

4. If you want to allow the users to log on to any workstation, select All Computers. If you want to specify which workstations users are permitted to use, tap or click The Following Computers button, and then enter the names of the workstations. When you tap or click OK, these settings are applied to all the selected user accounts.

Setting logon, password, and expiration properties for multiple accounts

User accounts have many options that control logon, passwords, and account expiration. You set these values on 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 choices:

§ Enable the option by selecting its check box. For example, if you are working with the Password Never Expires option, a flag is set so that the password for the selected users won’t expire when you tap or click OK.

§ Don’t set the option, which effectively clears the option. For example, if you are working with the Account Is Disabled option, the accounts for the selected users are reenabled when you tap or click OK.

If you want to set the expiration date of the selected accounts, start by selecting Account Expires, and then select the appropriate expiration value. The Never option removes any current account expiration values. Select the End Of option to set a specific expiration date.

Troubleshooting logon problems

The previous section listed ways in which accounts can become disabled. Active Directory Users And Computers shows disabled accounts with a red warning icon next to the account name. To enable a disabled account, press and hold or right-click the account in Active Directory Users And Computers, and then tap or click Enable Account.

You can also search the entire domain for users with disabled accounts by entering dsquery user –disabled at a command prompt. To enable a disabled account from the command line, enter dsmod user UserDN –disabled no.

When a user account has been locked out by the Account Lockout policy, the account cannot be used for logging in until the lockout duration has elapsed or an administrator resets the account. If the account lockout duration is indefinite, the only way to unlock the account is to have an administrator reset it as discussed previously.

Windows Server 2012 R2 can record logon success and failure through auditing. When you enable account logon failure auditing, logon failure is recorded in the security log on the login domain controller. Auditing policies for a site, domain, or organizational unit GPO are found under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

When a user logs on to the network by using his domain user account, the account credentials are validated by a domain controller. By default, users can log on by using their domain user accounts even if the network connection is down or no domain controller is available to authenticate the user’s logon.

The user must have previously logged on to the computer and have valid, cached credentials. If the user has no cached credentials on the computer, and the network connection is down or no domain controller is available, the user will not be able to log on. Each member computer in a domain can cache up to 10 credentials by default.

Authentication can also fail if the system time on the member computer deviates from the logon domain controller’s system time by more than is allowed in the Kerberos Policy: Maximum Tolerance For Computer Clock Synchronization. The default tolerance is five minutes for member computers.

Beyond these typical reasons for an account being disabled, some system settings can also cause access problems. Specifically, you should look for the following:

§ A 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 applies only to the single workstation.

If the user is supposed to have access to the local system, configure the Logon Locally user right as described in the “Configuring user rights policies” section in Chapter 9.

§ A user gets a message that the system could not log on the user. 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, which means that only users with administrator privileges can log on to the domain.

§ A 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 might not be able to log on. See the “Local, roaming, and mandatory profiles” section earlier in this chapter.

§ A 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 is supposed to have access to this workstation, change the logon workstation information as described in the “Setting permitted logon workstations for multiple accounts” section earlier in the chapter.

Viewing and setting Active Directory permissions

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.

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 they’re defined in.

You can view and set standard security permissions for objects by following these steps:

1. Start Active Directory Users And Computers, and then display advanced options by choosing Advanced Features from the View menu. Next, press and hold or right-click the user, group, or computer account you want to work with, and then tap or click Properties.

2. In the Properties dialog box, tap or click the Security tab. As shown in Figure 10-15, a list of groups and users that have been assigned permissions on the object you previously selected is displayed. If the permissions are unavailable, it means the permissions are inherited from a parent object.

3. Users or groups with access permissions are listed in the Group Or User Names list box. You can change permissions for these users and groups by doing the following:

o Select the user or group you want to change.

o Grant or deny access permissions in the Permissions list.

o When inherited permissions are not available, override inherited permissions by selecting the opposite permissions.

4. To set access permissions for additional users, computers, or groups, tap or click Add. In the Select Users, Computers, Service Accounts, Or Groups dialog box, add users, computers, or groups.

5. In the Group Or User Names list, select the user, computer, or group you want to configure. In the check boxes in the Permissions area, allow or deny permissions. Repeat this step for other users, computers, or groups.

6. Tap or click OK when you have finished.

Screen shot of the Properties dialog box for the selected user, showing object permissions on the Security tab.

Figure 10-15. View and configure object permissions on the Security tab.

CAUTION

Only administrators who have a solid understanding of Active Directory and Active Directory permissions should manipulate object permissions. Setting object permissions incorrectly can cause problems that are very difficult to track down.

One way to view and set advanced security permissions for objects is by following these steps:

1. Start Active Directory Users And Computers, and then display advanced options by choosing Advanced Features from the View menu. Next, press and hold or right-click the user, group, or computer account you want to work with, and then tap or click Properties.

2. In the Properties dialog box, tap or click the Security tab, and then tap or click Advanced. A list of individual permission entries for the previously selected object is displayed. Permission entries that are inherited are listed as being inherited from a specific parent object.

3. To view and set the individual permissions associated with a permission entry, select the entry, and then tap or click Edit. You can change advanced permissions for the selected user or group by granting or denying access permissions in the Permissions list. When inherited permissions are not available, override inherited permissions by selecting the opposite permissions.

4. Tap or click OK twice when you have finished.