Lesson 2 Planning and Implementing an Authentication Strategy

 < Day Day Up > 



Most organizations need to support seamless access to the network for multiple types of users, such as office workers, employees who are traveling, business partners, and customers. At the same time, organizations need to protect network resources from potential intruders. A well-designed authentication strategy can help you achieve this complex balance between providing reliable access for users and strong network security for your organization.

After this lesson, you will be able to

  • Evaluate the factors that influence the needs of your authorization strategy.

  • Create a strong password policy.

  • Configure settings to implement account lockout polices and logon restrictions on users.

  • Configure settings for creating a Kerberos ticket policy.

  • Select appropriate Windows authentication methods for earlier applications.

  • Enable secure authentication.

  • Design a strategy for supplemental authentication.

  • Explain the benefits of applications that are certified for use with Windows.

Estimated lesson time: 45 minutes

Considerations for Evaluating Your Environment

When establishing an authentication strategy for your organization, you must become familiar with your current environment, including the structure of your organization; the users, computers, and services in your organization that require authentication; and the applications and services that are in use. This will help you to understand the requirements and constraints of your organization.

When evaluating your environment, identify the following:

  • The number of domain controllers in your organization. Ensure that there are enough domain controllers to support client logon requests and authentication requests while meeting your redundancy requirements. A sufficient number of domain controllers will ensure that a large volume of authentication requests will not result in authentication failures, even if a domain controller is offline because of hardware or network failures.

  • The type of network connectivity between site locations in your organization. Ensure that clients in remote sites are connected well enough to authenticate to domain controllers located in main sites. If connectivity is an issue, consider installing domain controllers in sites that might have logon problems because of slow or unreliable links.

    Planning 

    Everyone is always concerned about whether they have enough bandwidth, but it’s latency that’s more likely to cause authentication problems across wide area network links. Authentication requires very little bandwidth. However, packets must go back and forth across the link several times. If latency causes a significant delay for each round trip, authentication will seem slow.

  • The number of certification authorities (CAs) that are available in your organization and their locations. Ensure that you have enough CAs to support the anticipated number of certificate requests.

Guidelines for Creating a Strong Password Policy

Encryption limits your vulnerability to having user credentials intercepted and misused. Specifically, password encryption is designed to be extremely difficult for unauthorized users to decrypt. Ideally, when a strong password is used, it should take an attacker months, years, or decades to identify the unencrypted password after the attacker captures the encrypted or hashed password. During that time, the password should have been changed—making the unencrypted password now useless.

In contrast, weak passwords can be identified in a matter of hours or days, even when they have been encrypted. Encryption cannot protect against passwords that are easily guessed, because weak passwords are vulnerable to dictionary attacks. Dictionary attacks encrypt a list of common passwords, and compare each possibility with the captured cyphertext. If the password appears in the password dictionary, the attacker will identify the password quickly. You can defend against this vulnerability by implementing a strong password policy.

Off the Record 

The best way to understand how effective dictionary attacks are is to grab a password cracking tool from the Internet and experiment with it on a test machine. I can’t point you to a specific tool, but they’re not hard to find.

What is a strong password?

A strong password is one that can be remembered by the user but that is also complex enough to be difficult to guess. For example, *&_I5y#<.h may appear to be a good password, but the user might be forced to write it down in order to remember it, creating a significant security vulnerability. Fortunately, there are techniques for creating strong passwords that the human brain can remember. For example, you could take a password that is easy to remember (and easy to guess), such as 99Butterflies, and add an easy-to-remember suffix to it to make it more secure: 99Butterflies@complexpassword.com. You now have a password that is 33 characters long, uses uppercase, lowercase, and symbols, is easy to remember, and that, because of the length, is harder than the *&_I5y#<.h password to crack.

In the example above, an e-mail type suffix was added to the end of the password to make it complex. You can also add phone numbers, addresses, and file path locations (like c:\winnt\system32) to make a password complex.

Strong password policy

When implementing and enforcing a password policy, consider the users’ inability to remember passwords that are too complex, change too often, and are too long. When passwords are too complex or too long, the eventuality that users will use other methods to remember their passwords, such as writing them down, is more likely.

Important 

There is nothing seriously wrong with a user writing down a password to remember it, as long as the written-down copy is not easily accessible. Actually, users feel more comfortable if they can write down their passwords and are more likely to create more complex passwords.

To help implement a strong password policy, Windows Server 2003 provides a feature known as Password Complexity. Password Complexity is enforced by default in the Windows Server 2003 environment. The Password Complexity feature requires that passwords:

  • Do not contain all or part of the user’s account name.

  • Be at least six characters in length.

  • Contain characters from three of the following four categories:

    • Uppercase characters (A through Z)

    • Lowercase characters (a through z)

    • Base 10 digits (0 through 9)

    • Non-alphabetic characters (for example, !, $, #, %)

      Note 

      By default, Windows Server 2003 requires that passwords are seven characters long, exceeding the requirement imposed by the Password Complexity feature.

Table 1.3 describes the security policy settings that you can use to implement a strong password policy. These policy settings are located in the Password Policy node in Account Policies.

See Also 

Security configuration settings such as minimum password length are configured using security policy. Security policy is covered in more detail in Chapter 3, “Deploying and Troubleshooting Security Templates.”

Table 1.3: Security Policy Settings for Strong Passwords

Security policy setting

Description

Maximum password age

Determines how long passwords can be used before users are required to change them. The default value of 42 days is generally appropriate. Ideally, this value would be lower than the time it takes a commercial password cracking program to compromise the passwords in your organization. Lowering this value decreases the likelihood that a password will be cracked while it is still valid, but may increase the number of support calls relating to forgotten passwords.

Enforce password history

Stores the passwords that users have used previously and prevents reuse of those passwords. The default setting is also the maximum: 24 passwords remembered.

Minimum password age

Determines how long a user must keep a password before changing it. The default setting of one day will prevent a user from immediately changing a password to a previous one.

Minimum password length

Determines the minimum length of a password. The minimum recommended setting is the default of 7 characters.

Tip 

You can use the Microsoft Platform Software Development Kit (SDK) to develop custom password complexity requirements for your organization.

Although you can enforce strong passwords through security policy in Windows Server 2003 Active Directory, employee education is the only way to keep users from writing down passwords in public locations or using discoverable personal information in passwords.

Options for Account Lockout Policies

Account lockout policies exist to limit your vulnerability to password-guessing attacks. When an account lockout policy is defined, a user account is automatically locked out after a specified number of incorrect password attempts. Windows Server 2003 does not enable account lockouts by default, and for a good reason: enabling account lockouts exposes you to a denial-of-service vulnerability. A malicious attacker with access to user names can guess incorrect passwords, which will cause those accounts to become locked out, which denies legitimate users from accessing network resources.

Therefore, account lockout policies should only be enabled in environments where the threat from guessed passwords is greater than the threat of a denial-of-service attack. Account lockout policies are set and enforced at the domain level. When enabled, these policies should be set to allow for user error, but to prevent attacks on user accounts.

Security Alert 

Account lockout policies are not necessary in environments where an intrusion detection system exists. An intrusion detection system will detect that an attacker is repeatedly guessing passwords and notify a system administrator. The system administrator can then track down the malicious attacker and stop the attack before the password is successfully guessed.

Account lockout settings

Table 1.4 describes the various account lockout settings that you can use to secure your network. These policy settings are located in the Account Lockout Policy in Account Policies.

Table 1.4: Password and Account Lockout Settings

Security policy setting

Description

Account lockout threshold

Determines how many logon attempts can be made before the account is locked out. This setting does not apply to attempts to log on at the console of a locked workstation or to attempts to unlock a screensaver, because locked workstations cannot be forced to run password-cracking programs.

Account lockout duration

Determines how many minutes a locked-out account will remain disabled before being automatically enabled. Setting this to 0 will require an administrator to unlock the account manually.

Reset account lockout
counter after

Determines the number of minutes that must elapse after a failed logon attempt before the counter is reset to 0 bad logon attempts.

Options for Creating a Kerberos Ticket Policy

You should establish reasonable lifetimes for Kerberos tickets in your organization. Reasonable Kerberos ticket lifetimes must be short enough to prevent attackers from cracking the cryptography that protects the ticket’s stored credentials. Reasonable ticket lifetimes must also be long enough to ensure that requests for new tickets do not overload the KDC and network.

Default domain policies for Kerberos tickets

Table 1.5 describes the default domain policy options available for Kerberos tickets. These policy settings are located in the Kerberos Policy node in Account Policies.

Table 1.5: Security Policy Settings for Kerberos Ticket Policy

Security policy setting

Description

Enforce user logon restrictions

Determines whether the KDC validates every request for a session ticket by examining the user rights policy on the target computer. This option also serves as a means of ensuring that the requesting account is still valid and was not disabled since the Kerberos ticket was issued.

This option could potentially slow down network logons.

Maximum lifetime for service ticket

Determines the amount of time a service ticket is available before it expires. This setting should be set the same as the user ticket setting, unless your users run jobs that are longer then their user tickets would allow.

Maximum lifetime for user ticket

Determines the amount of time a user ticket is available before it expires. This setting should be set according to the average amount of time a user logs on to a computer at your organization.

Maximum lifetime for user ticket renewal

Determines the number of days for which a user’s TGT can be renewed. The default is seven days. Shortening this interval will increase security but put more load on the KDC.

Maximum tolerance for computer clock synchronization

Determines the maximum time difference (in minutes) between the time on the user’s computer’s clock and the time on the domain controller. Raising this value from the default of five minutes increases your vulnerability to replay attacks, in which encrypted credentials captured from the network are resubmitted by a malicious attacker. Lowering this value will increase the number of authentication failures caused by unsynchronized clocks.

Windows 2003 Authentication Methods for Earlier Operating Systems

Authentication protocols have improved over time and will continue to improve in the future. As a result, earlier operating systems support fewer and less secure authentication protocols than newer operating systems. By default, computers running Windows Server 2003 can accept all types of authentication protocols, including LM, NTLMv2, and Kerberos, to ensure compatibility with earlier operating systems. If your organization does not require this backward compatibility, you can you can configure security policy to support only the more secure protocols, such as NTLMv2 and Kerberos.

The Network Security LAN Manager Authentication Level policy defines which authentication protocols a computer sends and accepts. This policy is contained within the Local Policies\Security Options security policy node. Table 1.6 describes the options for this policy setting. The policy settings are listed in order from least to most secure. Increasing the security of this policy reduces compatibility with earlier clients and servers.

Table 1.6: LM Authentication Levels

Security policy setting

Description

Send LM & NTLM responses

Clients use LM and NTLM authentication and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication. This setting ensures that clients will be able to authenticate with servers using operating systems earlier than Windows NT 4.0 Service Pack 4 by forcing clients to send only LM and NTLM authentication. This setting reduces authentication security.

Send LM & NTLM responses –use NTLMv2 session security if negotiated

Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication. This setting enables the more secure NTLMv2 authentication protocol to be used when possible, while providing backward compatibility.

Send NTLM response only

Clients use NTLM authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication. This setting eliminates the possibility that LM authentication will be used; however, clients will not be able to authenticate to computers running Windows 95 or Windows 98.

Send NTLMv2 response only

Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication. This setting improves authentication security by forcing clients to refuse down-level authentication protocols required by servers using operating systems earlier than Windows NT 4.0 Service Pack 4.

Send NTLMv2 response only\refuse LM

Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM (accept only NTLM and NTLMv2 authentication). This setting will cause clients running Windows 95, Windows 98, and Windows NT 4.0 Service Pack 3 (or earlier) to be unable to authenticate to domain controllers.

Send NTLMv2 response only\refuse LM & NTLM

Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM and NTLM (accept only NTLMv2 authentication). This setting will cause clients running Windows 95, Windows 98, and Windows NT 4.0 Service Pack 3 (or earlier) to be unable to authenticate to domain controllers.

Enabling anonymous authentication for earlier applications

Anonymous authentication allows users and network clients to be authenticated (but not necessarily authorized to access network resources) without providing any credentials. Unlike earlier Windows operating systems, in Windows Server 2003, anonymous users are not considered to be members of the Everyone group and therefore will not be authorized to use any network resources. However, there are some scenarios in which anonymous access needs to be granted to provide compatibility with systems prior to Windows 2000. Situations in which this access might be necessary include:

  • Remote Access Server (RAS) servers on Windows NT 4.0 use anonymous access to determine dial-in permissions.

  • Windows NT 4.0 might use anonymous access to enumerate shares or gather information from domain controllers.

  • Anonymous access might be used to enumerate shares and users in a one-way cross-forest trust.

  • Earlier operating systems might use anonymous access to change passwords in Active Directory. This is accomplished through the Pre–Windows 2000–compatible access group.

If you have earlier systems in your Windows Server 2003 domain, you will need to determine which resources need anonymous access. You can then enable anonymous access by performing one of the following tasks:

  • Add the Anonymous Logon security principal to the ACL that needs access. This is the preferred method for enabling anonymous access to resources because it is the most granular.

  • Enable the Network Access: Share That Can Be Accessed Anonymously security policy setting. This security policy setting contains a list of shares that can be accessed and is useful for enabling anonymous access to a specific share on multiple computers.

  • Enable the Network Access: Let Everyone Permissions Apply To Anonymous Users security policy setting. This setting causes unauthenticated users to be considered members of the Everyone group, which might authorize users to access network resources without being authenticated as valid users. This setting should only be enabled when absolutely necessary, because it creates a significant, exploitable vulnerability.

    Caution 

    Apply the Anonymous Logon, Network Access: Share That Can Be Accessed Anonymously, Network Access: Let Everyone Permissions Apply To Anonymous Users settings only to the OU or server that needs them. Enabling these settings at the domain level will decrease network security.

Enabling secure authentication for domain controllers

Though many systems on a network may authenticate users that exist within a local user database, domain controllers provide most authentication services for network resources in Active Directory environments. Whenever possible, you should configure domain controllers to refuse LM authentication, because LM authentication is more vulnerable than other authentication protocols. To configure domain controllers to reject LM authentication:

  1. On a domain controller, click Start, click Administrative Tools, and then click Domain Controller Security Policy.

  2. Expand Local Policies and then select Security Options, as shown in Figure 1.1.

    click to expand
    Figure 1.1: The Default Domain Controllers Security Settings console

  3. Double-click Network Security: LAN Manager Authentication Level. The Network Security: LAN Manager Authentication Level Properties dialog box appears, as shown in Figure 1.2.

    click to expand
    Figure 1.2: Security policy settings

  4. Select the Define This Policy Setting check box, if it is not already selected.

  5. Select Send NTLMv2 Response Only\Refuse LM, and then click OK.

  6. Close the Default Domain Controller Security Settings console.

  7. Click Start, and then click Run. Type gpupdate.exe, and click OK. This causes the policy to take effect on the local domain controller immediately.

Using Multifactor Authentication

As described earlier in this chapter, multifactor authentication significantly increases authentication security. Windows Server 2003 supports multifactor authentication by using smart cards and can support a variety of other authentication mechanisms using non-Microsoft hardware and software.

Smart cards can be required for all users in an organization. However, because of the additional cost, smart cards are often assigned only for specific users. Often network administrators are required to use smart cards because their privileges on the network would provide an attacker significant opportunity.

To require a smart card for interactive logon, launch the Active Directory Users And Computers console. Double-click the user account to view the properties, and click the Account tab. In the Account Options list, select Smart Card Is Required For Interactive Logon.

Requiring smart cards for authentication can cause problems with existing applications. However, if an application includes the Certified for Windows Server 2003 logo, the application has been tested to ensure that it meets Microsoft security standards for Windows Server 2003. From a security perspective, an application that is identified as Certified for Windows Server 2003 meets the following criteria:

  • Support smart card logons. The application should work correctly with smart card authentication and will allow smart card authentication to a terminal service.

  • Provide secure credential management. Ensures that users will get appropriate prompting for credentials and storing credentials. Also means that the application can use Kerberos, NTLM, and Secure Sockets Layer (SSL) protocols. A user can also log on using a user principal name (UPN) format.

  • Can be run in a highly secure configuration. Applications can perform all primary functions in a highly secure configuration. In a highly secure configuration, applications cannot use the unsafe communication protocol NTLM; strong authentication and account policies are set; and group membership is restricted. A highly secure configuration is a system with a clean installation of Windows and with the predefined security template Hisecws.inf applied.

  • Provide secure network connections. Applications using network connections must not depend on protocols that are known to have vulnerabilities.

Practice: Adjusting Authentication Options

In this practice, you will secure authentication on a Windows 2003 Server by using security policy. You must be logged on to Computer1.cohowinery.com with an account that has administrative credentials to create and modify the default domain controller security policy.

Your company has recently updated its security policy. The new security policy specifically forbids using the LM authentication protocol to authenticate users in the cohowinery.com domain. To comply with the updated security policy, you will use the Domain Controller Security Policy console to ensure that LM authentication is not used on any cohowinery.com domain controller.

Exercise 1: Disabling LM Authentication

In this exercise, you will configure the domain controllers to accept only NTLM and refuse LM default domain controllers security policy.

  1. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

  2. Click Start, click Administrative Tools, and then click Domain Controller Security Policy.

  3. Expand Local Policies, and then select Security Options.

  4. In the right pane, double-click Network Security: LAN Manager Authentication Level.

  5. Select the Define This Policy Setting check box if it is not already selected.

  6. Select Send NTLMv2 Response Only\Refuse LM, and then click OK.

  7. Click Start, and then click Run. Type gpupdate.exe, and click OK. This causes the policy to take effect on the local domain controller immediately.

Exercise 2: Enable Account Lockout

In this exercise, you will configure the domain controllers to accept only NTLM and refuse LM default domain controller security policy.

  1. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

  2. Click Start, click Administrative Tools, and then click Active Directory Users And Computers.

  3. Right-click the Users node, click New, and then click User.

  4. In the First Name field, type Admin1. In the User Logon Name field, type Admin1.

  5. In the Password and Confirm Password fields, type a complex password. Clear the User Must Change Password At Next Logon check box. Click Next, and then click Finish.

  6. In Active Directory Users And Computers, double-click the Admin1 user you just created.

  7. In the Admin1 Properties dialog box, click the Member Of tab. Click Add, and then specify the Administrators group. Click OK twice to return to the Active Directory Users And Computers console.

  8. Click Start, click Administrative Tools, and then click Domain Security Policy.

  9. Expand Account Policies, and then select Account Lockout Policy.

  10. In the right pane, double-click Account Lockout Threshold.

  11. In the Account Lockout Threshold Properties dialog box, select Define This Policy Setting. In the Account Will Lock Out After field, type 6. Click OK.

  12. Review the Suggested Value Changes dialog box, and then click OK.

  13. Click Start, and then click Run. Type gpupdate.exe, and click OK. This causes the policy to take effect on the local domain controller immediately.

  14. Log off from Computer1.

  15. Attempt to log on as Admin1, but do not type a password. Repeatedly attempt to log on to simulate a malicious attacker attempting to guess a password. After six attempts, you will be notified that the Admin1 account is locked out, as shown in Figure 1.3.

    click to expand
    Figure 1.3: Account lockout warning

    After completing this exercise, remove the Admin1 account and return the account lockout policies to their default settings.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

  1. Which of the following passwords is an example of a strong password?

    1. tyia

    2. imsitrjs5itr

    3. passwordpassword

    4. l%@3tty7&

  2. Which of the following are valid reasons to enable LM authentication? (Choose all that apply.)

    1. Users will access network resources using computers running Windows 95.

    2. Users will access network resources using computers running Windows 98.

    3. Users will access network resources using computers running Windows NT.

    4. Users will access network resources using computers running Windows Me.

    5. Users will access network resources using computers running Windows 2000.

    6. Users will access network resources using computers running Windows XP.

  3. Enabling account lockout accomplishes which of the following goals?

    1. Makes it impossible to steal a user’s password.

    2. Reduces the likelihood that a malicious attacker will use brute force techniques to discover a user’s password.

    3. Eliminates the need for strong passwords.

    4. Reduces Help desk costs.

Lesson Summary

  • Use security policy settings to configure authentication requirements.

  • Implement a strong password policy in your organization to reduce the likelihood that your users’ credentials will be compromised.

  • Although you can enforce complex passwords by using security policy in Windows Server 2003 Active Directory, employee education is the only way to keep users from writing down passwords or using discoverable personal information in passwords.

  • An account lockout policy prevents malicious attackers from logging on by continually guessing passwords; however, it enables malicious attackers to perform a denial-of-service attack that denies valid users from successful authentication.

  • Kerberos ticket lifetimes must be short enough to prevent attackers from cracking the cryptography that protects the ticket’s stored credentials, but long enough to minimize the number of tickets that clients request.

  • Use delegated authentication and constrained delegation as strategies for implementing supplemental authentication where required.

  • Any application that has the Certified for Windows Server 2003 logo has been tested to ensure that it will function in environments that require multifactor authentication.



 < Day Day Up > 



MCSA(s)MCSE Self-Paced Training Kit Exam 70-299 (c) Implementing and Administering Security in a M[.  .. ]twork
MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)
ISBN: 073562061X
EAN: 2147483647
Year: 2004
Pages: 217

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