Configuring Account Policies


As you learned in the previous section, there are three types of account policies: password policies, account lockout policies, and Kerberos policies. The sections that follow show you how to configure each one of these policies.

Configuring Password Policies

Password policies control security for passwords, and they are:

  • Enforce Password History

  • Maximum Password Age

  • Minimum Password Age

  • Minimum Password Length

  • Passwords Must Meet Complexity Requirements

  • Store Password Using Reversible Encryption For All Users In The Domain

The uses of these policies are discussed in the following sections.

Enforce Password History

Enforce Password History sets how frequently old passwords can be reused. You can use this policy to discourage users from changing back and forth between a set of common passwords. Windows Server 2003 can store up to 24 passwords for each user in the password history.

To disable this feature, set the size of the password history to zero. To enable this feature, set the size of the password history using the Passwords Remembered field. Windows Server 2003 then tracks old passwords using a password history that's unique for each user, and users aren't allowed to reuse any of the stored passwords.

Note

To discourage users from bypassing Enforce Password History, you shouldn't allow them to change passwords immediately. This prevents users from changing their passwords several times to get back to their old passwords. You set the time required to keep a password with the Minimum Password Age policy as discussed below.


Maximum Password Age

Maximum Password Age determines how long users can keep a password before they have to change it. The aim is to periodically force users to change their passwords. When you use this feature, set a value that makes sense for your network. Generally , you use a shorter period when security is very important and a longer period when security is less important.

You can set the maximum password age to any value from 0 to 999. A value of zero specifies that passwords don't expire. Although you might be tempted to set no expiration date, users should change passwords regularly to ensure the network's security. Where security is a concern, good values are 30, 60, or 90 days. Where security is less important, good values are 120, 150, or 180 days.

Note

Windows Server 2003 notifies users when they're getting close to the password expiration date. Any time the expiration date is less than 30 days away, users see a warning when they log on that they have to change their password within so many days.


Minimum Password Age

Minimum Password Age determines how long users must keep a password before they can change it. You can use this field to prevent users from bypassing the password system by entering a new password and then changing it right back to the old one.

If the minimum password age is set to zero, users can change their passwords immediately. To prevent this, set a specific minimum age. Reasonable settings are from three to seven days. In this way, you make sure that users are less inclined to switch back to an old password but are able to change their passwords in a reasonable amount of time if they want to.

Minimum Password Length

Minimum Password Length sets the minimum number of characters for a password. If you haven't changed the default setting, you'll want to do so immediately. The default in some cases is to allow empty passwords (passwords with zero characters ), which is definitely not a good idea.

For security reasons, you'll generally want passwords of at least eight characters. The reason for this is that long passwords are usually harder to crack than short ones. If you want greater security, set the minimum password length to 14 characters.

Passwords Must Meet Complexity Requirements

Beyond the basic password and account policies, Windows Server 2003 includes facilities for creating additional password controls. These facilities enforce the use of secure passwords that follow these guidelines:

  • Passwords must be at least six characters long.

  • Passwords can't contain the user name, such as stevew, or parts of the user's full name , such as steve.

  • Passwords must use three of the four available character types: lowercase letters, uppercase letters , numbers , and symbols.

To enforce these rules, enable Passwords Must Meet Complexity Requirements. Passwords are then required to meet the security requirements listed above.

Store Password Using Reversible Encryption For All Users In The Domain

Passwords in the password database are encrypted. This encryption can't normally be reversed . The only time you'd want to change this setting is if your organization uses applications that need to be able to read the password. If this is the case, you could enable Store Password Using Reversible Encryption For All Users In The Domain.

With this policy enabled, passwords might as well be stored as plain text. It presents the same security risks. With this in mind, a much better technique would be to enable the option on a per user basis and then only as required to meet the user's actual needs.

Configuring Account Lockout Policies

Account lockout policies control how and when accounts are locked out of the domain or the local system. These policies are:

  • Account Lockout Threshold

  • Account Lockout Duration

  • Reset Account Lockout Counter After

Account Lockout Threshold

Account Lockout Threshold sets the number of logon attempts that are allowed before an account is locked out. If you decide to use lockout controls, you should set this field to a value that balances the need to prevent account cracking against the needs of users who are having difficulty accessing their accounts.

The main reason users might not be able to access their accounts properly the first time is that they forgot their passwords. If this is the case, it might take them several attempts to log on properly. Workgroup users could also have problems accessing a remote system where their current passwords don't match the passwords that the remote system expects. If this happens, the remote system might record several bad logon attempts before the user ever gets a prompt to enter the correct password. The reason is that Windows Server 2003 might attempt to automatically log on to the remote system. In a domain environment, this normally doesn't happen because of the Single Log-On feature.

You can set the lockout threshold to any value from 0 to 999. The lockout threshold is set to zero by default, which means that accounts won't be locked out because of invalid logon attempts. Any other value sets a specific lockout threshold. Keep in mind that the higher the lockout value, the higher the risk that a hacker might be able to break into your system. A reasonable range of values for this threshold is between 7 and 15. This is high enough to rule out user error and low enough to deter hackers.

Account Lockout Duration

If someone violates the lockout controls, Account Lockout Duration sets the length of time the account is locked. You can set the lockout duration to a specific length of time using a value between 1 and 99,999 minutes or to an indefinite length of time by setting the lockout duration to zero.

The best security policy is to lock the account indefinitely. When you do, only an administrator can unlock the account. This prevents hackers from trying to access the system again and forces users who are locked out to seek help from an administrator, which is usually a good idea. By talking to the user, you can determine what the user is doing wrong and help the user avoid problems.

Tip

When an account is locked out, access the Properties dialog box for the account in Active Directory Users And Computers. Then click the Account tab and clear the Account Is Locked Out check box. This unlocks the account.


Reset Account Lockout Counter After

Every time a logon attempt fails, Windows Server 2003 raises the value of a threshold that tracks the number of bad logon attempts. To balance potential lockouts due to valid security concerns against lockouts that could occur due to simple human error, there's another policy that determines how long to maintain information regarding bad logon attempts. This policy is called Reset Account Lockout Counter After and it's used to reset the bad logon attempts counter to zero after a certain waiting period. The way the policy works is simple: if the waiting period for Reset Account Lockout Counter After has elapsed since the last bad logon attempt, the bad logon attempts counter is reset to zero. The bad logon attempts counter is also reset when a user logs on successfully.

If the Reset Account Lockout Counter After policy is enabled, you can set any value from 1 to 99,999 minutes. As with Account Lockout Threshold, you need to select a value that balances security needs against user access needs. A good value is from one to two hours. This waiting period should be long enough to force hackers to wait longer than they want to before trying to access the account again.

If the Reset Account Lockout Counter After policy isn't set or is disabled, the bad logon attempts counter is reset only when a user successfully logs on.

Note

Bad logon attempts to a workstation against a password-protected screen saver don't increase the lockout threshold. Similarly, if you lock a server or workstation using Ctrl+Alt+Delete, bad logon attempts against the Unlock dialog box don't count.


Configuring Kerberos Policies

Kerberos v5 is the primary authentication mechanism used in an Active Directory domain. To verify the identification of users and network services, Kerberos uses service tickets and user tickets. As you might expect, Windows Server 2003 service processes use service tickets and user processes use user tickets. Tickets contain encrypted data that confirm the identity of the service or user.

You can control ticket duration, renewal, and enforcement with the following policies:

  • Enforce User Logon Restrictions

  • Maximum Lifetime For Service Ticket

  • Maximum Lifetime For User Ticket

  • Maximum Lifetime For User Ticket Renewal

  • Maximum Tolerance For Computer Clock Synchronization

These policies are discussed in the sections that follow.

Security Alert

Only administrators with an intimate understanding of Kerberos security should change these policies. If you change these policies to inefficient settings, you might cause serious problems on the network. In most cases the default Kerberos policy settings work just fine.


Enforce User Logon Restrictions

Enforce User Logon Restrictions ensures that any restrictions placed on a user account are enforced. For example, if the user's logon hours are restricted, this policy is what enforces the restriction. By default, the policy is enabled and you should disable it only in rare circumstances.

Maximum Lifetime

Maximum Lifetime For Service Ticket and Maximum Lifetime For User Ticket set the maximum duration for which a service or user ticket is valid. By default, service tickets have a maximum duration of 600 minutes and user tickets have a maximum duration of 10 hours.

You can change the duration of tickets. For service tickets, the valid range is from 0 to 99,999 minutes. For user tickets, the valid range is from 0 to 99,999 hours. A value of zero effectively turns off expiration. Any other value sets a specific ticket lifetime.

A user ticket that expires can be renewed, provided the renewal takes place within the time set for Maximum Lifetime For User Ticket Renewal. By default, the maximum renewal period is 7 days. You can change the renewal period to any value from 0 to 99,999 days. A value of zero effectively turns off the maximum renewal period, and any other value sets a specific renewal period.

Maximum Tolerance

Maximum Tolerance For Computer Clock Synchronization is one of the few Kerberos policies that you might need to change. By default, computers in the domain must be synchronized within five minutes of each other. If they aren't, authentication fails.

If you have remote users who log on to the domain without synchronizing their clock to the network time server, you might need to adjust this value. You can set any value from 0 to 99,999. A value of zero (0) says that there's no tolerance for a time difference, which means the remote user's system must be precisely time-synchronized or else authentication will fail.



Microsoft Windows Server 2003 Administrator[ap]s Pocket Consultant
Microsoft Windows Server 2003 Administrator[ap]s Pocket Consultant
ISBN: 735622450
EAN: N/A
Year: 2003
Pages: 141

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net