User Account Setup and Organization

The most important aspects of account creation are account setup and organization. Without the appropriate policies, you could quickly find that you need to rework all your user accounts. So before you create accounts, determine the policies you'll use for setup and organization.

Account Naming Policies

A key policy you'll need to set is the naming scheme for accounts. User accounts have display names and logon names . The display name (or full name) is the name displayed to users and the name referenced in user sessions. The logon name is the name used to log on to the domain. Logon names were discussed briefly in the section entitled "Logon Names, Passwords, and Public Certificates" in Chapter 8 , "Understanding User and Group Accounts."

Rules for Display Names

For domain accounts, the display name is normally the concatenation of the user's first name, middle initial, and last name, but you can set it to any string value. The display names must follow these rules:

Local display names must be unique on an individual computer.
Display names must be unique throughout a domain.
Display names must be no more than 64 characters long.
Display names can contain alphanumeric characters and special characters.

Rules for Logon Names

Logon names must follow these rules:

Local logon names must be unique on an individual computer, and global logon names must be unique throughout a domain.
Logon names can be up to 256 characters. However, it isn't practical to use logon names that are longer than 64 characters.
A pre “Windows 2000 logon name is given to all accounts, which by default is set to the first 20 characters of the Windows logon name. The pre “Windows 2000 logon name must be unique throughout a domain.
Users logging on to the domain with Windows 2000 or later can use their standard logon name or their pre “Windows 2000 logon name, regardless of the domain operations mode.
Logon names can't contain certain characters. Invalid characters are

" / \ [ ] ; = , + * ? < >

Logon names can contain all other special characters, including spaces, periods, dashes, and underscores. But it's generally not a good idea to use spaces in account names.

Note

Although Windows Server 2003 stores user names in the case that you enter, user names aren't case sensitive. For example, you can access the Administrator account with the user name Administrator, administrator, or ADMINISTRATOR. Thus, user names are case aware but not case sensitive.

Naming Schemes

You'll find that most small organizations tend to assign logon names that use the user's first or last name. But you can have several Toms, Dicks, and Janes in an organization of any size. So rather than having to rework your logon naming scheme when you run into problems, select a good naming scheme now and make sure other administrators use it. For naming accounts, you should use a consistent procedure that allows your user base to grow and limits the possibility of name conflicts, and ensures that your accounts have secure names that aren't easily exploited. If you follow these guidelines, the types of naming schemes you might want to use include

User's first name and last initial
User's first initial and last name
User's first initial, middle initial, and last name
User's first initial, middle initial, and first five characters of the last name
User's first name and last name

Security Alert

In tight security environments, you can assign a numeric code for the logon name. This numeric code should be at least 20 characters long. Combine this strict naming method with smart cards and smart card readers to allow users to quickly log on to the domain. Don't worry, users can still have a display name that humans can read.

Password and Account Policies

Domain accounts use passwords and public certificates to authenticate access to network resources. This section focuses on passwords.

Secure Passwords

A password is a case-sensitive string that can contain in excess of 127 characters with Active Directory directory service and up to 14 characters with Windows NT Security Manager. Valid characters for passwords are letters , numbers , and symbols. When you set a password for an account, Windows Server 2003 stores the password in an encrypted format in the account database.

But simply having a password isn't enough. The key to preventing unauthorized access to network resources is to use secure passwords. The difference between an average password and a secure password is that secure passwords are difficult to guess and crack. You make passwords difficult to crack by using combinations of all the available character types ”including lowercase letters, uppercase letters, numbers, and symbols. For example, instead of using happydays for a password you would use haPPy2Days&, Ha**y!dayS, or even h*PPY%d*ys.

Unfortunately, no matter how secure you initially make a user's password, eventually the user usually chooses the password. Because of this, you'll want to set account policies that define a secure password for your systems. Account policies are a subset of the policies configurable as a group policy.

Setting Account Policies

As you know from previous discussions, you can apply group policies at various levels within the network structure. You manage local group policies in the manner discussed in the section entitled "Managing Local Group Policies" in Chapter 4 , "Automating Administrative Tasks, Policies, and Procedures." You manage global group policies as explained in the section of Chapter 4 entitled "Managing Site, Domain, and Unit Policies."

Once you access the group policy container you want to work with, you can set account policies by completing the following steps:

As shown in Figure 9-1, access the Account Policies node within Group Policy. Expand Computer Configuration, then Windows Settings, and then Security Settings.

Figure 9-1. Use entries in the Account Policies node to set policies for passwords and general account use. The console tree shows the name of the computer or domain you're configuring. Be sure this is the appropriate network resource to configure.
You can now manage account policies through the Password Policy, Account Lockout Policy, and Kerberos Policy nodes.

Note

Kerberos policies aren't used with local computers. Kerberos policies are only available with group policies that affect sites, domains, and organizational units.
To configure a policy, double-click its entry or right-click it and select Properties. This opens a Properties dialog box for the policy.
For a local policy, the Properties dialog box is similar to the one shown in Figure 9-2. In domains, the effective policy for the computer is displayed but you can't change it. For stand-alone servers, you can change the local policy settings, however. Use the fields provided to configure the local policy. For a local policy, skip the remaining steps; those steps apply to global group policies.

Note

Site, domain, and organizational unit policies have precedence over local policies.

Figure 9-2. With local policies, you'll see the effective policy. For controllers and member servers, you must use the appropriate site, domain, or unit policy to change the settings.
For a site, domain, or organizational unit, the Properties dialog box is similar to the one shown in Figure 9-3.

Figure 9-3. Define and configure global group policies using their Properties dialog box.
All policies are either defined or not defined. That is, they are either configured for use or not configured for use. A policy that isn't defined in the current container could be inherited from another container.
Select or clear the Define This Policy Setting check box to determine whether a policy is defined.

Tip

Policies can have additional fields for configuring the policy. Often these fields are option buttons labeled Enabled and Disabled. Enabled turns on the policy restriction. Disabled turns off the policy restriction. Some policies are negations, meaning that by enabling them you are actually negating the item. For example, Disable Log On As A Service is the negation of the item Log On As A Service.

Specific procedures for working with account policies are discussed in the sections of this chapter entitled "Configuring Password Policies," "Configuring Account Lockout Policies," and "Configuring Kerberos Policies." This chapter's next section, "Viewing Effective Policies," teaches you more about viewing the effective policy on a local computer.

Viewing Effective Policies

When working with account policies and user rights assignment, you'll often want to view the effective policy on a system and see from where a particular policy setting originates. The effective policy is the policy being enforced and, as discussed in the section of Chapter 4 entitled "Group Policy Management," the effective policy depends on the order in which you apply the policies.

To view the effective policy on a system and see from where it originates, complete the following steps:

Open the Run dialog box by clicking Start and then clicking Run.
Type mmc in the Open field and then click OK. This opens the MMC.
In MMC, click File, and then click Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.
In the Standalone tab, click Add.
In the Add Standalone Snap-In dialog box, click Resultant Set Of Policy, and then click Add.
Close the Add Standalone Snap-In dialog box by clicking Close, and then click OK.
Right-click the Resultant Set Of Policy node and then select Generate RSoP Data. This starts the Resultant Set Of Policy Wizard. Click Next twice.
To view Computer Configuration policy settings for the local computer, select This Computer. Otherwise, select Another Computer and then type the name of the system to check. Click Browse if you want to use the Select Computer dialog box to find the system you want to use. Click Next.
To view User Configuration policy settings for the current user, select Current User. Otherwise, choose Select A Specific User and then select the account entry for a different user who's logged on to the system.
Click Next twice and then click Finish. Now when you access a policy node in the Resultant Set Of Policy console as shown in Figure 9-4, you'll see the effective setting, listed as the Computer Setting, and the source Group Policy Object.

Figure 9-4. Resultant Set of Policy shows the effective setting as well as the source Group Policy Object.

User Account Setup and Organization