Microsoft Windows Server 2008 R2 : Administering user and computers

Managing users and computers is one of the day-to-day duties that will be performed on a regular basis. User and computer account objects in AD represent the true users and computers on your network. Both are used in unique ways to manage and secure your domain.

User accounts

User accounts are assigned to people who need to access your network. User accounts allow end users to log on to individual servers or the AD domain. As a best practice, every user should be assigned his or her own user account.

Local user accounts

Local user accounts are created on individual computers and give users access only to the computer in which they are created. Local user accounts do not provide access to any AD domain resources. If you deploy an AD domain, local user accounts should only be used sparsely as they must be managed and maintained on every individual computer they are created on. Local user accounts are good to use for providing temporary access to a server by someone who may not have a regular domain user account, or some application service accounts may require that you set them up as local use accounts.

Domain user accounts

Domain user accounts are created on a DC in the AD domain and provide access to domain resources. These resources can include servers, file shares, printers, Web sites, and AD settings. Domain user accounts are stored in the AD database, thus get replicated to all DCs in the domain. Domain User accounts are usually the preferred method for providing access to your Windows network.

Account usernames, passwords, and security policies

User accounts provide people access to your network. Giving someone a user account is like giving them a key to open certain doors within your organization. Behind those doors resides your company's data. To protect your organization's data, you need to ensure that the user's “keys” are not stolen or compromised. Each user account is assigned a username and password. The username and password combination is used to verify that the user is really who he says he is.

Usernames

Usernames are typically well known within an organization and not considered part of the “key.” Usernames are used to simply identify the user who is using his key. You will want to come up with a standard naming convention for all users on your network. This provides consistency and helps keep user accounts manageable. Some examples of naming conventions are:

• Firstname.lastname—John.Doe

• First initial of first name + last name—Jdoe

• Lastname + first initial of first name—Doej

You may want to consider naming the username the same as the user's e-mail alias. This can help ensure that users do not forget their username. The naming convention you use should make sense for your organization. Usernames should be easy for users to remember.

Passwords

A password (key) is assigned to each user account. The passwords ensure that only authorized users are accessing the network. For network access to be granted, each user must identify himself with his username and then enter a password that only the user assigned to the account knows. This combination validates that the person accessing the network to ensure they are truly who they say they are.

After log-on is complete, the user is granted access to resources in which his key allows him to access. If the user does not have access to a particular resource such as a file share, he will receive an access denied error when trying to access the resource.

User account properties

In addition to the username and password properties, domain user accounts include additional properties such as office location, office phone number, and e-mail address. These fields can be referenced (and populated) by various applications, including Microsoft Exchange Server, Office Communications Server, and SharePoint Server. Some of the additional user account properties are:

• First Name

• Last Name

• Initials

• Display Name

• Description

• Office

• Telephone Number

• E-mail

• Web page

• Physical Address Information (Street, City, State, Country)

• Organization Information (Job Title, Department, Company, Manager, Direct Reports)

The following exercise will walk you through setting up a user account in AD:

1. Log on to a DC and open Server Manager.

2. Expand the nodes Roles | Active Directory Domain Services | Active Directory Users and Computers | <your domain>.

3. Right-click on the User's container. Then, select the option New → User. The New Object User wizard will launch.

4. Type John and Doe in the First name and Last name fields, respectively. Type jdoe in the User logon name text box as seen in Figure 1. Then, click Next.

   

   Figure 1 Create New User Account Wizard.

5. Enter and confirm a password for the user. In our example, we will use Pass@word1. Leave the box selected for User must change password at the next logon. This will force John Doe to change his password the first time he logs on to the network. The following password options are available when creating user accounts:

   • User must change password at next logon—This setting forces the user to change his password during the first logon.

   • User cannot change password—This prevents the user from changing his password.

   • Password never expires—This exempts the user from any account policies that might force password changes after x number of days.

   • Account is disabled—This disables the user account. It cannot be logged onto until it is enabled again.

6. Click Next to continue.

7. Verify the account settings and click Finish to create the user account.

Best practices

Use a management server or local workstation for admin tasks

As a best practice, you should not perform day-to-day account management operations on a DC. Instead, you should set up a management server or a workstation with the administrative tools installed. You can then run the tools and connect to a DC remotely when creating new accounts. This provides a great level of security by limiting, who can actually log on to a DC.

Built-in user accounts

AD creates two default user accounts during installation. The Administrator and Guest accounts are created during the dcpromo process. The Administrator is the first and primary administrator to the domain. The Administrator account has full permissions to everything within the domain. The Guest account is disabled by default. The Guest account is a low-privileged account with limited permissions in the domain. It can be used to provide temporary access to network resources; however, as a best practice, you may want to create a limited user account instead. As mentioned earlier, each user should have a unique account on your domain, including people who need only temporary access.

Account security policies

User account security policies help ensure that user accounts are protected and properly secured. Using account security policies, you can set the following account policies for AD accounts:

• Password Policy

• Account Lockout Policy

• Kerberos Policy

The password policy allows you to configure requirements for user passwords. The password policy options are defined in Table 1.

Notes from the field

Multiple password policies

Windows Server 2008 R1 first introduced the ability to have multiple password policies in a single domain. This allows you to set up different password requirements assigned to different groups of users. For example, you can have a more strict password policy assigned to administrative-level accounts.

Table 1. Active Directory Domain Password Policy

Policy	Description	Default Setting
Enforce password history	By enabling this policy, users cannot use any of the previously remembered passwords. For example, using the default setting of 24, the user cannot use any of the previous 24 passwords when setting a new password	24 Passwords remembered
Maximum password age	By enabling this setting, passwords expire every x number of days. The number of days configured here define how often the users will be forced to change their passwords	42 days
Minimum password age	By enabling this setting, passwords require to remain the same for x number of days. For example, the default setting of 1 day requires that a user keep the same password for at least 1 day	1 day
Minimum password length	By enabling this setting, users must include at least x number of characters in their passwords. The longer the password the more secure it is. However, the longer the password the harder it is to remember. You should find a happy medium for your network. Most security best practices recommend at least 8 characters, though some organizations are asking users to begin using passphrases opposed to passwords. This can increase the character count dramatically, thus increasing account security	Seven characters
Password must meet complexity requirements	By enabling this setting, users must create passwords that are considered complex. Complex passwords require that the password use characters from three of the following four sets of characters: Upper Case Lower Case Number Special Characters such as #, @, ! Complex passwords cannot contain part or all of the user's full name or username	Enabled
Store passwords using reversible encryption	This setting essentially stores passwords in a plain text format. This is to provide backwards compatibility with some legacy applications but is not recommended.	Disabled

In addition to the password policy, you can set an account lockout policy. The account lockout policy “locks” the user's account after a defined number of failed password attempts. The account lockout prevents the user from logging onto the network for a period of time even if the correct password is entered. You should set an account lockout policy to help thwart off those who may attempt to compromise user accounts by brute force methods of guessing username and password combinations. The account lockout policy contains the following settings:

• Account lockout duration—This is the amount of time the account will remain locked out. This is commonly set to 20 or 30 min. An administrator can manually unlock the account at any time after it has been locked.

• Account lockout threshold—This is the number of invalid log-on attempts allowed before the account is locked out. After the defined threshold is reached, the account then becomes locked until the account lockout duration passes or an administrator manually unlocks the account.

• Reset account lockout counter after—This setting defines the number of minutes that must pass before the lockout counter will set itself to zero after an invalid log-on attempt has been detected.

The third account policy is the Kerberos Policy. This policy allows you to define Kerberos authentication settings.

• Enforce user logon restrictions—By enabling this setting, the Kerberos Key Distribution Center (KDC) will validate each ticket request against the user account rights policy.

• Maximum lifetime for a service ticket—This setting defines how long a service ticket is valid. After the ticket expires, the user account will be rejected by the resource and will have to request a new ticket from the KDC.

• Maximum lifetime for a user ticket—This setting defines the maximum age in minutes that the user ticket or ticket granting ticket (TGT) is valid.

• Maximum lifetime for user ticket renewal—This setting defines the number of days that a TGT can be renewed for continued use.

• Maximum tolerance for computer clock synchronization—Kerberos is time-sensitive protocol. This is a security feature to ensure that expired tickets cannot be used because of computer clocks being set incorrectly. This setting allows you to set the maximum amount of time difference Kerberos will allow between the domain and computers joined to the domain.

The account policies are set using the Group Policy Management console located in Server Manager. To manage the account policies, you need to edit the default domain group policy. Perform the following tasks to modify account policies:

1. Open Server Manager.

2. Expand the nodes Features | Group Policy Management | Forest: <your forest name> | Domains | <your domain name>.

3. Right-click the Default Domain Policy and choose the Edit option.

4. Expand the nodes Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies.

5. Select the policy you want to modify. After making changes, close the Group Policy Management Editor. Changes will be automatically saved.

Administering computer accounts

Just like users, computers also have accounts in AD and are automatically created when a computer joins the domain. Typically, the administrative burden for computer accounts is much less than users. Computer accounts do contain properties that can be populated such as information regarding who manages the system, its physical location, and delegation settings.

Best practices

Cleanup old computer accounts

Most organizations are disciplined about disabling and remove user accounts for users who no longer need access to the network. However, many companies fail to disable and remove old computer accounts from the AD. As a best practice, you need to implement process to disable and remove old computer accounts from your AD domain. This not only tightens security but also helps keep stale computer accounts from sitting around in your domain.