|< Day Day Up >|| |
In this lesson, you will learn the meaning of the term authentication, and how it differs from authorization. You will understand that network authentication is similar in function to the common methods of authenticating people in the physical world. You will learn how to optimize the security of authentication in Windows Server 2003 environments while ensuring compatibility with every client that will access your network resources. Finally, you will explore the tools provided for troubleshooting authentication problems.
After this lesson, you will be able to
Select an appropriate authentication protocol.
Explain how the NTLM authentication process works.
Explain how the Kerberos authentication process works.
Determine how Windows Server 2003 stores passwords and secrets to support authentication.
Select appropriate tools to troubleshoot authentication problems.
Estimated lesson time: 30 minutes
Whether you’re withdrawing money from a bank, entering a restricted building, or boarding an airplane, gaining access to a restricted resource requires both authentication and authorization. The two processes are closely related and often confused. To understand the difference between authentication and authorization, consider an example in the physical world that most people are familiar with: boarding an airplane. Before you can board a plane, you must present both your identification and your ticket. Your identification, typically a driver’s license or a passport, enables the airport staff to determine who you are. Validating your identity is the authentication part of the boarding process. The airport staff also checks your ticket to make sure that the flight you are boarding is the correct one. Verifying that you are allowed to board the plane is the authorization process.
On networks, authentication is often performed by providing a user name and password. The user name identifies you, and the password offers the computer system some assurance that you really are who you claim to be. After you are authenticated, the computer agrees that you are who you claim to be. However, it doesn’t yet know whether you are allowed to access the resource you are requesting. For example, Help desk support staff should have the right to reset a user’s password, but members of the accounting department should be able to change only their own passwords. To authorize the user, the computer system typically checks an access control list (ACL). The ACL lists users, and groups of users, who are permitted to access a resource.
|See Also|| |
Authorization is covered in Chapter 2, “Planning and Configuring an Authorization Strategy.”
In order to authenticate a user on a network with some reasonable certainty that the user is who he or she claims to be, the user needs to provide two pieces of information: identification and proof of identity. In most networks, users identify themselves with a user name or an e-mail address. The way users prove their identity varies, however.
Traditionally, a password is used to prove a user’s identity. A password is a form of a shared secret. The user knows his or her password, and the server authenticating the user either has the password stored, or has some information that can be used to validate the password.
Passwords prove your identity because they are something you know. Other ways to prove your identity are with something you have or something you are. Many modern computer systems authenticate users by reading information from a smart card—something you have. Other computer systems are satisfied that you are who you claim to be only when you prove it with something you are. Biometrics can do this by scanning a unique part of your body such as your fingerprint, your retina, or your facial features.
Passwords can be guessed, and smart cards can be stolen. One form of authentication alone may not meet your organization’s security requirements. Multifactor authentication combines two or more authentication methods, and significantly reduces the likelihood that an attacker will be able to impersonate a user during the authentication process. The most common example of multifactor authentication is combining a smart card with a password. Typically, the password is required to retrieve a key stored on the smart card. Before you can authenticate to such a system, you must provide a password (something you know) and a smart card (something you have).
The examples in this book rely on using passwords alone for authentication. While this is one of the less secure ways to authenticate users, you probably don’t have smart cards or fingerprint readers connected to your computer. You almost certainly have a keyboard, though.
The server that authenticates the user must be able to determine that the user’s credentials are valid. To do this, the server must store information that can be used to verify the user’s credentials. How and where this information is stored are important decisions to make when designing an authentication model.
The way the user credentials are stored can determine how difficult it is for an attacker to misuse the information and whether those user credentials can be migrated to a new authentication system in the future. Naturally, it is important that this information remains confidential. Instead of simply storing a list of user passwords on a server, and directly comparing the password provided by the user against the list, it’s common to store an encrypted or hashed version of the user password. If an attacker does gain access to the server’s copy of the user’s credentials, the attacker still needs to decrypt the contents before they can be used to impersonate a user.
Since the beginning of computer systems, some of the most widely used security attacks have changed upon the attacker gaining access to the operating system’s password file. When multi-user computer systems were first created, developers didn’t understand the importance of security, and password files were often created in plain text. Anyone who could gain access to the password file would easily be able to read every user’s password.
Later, operating system developers used various forms of encryption and hashing to obscure user credentials. This was a huge step forward, because the casual attacker couldn’t read the files without first decrypting them. However, security experts (whether wearing a white or a black hat) have always put a huge amount of energy into finding ways to uncover user credentials based on a captured password file. Over time, these security experts have found ways to unencrypt, in a reasonable amount of time, just about every encryption scheme operating system developers have created for protecting password files. This trend is bound to continue in the future, but you can reduce the risk of someone misusing access to your password file by requiring users to use strong passwords, requiring regular password changes, and using the cracking tools yourself to identify easily cracked passwords that should be changed.
Determining where user credentials are stored requires choosing between centralized and decentralized authentication models. Decentralized authentication models require each network resource to maintain a list of users and their credentials. While this provides granular control over which users can authenticate to network resources, it becomes impossible to manage on networks with more than a handful of servers. In Windows networks, each server maintains a list of local users that can be used to implement a decentralized authentication model.
Centralized authentication models provide significantly simpler management in larger networks, which lowers Help desk costs related to password management. In a centralized model, network resources rely on a central authority to authenticate users. Centralized authentication is required in environments where users should access all network resources with a single set of credentials, an ideal situation known as single sign-on. In Windows networks, centralized authentication is provided by means of Active Directory domains. Larger networks might use multiple domains, with trusts used to enable network resources in one domain to authorize users in another domain.
Windows Server 2003 provides robust and flexible authentication methods that can be configured to meet the needs of organizations from small businesses to enterprises. Key authentication features of Windows Server 2003 include:
Central administration of user accounts. The Active Directory directory service allows users to log on to computers in a multidomain or multiforest environment by using single-factor authentication or various types of multifactor authentication.
Single sign-on environment. When a user is authenticated to a Windows Server 2003 domain, the user’s credentials are used to access resources in the domain, thereby eliminating the need for users to authenticate to every resource that they attempt to access. When this technology is used with the Windows XP credential manager, users can access resources in other domains by providing the password one time and storing the password as part of the domain user account.
Computer and service accounts. In addition to users, computer and service accounts authenticate to the domain. Collectively, users, computers, and service accounts are referred to as security principals.
Multifactor support. Windows Server 2003 natively supports smart cards and a variety of other multifactor authentication mechanisms.
Auditing. Windows Server 2003 provides the ability to audit logon attempts and access to resources.
Protocols. Windows Server 2003 uses a variety of authentication protocols, including LM, NTLM, NTLMv2, and Kerberos.
Windows Server 2003 provides the ability to authenticate a variety of client operating systems. Because client operating systems support various levels of authentication protocols, Windows Server 2003 supports two primary authentication protocols: NTLM and Kerberos.
The NTLM authentication protocol uses a challenge-response mechanism to authenticate users and computers running Windows Me and earlier operating systems, or computers running Windows 2000 or later that are not part of a domain. A user is prompted (the challenge) to provide some private piece of information unique to the user (the response). Windows Server 2003 supports the following three methods of challenge- response authentication:
LAN Manager (LM). Developed jointly by IBM and Microsoft for use in OS2 and Windows for Workgroups, Windows 95, Windows 98, and Windows Me. It is the least secure form of challenge-response authentication because it is susceptible to eavesdropping attacks, and servers that authenticate users with LM authentication must store credentials in an LMHash.
NTLM version 1. A more secure form of challenge-response authentication than LM. It is used for connecting to servers running Windows NT with Service Pack 3 or earlier. NTLMv1 uses 56-bit encryption to secure the protocol. Servers that authenticate users with any version of NTLM authentication must store credentials in an NT Hash.
NTLM version 2. The most secure form of challenge-response authentication available. This version includes a secure channel to protect the authentication process. It is used for connecting to servers running Windows 2000, Windows XP, and Windows NT with Service Pack 4 or higher. NTLMv2 uses 128-bit encryption to secure the protocol.
Kerberos is the default authentication protocol for Windows Server 2003, Windows 2000, and Windows XP Professional. Kerberos is designed to be more secure and scalable than NTLM across large, diverse networks. Kerberos provides the following additional benefits to those provided by NTLM:
Efficiency. When a server needs to authenticate a client, the server can validate the client’s credentials without having to contact a domain controller.
Mutual authentication. In addition to authenticating the client to the server, Kerberos enables the server to be authenticated to the client.
Delegated authentication. Allows services to impersonate clients when accessing resources on their behalf.
Simplified trust management. Kerberos can use transitive trusts between domains in the same forest and domains connected with a forest trust.
Interoperability. Kerberos is based on the Internet Engineering Task Force (IETF) standards and is therefore compatible with other IETF-compliant Kerberos realms.
You can use LM authentication to provide compatibility with earlier operating systems, including Windows 95, Windows 98, and Windows NT 4.0 Service Pack 3 or earlier. There are also earlier applications that might rely on this authentication mechanism. For example, earlier versions of Netscape Navigator support only LM authentication. However, LM authentication is the weakest protocol, and the easiest to compromise. Do not use LM authentication in a Windows Server 2003 environment. Upgrade any computers that rely on the LM protocol to eliminate this security vulnerability.
A major reason not to use LM protocol is that when a password is created by the user and stored for use with LM, the password is converted to an LMHash. The LMHash contains user names and hashes of the corresponding user password. A hash is a form of one-way encryption. When a client attempts to authenticate a user with LM authentication, the hash of the password, rather than the password itself, is transmitted across the network. The server will only be able to authenticate the user if the server has the LMHash stored.
The LMHash has several weaknesses that make it more vulnerable to attack than the NT Hash. The LMHash is stored in all uppercase, is limited to 14 characters, and is divided into two discreet components before hashing. If a knowledgeable, malicious attacker does obtain access to LMHashes for a large number of users, it is likely that the attacker would be able to identify at least one user’s password. Table 1.1 shows examples of passwords and the corresponding LMHashes that would be stored.
Examine Table 1.1. Notice that passwords with fewer than eight characters all share the last sixteen characters. During the process of computing the hash, the original password is divided into two sets of seven characters. If the password is seven characters or less, the second set of seven characters is null. This results in the last sixteen characters being a well-known value that indicates to the attacker that the original password is less than eight characters. Knowing that the password is short significantly reduces the amount of work an attacker needs to perform in order to identify the original password. This method of storing passwords makes the LMHash vulnerable to attacks that can reveal the unencrypted password.
Windows Server 2003 allows you to disable the LMHash to remove the vulnerabilities presented by LM authentication. However, if you have clients running Windows 3.1 or the original release of Windows 95 that need to connect to a computer running Windows Server 2003, it is imperative that you do not disable the LMHash. However, you can still disable the use of the LMHash on an account-by-account basis by doing one of the following:
Using passwords that are 15 characters or longer.
Enabling the NoLMHash registry value locally on a computer or by using security policy.
Using specific ALT characters in passwords. ALT characters are inserted into a password by holding down the ALT key, typing the ALT code using the number pad, and then releasing the ALT key.
|Exam Tip|| |
Only specific ALT character ranges will disable the LMHash. You don’t need to memorize these for the exam, but you should be aware that not all ALT keys will work. The ALT character ranges that will disable the LMHash are: 128–159, 306–307, 312, 319–320, 329– 331, 383, 385–406, 408–409, 411–414, 418–424, 426, 428–429, 433–437, 439–447, 449–450, 452–460, 477, 480–483, 494–495, 497–608, 610–631, 633–696, 699, 701– 707, 709, 711, 716, 718–729, 731, 733–767, 773–775, 777, 779–781, 783–806, 808– 816, 819–893, 895–912, 914, 918–919, 921–927, 929–930, 933, 935–936, 938–944, 947, 950–955, 957–959, 961–962, 965, and 967–1023.
As mentioned earlier, NTLM includes three methods of challenge-response authentication: LM, NTLMv1, and NTLMv2. The authentication process for all the methods is the same, but they differ in the level of encryption.
The following steps demonstrate the flow of events that occur when a client authenticates to a domain controller using any of the NTLM protocols:
The client and server negotiate an authentication protocol. This is accomplished through the Microsoft negotiate Security Support Provider (SSP).
The client sends the user name and domain name to the domain controller.
The domain controller generates a 16-byte random character string called a nonce.
The client encrypts the nonce with a hash of the user password and sends it back to the domain controller.
The domain controller retrieves the hash of the user password from the security account database.
The domain controller uses the hash value retrieved from the security account database to encrypt the nonce. The value is compared with the value received from the client. If the values match, the client is authenticated.
The Kerberos protocol gets it name from the three-headed dog in Greek mythology. The three components of Kerberos are:
The client requesting services or authentication.
The server hosting the services requested by the client.
A computer that is trusted by the client and server (in this case, a Windows Server 2003 domain controller running the Kerberos Key Distribution Center service).
Kerberos authentication is based on specially formatted data packets known as tickets. In Kerberos, these tickets pass through the network instead of passwords. Transmitting tickets instead of passwords makes the authentication process more resistant to attackers who can intercept the network traffic.
The Key Distribution Center (KDC) maintains a database of account information for all security principals in the domain. The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long term key. The long term key is derived from a user’s logon password.
In a Kerberos environment, the authentication process begins at logon. The following steps describe the Kerberos authentication process:
When a user enters a user name and password, the computer sends the user name to the KDC. The KDC contains a master database of unique long term keys for every principal in its realm.
The KDC looks up the user’s master key (KA), which is based on the user’s password. The KDC then creates two items: a session key (SA) to share with the user and a Ticket-Granting Ticket (TGT). The TGT includes a second copy of the SA, the user name, and an expiration time. The KDC encrypts this ticket by using its own master key (KKDC), which only the KDC knows.
Kerberos implements secret key cryptography, which is different from public key cryptography in that it does not use a public and private key pair.
The client computer receives the information from the KDC and runs the user’s password through a one-way hashing function, which converts the password into the user’s KA. The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.
When a client receives the session key and TGT from the server, it stores that information in volatile memory and not on the hard disk. Storing the information in the volatile memory and not on the hard disk makes the information more secure, because the information would be lost if the server were physically removed.
When a Kerberos client needs to access resources on a server that is a member of the same domain, it contacts the KDC. The client will present its TGT and a timestamp encrypted with the session key that is already shared with the KDC. The KDC decrypts the TGT using its KKDC. The TGT contains the user name and a copy of the SA. The KDC uses the SA to decrypt the timestamp. The KDC can confirm that this request actually comes from the user because only the user can use the SA.
Next, the KDC creates a pair of tickets, one for the client and one for the server on which the client needs to access resources. Each ticket contains the name of the user requesting the service, the recipient of the request, a timestamp that declares when the ticket was created, and a time duration that says how long the tickets are valid. Both tickets also contain a new key (KAB) that will be shared between the client and the server so they can securely communicate.
The KDC takes the server’s ticket and encrypts it using the server master key (KB). Then the KDC nests the server’s ticket inside the client’s ticket, which also contains the KAB. The KDC encrypts the whole thing using the session key that it shares with the user from the logon process. The KDC then sends all the information to the user.
When the user receives the ticket, the user decrypts it using the SA. This exposes the KAB to the client and also exposes the server’s ticket. The user cannot read the server’s ticket. The user will encrypt the timestamp by using the KAB and send the timestamp and the server’s ticket to the server on which the client wants to access resources. When it receives these two items, the server first decrypts its own ticket by using its KB. This permits access to the KAB, which can then decrypt the timestamp from the client.
Now both the client and the server have the KAB. The server can be sure that the client has truthfully identified itself because the client used the KAB to encrypt the timestamp. If it is necessary for the server to respond to the user, the server will use the KAB. The client will know that the server has truthfully identified itself because the server had to use its KB to get the KAB.
|Exam Tip|| |
Be sure you understand the Kerberos authentication process for the exam!
To reduce the likelihood of passwords being discovered and compromised, Windows Server 2003, Windows 2000, and Windows XP must store passwords securely. To ensure the highest level of password integrity, passwords can be stored at the domain level in Active Directory. To enable each server to authenticate users without relying on Active Directory, Windows Server 2003 locally stores a separate database of user credentials called the Local Security Authority (LSA). The LSA is responsible for:
Managing local security policies.
Creating access tokens.
Controlling audit policies.
The sensitive information stored by the LSA is known as LSA secrets. LSA secrets contain:
Trust relationship passwords
Service account passwords
Service account names
LSA secrets can be extracted by any security principal with the Debug Programs right. To help protect LSA secrets, you can use the syskey.exe program, which further encrypts the contents of the LSA by using a public and a private key. Only Administrators can run the syskey.exe program.
|See Also|| |
For more information about the syskey.exe program, see http://support.microsoft.com/?kbid=310105 .
Sometimes, troubleshooting an authentication problem is as simple as resetting a user’s password. At other times it can be more challenging. For example, it might be difficult to detect the cause of an authentication failure if a domain controller is offline or a WAN link to a remote office has failed. Sometimes, NTLMv2 and Kerberos authentication failures can also be attributed to a clock synchronization failure. The tolerances for clocks that are out of synchronization are 30 minutes for NTLMv2 and 5 minutes for Kerberos. To assist you in determining the cause of authentication failures, Windows Server 2003 and the Resource Kit include several troubleshooting tools. Table 1.2 lists the tools that will help you troubleshoot authentication problems.
This GUI tool displays Kerberos ticket information. It also allows you to view and purge the ticket cache. Included with the Windows Server 2003 Resource Kit tools.
This command-line tool lets you view and delete Kerberos tickets granted to the current logon session. Included with the Windows Server 2003 Resource Kit tools.
Creates, lists, and deletes stored user names and passwords or credentials. Included with Windows Server 2003.
|See Also|| |
For all Resource Kit tools, see http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=9D467A69-57FF-4AE7-96EE-B18C4790CFFD.
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.
Is showing your identification to prove that you are of age to purchase a product an example of authentication or authorization?
Is showing your identification to a cashier to verify that the credit card you are using belongs to you an example of authentication or authorization?
Which of the following passwords will not be stored in an LMHash?
Authentication is the process of proving your identity. In Windows networks, users frequently authenticate themselves using a user name and password pair. How the user name and password are communicated across the network has changed with different versions of Windows.
Earlier versions of Windows use LM authentication, which is still supported by Windows Server 2003 for backward compatibility but carries with it potential security vulnerabilities. LM authentication should be disabled whenever compatibility with Windows 95 or Windows 98 is not required.
If LM authentication cannot be disabled, the storage of the LMHash can be avoided for specific user accounts by using passwords greater than 14 characters or passwords that contain special ALT characters.
Newer versions of Windows use NTLMv1, NTLMv2, or Kerberos authentication. The Kerberos protocol is designed to be more secure and scalable than NTLM authentication.
Local passwords are stored and maintained by the Local Security Authority (LSA). The LSA is responsible for managing local security policies, authenticating users, creating access tokens, and controlling audit policies.
Windows Server 2003 and the Resource Kit include the Kerbtray.exe, Klist.exe, and CmdKey.exe tools for troubleshooting Kerberos authentication problems.
|< Day Day Up >|| |