Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Authentication Management via Group Policy

Group Policy can be used to strengthen authentication practices for Windows. Password, account lockout policy, and Kerberos policies should be used, and many restrictions are also set in Group Policy Security Options. NTLM process restrictions, for example, are tightened via the Security Options, as described previously in this chapter in the section "LM/NTLM Configuration." Individual user account restrictions can be used to further manage and secure the authentication process.

Account Policy

The Group Policy Account Policy options determine the specifics of the Domain Password policy (see Figure 2-11 and Table 2-7), the Account Lockout policy (see Figure 2-12 and Table 2-8), and, in a domain, the Kerberos policy. Individual User Account policy determines the specific restrictions placed on an individual account. If a conflict exists, the individual user account policy has precedence.

Figure 2-11. The Domain Password policy.

[View full size image]

Table 2-7. Password Policy
Option	Description	Recommendations
Enforce password history	Determines the number of unique passwords associated with a user account before a password can be reused. Default: 24.	Retain this setting to prevent password reuse. It does no good to change a password if a user changes it back to the same thing.
Maximum password age	Number of days before which a user must change his password (1999). Default: 42.	Reduce the number of days to tighten the policy.
Minimum password age	Number of days before a password can be changed (0998). Default: 1 on domain controllers, 0 on servers.	Enforce this policy to make password history work. If users can immediately change their passwords, many will do so as many times as necessary to get back to their old passwords. If the minimum password age is set, it is unlikely that users will wait a day or more between password changes.
Minimum password length	The least number of characters a password must contain (0128). Default: 7 on domain controllers, 0 on servers.	Although a longer password is more secure, you must remember that longer passwords are harder to remember and may result in more of them being written down where anyone can see them. Each added character in length requires geometrically increasing times for brute force password attacks to work. A password of 15 characters is resistant to most brute-force password crackers because of its length and because an LM version of the password cannot be created.
Passwords must meet complexity requirements	If enabled, a password must not contain any part of a user's name, must be at least 6 characters, and must be composed of three or four categories (uppercase and lowercase letters, numbers, and special characters). Default: enabled on domain controllers, disabled on standalone servers.	Enforce this setting but train users in how to create strong passwords. A password such as Dogs32 meets this requirement but will be cracked in seconds by readily available cracking tools. Putting numbers within the password, not having any part of password be a word, making the password longer, and including special characters will make it harder to crack. Many argue that password length is more important than complexity and advise teaching users how to create passphrases in order to make long passwords easier to remember.
Store passwords using reversible encryption	If enabled, passwords are stored for all practical purposes in plain text. This setting is required by some applications that do not understand the Microsoft algorithms and need to be able to determine if a correct password was entered. Examples are CHAP and Digest authentication. Disabled by default.	Do not enable this setting. Seek workarounds for applications that require this setting or do not use these applications. If you must use these applications, restrict their use to only those users necessary and instead of setting this here, do so within individual user account restrictions.

Figure 2-12. Account Lockout Policy.

[View full size image]

Table 2-8. Account Lockout Policy
Option	Description	Recommendation
Account Lockout Duration	Set the number of minutes an account will remain locked out. Range: 099999 minutes (10 weeks). A setting of 0 means the account must be manually unlocked by an administrator. Default is none.	Must be greater than or equal to the reset time. Set the time low enough that a user can get back to work within a reasonable time. However, making the time too short might allow an automated attack to take advantage of it. A time of 15 to 30 minutes is probably adequate. Require administrative reset in high-security situations.
Account Lockout Threshold	The number of times a bad password may be entered before an account is locked out. Bad password entry at screen saver logons also counts toward this total. Range 1999. Default is none.	Set at 30 or so. This is high enough that most users will never have their account locked out, yet low enough that a brute force attack will lock the account before successfully deducing the password in most cases. Setting a high number for the threshold also avoids the problem created due to the way password attempts are evaluated. A single incorrect password may trigger a number of recorded bad password attempts because the password attempt is forwarded to the PDC emulator for the domain. Windows Server 2003 and Windows 2000 SP3 limit this effect (see KB article 272065), but even so, up to 10 requests may be forwarded.
Reset account lockout counter after	Determine how long a time in minutes must pass between bad logon attempts before the lockout counter is reset. For example, if the threshold is set to 4, the reset is set to 5, a single bad password is entered, and then no additional attempt to log on is made for 5 minutes, the user will again have 4 possible attempts to enter the correct password. Must be <= account lockout duration. Range 099999	Set to some number less than the account lockout duration.

Account Policy for a domain must be configured in the Default Domain Security Policy. There can only be one Account Policy per domain. However, when local accounts are used, the local account policy settings are used unless the account policy has been configured for the OU in which a domain member computer account resides.

Local Logon Versus Domain Logon

Local accounts exist in the local account database of every Windows computer based on NT technologies. Domain accounts exist in the domain database of a Windows NT 4.0 domain controller and in the Active Directory of Windows Server 2003 and Windows 2000 domains. When a Windows 2000 or Windows Server 2003 computer is promoted to DC, the local account database is not directly accessible, and during normal operation, the only accounts that have access to the computer's resources are domain accounts.Chapter 7.

The Password Policy

Password policy establishes restrictions that control password composition and modification.

TIP: New Account Gotcha

When new accounts are created, a password should be configured and provided to the user. The user should be advised to change his or her password immediately, but if no other configuration is applied and the password policy is set to require a minimum password age, the user cannot change his or her password until that time has elapsed. All new user accounts should be configured to require that the User must change password at next logon. This setting is configured in the user Account property page in the Account options box and will override the password policy minimum password age setting.

In addition to password policy, the Group Policy Security Option Accounts: Limit local account use of blank password to console logon only is Enabled by default. If the local password policy allows blank passwords, local accounts can be configured with no password. However, if this option is enabled, as it is by default, then these accounts cannot be used over the network as authentication to access resources. A user may sit at the console and use the account to log on to the computer, but if access from another computer is attempted to resources on the computer that allow access by this account, the attempt will be blocked.

Creating Strong Passwords: Bigger is Better

Modern password-cracking tools are available that can be used to crack even passwords that you may have been led to believe are strong. To break false assumptions about password strength and to assist all users in creating more crack-resistant passwords, I often demonstrate one of these tools. The activity usually consists of having available a test domain controller with default configuration, but with a small number of existing user accounts and different password configurations. I ask participants to submit a strong password and then have a volunteer enter a user account for each individual and enter their password, or if the group is small enough, I have each user create his account and enter his or her own password. Then I load the password cracker and explain how it works. I start it running and move on to other topics.

Periodically, we return to the program to see how it is doing. Because passwords that are cracked are displayed on the screen along with the time it took to crack them, we can judge each password's strength by the time it took to crack. Participants are often surprised to see that their "strong" passwordscomposed of upper- and lowercase letters, numbers, and special charactersare often cracked in minutes or seconds on a three-year-old laptop.

They also learn that passwords greater than 14 characters are not easily cracked because no LM password hash is stored and the cracker works by first attacking this weak hash.

The lesson to be learned from this demonstration is that requiring strong passwords means more than selecting the password policy that requires password complexity. When the LM hash is not available in the password database, and when users are taught how to create truly strong passwords, passwords can be made more secure for authentication. If you adopt this practical exercise in security awareness, be sure to emphasize that cracking truly strong passwords is also possible, but it takes longer. You should also be clear that the attack you ran required administrative access to the account database. When strong passwords are used in tandem with account policy settings such as the requirement to frequently change passwords and not repeat them, then password cracking programs can be deterred. An attacker may be able to crack a password, but if it takes him a long time, it may be useless because the password will have already changed, or the data he wanted to obtain will have become obsolete. You might also introduce the concept of passphrasescreating a password that is a phrase instead of a meaningless arrangement of letters and characters. This is a way that users can create long passwords that are easier to remember.

Truly, where passwords are concerned, bigger is better.

The Account Lockout Policy

An Account Lockout Policy can be configured to prevent online brute force cracking attacks from succeeding. Unfortunately, this may also lock out legitimate users. In the typical Account Lockout Policy, an account is locked out after some number of unsuccessful attempts. If the number of attempts is low, an attacker attempting to guess passwords or a legitimate user who has forgotten his password will quickly lock out an account. An automated attack, in which many accounts are targeted, can quickly lock out an entire population of users. Although accounts can be easily reset, there is no quick way to reset a large number of accounts with Active Directory Users and Computers. It is possible, however, to script the resetting of many accounts.

For this reason, account lockout policies are often not established. However, a better approach would be to evaluate the risk of such an attack against the need to prevent unauthorized access. In some circumstances, it may be better for legitimate users to be locked out than for unauthorized attackers to be allowed in. In many cases, setting the required number of incorrect attempts to a large number may provide a compromise. If systems are monitored, large numbers of invalid logon attempts should trigger investigations and countermeasures long before legitimate users are locked out. Should this detection fail, the account lockout policy has a good chance of locking accounts before an attacker gains access.

Figure 2-12 displays the Account Lockout Policy, and Table 2-8 describes the function of each of its settings.

User Account Restrictions

Setting account properties further restricts accounts. These account restrictions, some of which can be seen in the Account Options section of the User properties Account tab shown in Figure 2-13, are listed and defined in Table 2-9.

Figure 2-13. User account restrictions.

Table 2-9. User Account Restrictions
Restriction	Description	Recommendation
Logon Hours	By default, the user has unrestricted logon hours. A more limited schedule can be set.	At least restrict logon hours for temporary workers and contractors. Users should not be able to return and access computer systems outside of regular business hours, and those able to access computers in the evening should not be able to take advantage of found passwords.
Log On To	Users may be restricted to a set of computers from which they can log on. Using a different computer will result in logon failure. NetBIOS names for the computers must be entered, not DNS names.	Set restricting for temporary workers, contractors, and so on to reduce attack surface.
User must change password at next logon	When a user logs on, he will be prompted to change his password.	This should be set on new accounts. As a first password is provided to the user, setting this will ensure that the password quickly becomes known only to the user. Set this if attempting to remove LM hashes from the registry.
User cannot change password	A user may log on to this account but cannot change the password. An administrator must reset the password if this is required.	A good setting for service accounts. If the password is deduced, an attacker cannot change it while logged on.
Password never expires	Overrides password policy and enables a service account to retain its password until reset by an administrator.	Set for service accounts. Do not set for user accounts.
Store password using reversible encryption	Effectively places a plaintext password in the account database. May be necessary for legacy authentication protocols used in remote access.	If this must be set, set it here for a single user or small number of users, not in the password policy where it would affect all user accounts.
Account is trusted for delegation	Account credentials may be delegated.	Set if establishing delegation for specific services to be delegated in a multitier application.
Account is sensitive and cannot be delegated	An account cannot be delegated.	Do not delegate administrator accounts or other sensitive accounts.
Use DES encryption types for this account	Some clients may require this encryption type. This will change the way the password is stored in the account database.	Set only if necessary.
Do not require Kerberos preauthentication	The credentials testing before issuing the TGT will not be done.	Clients authenticating to a non-Windows Kerberos realm may not need to pre-authenticate. Set this for them.
Account expires	Never is the default, but a day, month, and year may be set.	Set for temporary and contract workers.

Individual User account restrictions can be set for each user account.

Local Account Policy and the Password Reset Disk

A Windows Server 2003 computer's local account policy can be configured through its local Group Policy. These settings will affect only local accounts. If the server is not joined in a domain, a password reset disk can be made for local user accounts. The password reset disk can be used to recover access to the server using an account whose password has been forgotten.

Although local accounts on the server should not be used interactively for end-user tasks such as web browsing, email, or EFS file encryption, it is true that resetting a local user account password on a standalone Windows Server 2003 computer will destroy access to encrypted email, EFS encrypted files, and Internet passwords saved on the disk. This is the same behavior seen on a standalone Windows XP computer. A password reset disk can be used to recover access to local accounts and thus return access to the encrypted data.

NOTE: Linux/Other OS Password Reset Disks

Numerous utilities are available that can be used to boot a Windows computer to another OS and attack the computer by resetting passwords. If the files have been encrypted using EFS, and the password is reset using any of these utilities, access to the EFS encrypted files is lost.

The Password Reset utility is used to make the Password Reset disk. When the utility is used, a public key/private key pair is created, and the user's current password is encrypted using the public key. The encrypted password is stored only on the local computer disk, not on the reset disk. The private key is stored on the password-reset disk. To recover the password, the Password Reset utility can use the private key from the disk to decrypt the encrypted password; the user will then be able to use the change password utility to change her password and log on to the system. The new password is encrypted with the same public key and is accessible with the same password reset disk, should it be necessary again.

To create a password reset disk, follow these steps:

Press Ctrl+Alt+Del, and then click Change Password.

In the User name box, enter the user name that the reset disk will be created for.

Select the local computer in the dropdown list Log on to.

Click the Backup button.

Click Next from the welcome page of the Forgotten Password wizard.

Insert a blank, formatted disk in the A:\drive and click Next.

Enter the current password and click Next.

When the progress bar indicates that the disk is 100% complete, click Next.

Click Finish to complete the wizard.

10.

Remove the disk and store it in a safe place.

11.

Click Cancel twice to return to your current session.

To use a password reset disk:

At the logon prompt, enter the user account name and click OK.

If a password reset disk was created, the Logon Failed box will appear.

Click Reset.

Insert the password reset disk.

The Create New Password wizard will start. Enter a new password for the account and confirm it.

Enter a new "password hint" and click OK. The password is then reset.