Windows Server 2003 : Securing and Troubleshooting Authentication

Securing Authentication with Policy

Active Directory on Windows Server 2003 supports security policies to strengthen passwords and their use within an enterprise. Of course, you must design a password policy that is sufficiently daunting to attackers while being sufficiently convenient for users, so that they do not forget passwords (resulting in increased calls to the help desk) or, worse, write down their passwords.

A system running Windows Server 2003 as a member server maintains a policy related to its local user accounts. The local security policy can be managed using the appropriately named snap-in: Local Security Policy.

You will more often be concerned with the policy that affects domain user objects. Domain account policy is managed by the Default Domain Policy. To examine and modify this policy, open Active Directory Users and Computers. Select the domain node and choose Properties from the Action menu. Click the Group Policy tab. The GPO listed as the first, or top object link is the policy object that will drive the domain account policies. It is typically, and in best practice, the Default Domain Policy. Select that policy and click Edit. The Group Policy Object Editor console opens, focused on the Default Domain policy. Navigate to Computer Configuration, Windows Settings, Security Settings, Account Policies.

Password Policy

The domain password policies enable you to protect your network against password compromise by enforcing best-practice password management techniques. The policies are described in Table 1.

Table 1. Password Policies

Policy	Description
Enforce Password History	When this policy is enabled, Active Directory maintains a list of recently used passwords, and will not allow a user to create a password that matches a password in that history. The result is that a user, when prompted to change his or her password, cannot use the same password again, and therefore cannot circumvent the password lifetime. The policy is enabled by default, with the maximum value of 24. Many IT organizations use a value of 6 to 12.
Maximum Password Age	This policy determines when users will be forced to change their passwords. Passwords that are unchanged or infrequently changed are more vulnerable to being cracked and utilized by attackers to impersonate a valid account. The default value is 42 days. IT organizations typically enforce password changes every 30 to 90 days.
Minimum Password Age	When users are required to change their passwords—even when a password history is enforced—they can simply change their passwords several times in a row to circumvent password requirements and return to their original passwords. The Minimum Password Age policy prevents this possibility by requiring that a specified number of days must pass between password changes. Of course, a password can be reset at any time in Active Directory by an administrator or support person with sufficient permissions. But the user cannot change their password more than once during the time period specified by this setting.
Minimum Password Length	This policy specifies the minimum number of characters required in a password. The default in Windows Server 2003 is seven.
Passwords Must Meet Complexity Requirements	This policy enforces rules, or filters, on new passwords. The default password filter in Windows Server 2003 (passfilt.dll) requires that a password: Is not based on the user’s account name. Is at least six characters long. Contains characters from three of the following four character types: Uppercase alphabet characters (A...Z) Lowercase alphabet characters (a...z) Arabic numerals (0...9) Nonalphanumeric characters (for example, !$#,%) Windows Server 2003 enables this policy, by default.

Note

Configuring password length and complexity requirements does not affect existing passwords. These changes will affect new accounts and changed passwords after the policy is applied.

Account Lockout Policy

Account lockout refers, in its broadest sense, to the concept that after several failed logon attempts by a single user, the system should assume that an attacker is attempting to compromise the account by discovering its password and, in defense, should lock the account so no further logons may be attempted. Domain account lockout policies determine the limitations for invalid logons, expressed in a number of invalid logons in a period of time, and the requirements for an account to become unlocked, whether by simply waiting or contacting an administrator. Table 2 summarizes Account Lockout policies.

Table 2. Account Lockout Policies

Policy	Description
Account Lockout Threshold	This policy configures the number of invalid logon attempts that will trigger account lockout. The value can be in the range of 0 to 999. A value that is too low (as few as three, for example) may cause lockouts due to normal, human error at logon. A value of 0 will result in accounts never being locked out. The lockout counter is not affected by logons to locked workstations.
Account Lockout Duration	This policy determines the period of time that must pass after a lockout before Active Directory will automatically unlock a user’s account. The policy is not set by default, as it is useful only in conjunction with the Account Lockout Threshold policy. Although the policy accepts values ranging from 0 to 99999 minutes, or about 10 weeks, a low setting (5 to 15 minutes) is sufficient to reduce attacks significantly without unreasonably affecting legitimate users who are mistakenly locked out. A value of 0 will require the user to contact appropriate administrators to unlock the account manually.
Reset Account Lockout Counter After	This setting specifies the time that must pass after an invalid logon attempt before the counter resets to zero. The range is 1 to 99999 minutes, and must be less than or equal to the account lockout duration.

Cross-Platform Issues Organizations commonly implement a mix of directory service, server, and client platforms. In environments in which Windows 95, Windows 98, Windows Me, or Windows NT 4 participate in an Active Directory domain, administrators need to be aware of several issues. Passwords: While Windows 2000, Windows XP Professional, and Windows Server 2003 support 127-character passwords, Windows 95, Windows 98, and Windows ME support only 14-character passwords. Active Directory Client: The Active Directory Client can be downloaded from Microsoft’s web site and installed on Windows 95, Windows 98, Windows Me, and Windows NT 4 systems. It enables those platforms running previous editions of Windows to participate in many Active Directory features available to Windows 2000 Professional or Windows XP Professional, including the following: Site-awareness: a system with the Active Directory Client will attempt to log on to a domain controller in its site, rather than to any domain controller in the enterprise. Active Directory Service Interfaces (ADSI): use scripting to manage Active Directory. Distributed File System (Dfs): access Dfs shared resources on servers running Windows 2000 and Windows Server 2003. NT LAN Manager (NTLM) version 2 authentication: use the improved authentication features in NTLM version 2. Active Directory Windows Address Book (WAB): property pages Active Directory search capability integrated into the Start–Find or Start–Search commands. The following functionalites, supported on Windows 2000 Professional and Windows XP Professional, are not provided by the Active Directory client on Windows 95, Windows 98, and Windows NT 4: Kerberos V5 authentication Group Policy or Change and Configuration Management support Service principal name (SPN), or mutual authentication. In addition, you should be aware of the following issues in mixed environments: Windows 98 supports passwords of up to 14 characters long. Windows 2000, Windows XP, and Windows Server 2003 can support 127-character passwords. Be aware of this difference when configuring passwords for users who log on using Windows 98. Without the Active Directory client, users on systems using versions of Windows earlier than Windows 2000 can change their password only if the system has access to the domain controller performing the single master operation called primary domain controller (PDC) emulator. To determine which system is the PDC emulator in a domain, open Active Directory Users And Computers, select the domain node, choose the Operations Masters command from the Action menu, and then click the PDC tab. If the PDC emulator is unavailable (that is, if it is offline or on the distant side of a downed network connection), the user cannot change his or her password. As you have learned in this chapter, user objects maintain two user logon name properties. The Pre-Windows 2000 logon name, or SAM name, is equivalent to the user name in Windows 95, Windows 98, or Windows NT 4. When users log on, they enter their user name and must select the domain from the Log On To box. In other situations, the user name may be entered in the format <DomainName>\<UserLogonName>. Users logging on using Windows 2000 or later platforms may log on the same way, or they may log on using the more efficient UPN. The UPN takes the format <UserLogonName>@<UPN Suffix>, where the UPN suffix is, by default, the DNS domain name in which the user object resides. It is not necessary to select the domain from the Log On To box when using UPN logon. In fact, the box becomes disabled as soon as you type the “@” symbol.

Auditing Authentication

If you are concerned that attacks may be taking place to discover user passwords, or to troubleshoot authentication problems, you can configure an auditing policy that will create entries in the Security log that may prove illuminating.

Audit Policies

The following policies are located in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy node of Group Policy Object Editor (or the Local Security Policy snap-in). You can configure auditing for successful or failed events.

• Audit Account Logon Events This policy audits each instance of user logon that involves domain controller authentication. For domain controllers, this policy is defined in the Default Domain Controllers GPO. Note, first, that this policy will create a Security log entry on a domain controller each time a user logs on interactively or over the network using a domain account. Second, remember that to evaluate fully the results of the auditing, you must examine the Security logs on all domain controllers, because user authentication is distributed among each domain controller in a site or domain.

• Audit Account Management Configures auditing of activities including the creation, deletion, or modification of user, group, or computer accounts. Password resets are also logged when account management auditing is enabled.

• Audit Logon Events Logon events include logon and logoff, interactively or through network connection. If you have enabled Audit Account Logon Events policy for successes on a domain controller, workstation logons will not generate logon audits. Only interactive and network logons to the domain controller itself generate logon events. Account logon events are generated on the local computer for local accounts and on the domain controller for network accounts. Logon events are generated wherever the logon occurs.

Tip

Keep track of the distinction between Account Logon and Logon events. When a user logs on to their workstation using a domain account, the workstation registers a Logon event and the domain controller registers an Account Logon event. When the user connects to a network server’s shared folder, the server registers a Logon event and the domain controller registers an Account Logon event.

Security Event Log

Once you have configured auditing, the security logs will begin to fill with event messages. You can view these messages by selecting Security from the Event Viewer snapin, and then double-clicking the event.

Tip

Remember that Account Logon events will need to be monitored on each domain controller. Logon events must be monitored on all systems.

Administering User Authentication

When users forget their passwords, are transferred or terminated, you will have to manage their user objects appropriately. The most common administrative tasks related to user account security are unlocking an account, resetting a password, disabling, enabling, renaming, and deleting user objects.

Unlocking a User Account

The account lockout policy requires that when a user has exceeded the limit for invalid logon attempts, the account is locked and no further logons can be attempted for a specified period of time, or until an administrator has unlocked the account.

To unlock a user, select the user object and, from the Action menu, choose Properties. Click the Account tab and clear the check box: Account Is Locked Out.

Resetting User Passwords

If a user forgets his or her password, you must reset the password. You do not need to know the user’s old password to do so. Simply select the user object and, from the Action menu, choose the Reset Password command. Enter the new password twice to confirm the change, and as a security best practice, select the User Must Change Password At Next Logon option.

Disabling, Enabling, Renaming, and Deleting User Objects

Personnel changes may require you to disable, enable, or rename a user object. The process for doing so is similar for each action. Select the user and, from the Action menu, choose the appropriate command, as follows:

• Disabling And Enabling A User When a user does not require access to the network for an extended period of time, you should disable the account. Reenable the account when the user needs to log on once again. Note that the only one of the commands to Disable or Enable will appear on the Action menu depending on the current status of the object.

• Deleting A User When a user is no longer part of your organization, and there will not soon be a replacement, delete the user object. Remember that by deleting a user, you lose its group memberships and, by deleting the SID, its rights and permissions. If you recreate a user object with the same name, it will have a different SID, and you will have to reassign rights, permissions, and group memberships.

• Renaming A User You will rename a user if a user changes their name, for example through marriage, or in the event that a user is no longer part of your organization, but you are replacing that user and you want to maintain the rights, permissions, group memberships, and most of the user properties of the previous user.

  Tip

  Be certain to understand the difference between disabling and deleting an object; and between enabling and unlocking a user.

  
  

1: Configure Policies

1.	Open Active Directory Users And Computers.
2.	Select the domain node, Contoso.com
3.	From the Action menu, choose Properties.
4.	On the Group Policy tab, select Default Domain Policy and then click Edit.
5.	Navigate to Computer Configuration, Windows Settings, Security Settings, Account Policies, and finally Account Lockout Policy.
6.	Double-click the Account Lockout Duration policy.
7.	Select the Define This Policy Setting check box.
8.	Type 0 for the duration, then click Apply. The system will prompt you that it will configure the account lockout threshold and reset counter policies. Click OK.
9.	Click OK to confirm the settings, and then click OK to close the Policy dialog box.
10.	Confirm that the Account Lockout Duration policy is zero, the threshold is 5, and the reset counter policy is 30 minutes.
11.	Close the Group Policy Object Editor window.
12.	Click OK to close the Properties dialog box for the contoso.com domain.
13.	Select the Domain Controllers container, under the domain node.
14.	From the Action menu, click Properties.
15.	On the Group Policy tab, select Default Domain Controllers Policy and click Edit.
16.	Navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, and finally Audit Policy.
17.	Double-click the Audit Account Logon Events policy.
18.	Select Define These Policy Settings, select both Success and Failure, and then click OK.
19.	Double-click the Audit Logon Events policy.
20.	Select Define These Policy Settings, select both Success and Failure, and then click OK.
21.	Double-click the Audit Account Management policy.
22.	Select Define These Policy Settings, select Success, and then click OK.
23.	Close the Group Policy Object Editor window.
24.	Click OK to close the Properties dialog box for the Domain Controllers Properties dialog box.

 2: Generate Logon Events

1.	Log off of Server01.
2.	Generate two logon failure events by attempting to log on twice with the username sbishop and an invalid password.
3.	Log on correctly as sbishop.
4.	Log off.

3: Generate Account Management Events

1.	Log on as Administrator.
2.	Open Active Directory Users And Computers.
3.	In the tree pane, navigate to and select the Employees OU.
4.	In the details pane, select Scott Bishop’s user object, and then click the Action menu.
5.	Click the Reset Password command.
6.	Enter and confirm a new password for Scott Bishop, and then click OK.

 4: Examine Authentication Security Event Messages

1.	Open the Computer Management console from the Administrative Tools group.
2.	Expand Event Viewer and select Security.
3.	Make sure the Category column is wide enough that you can identify the types of events that are logged.
4.	Explore the events that have been generated by recent activity. Note the failed logons, the successful logons, and the resetting of Scott Bishop’s password.