Objective 5.1: Designing a Client Authentication Strategy

Any network security design needs a client logon strategy that addresses the following three topics: authentication, authorization, and accounting (you ll sometimes see the last one referred to as Auditing ). This AAA Model is an Internet standard for controlling various types of network access by end users. Put simply, authentication is concerned with determining that a user is who he or she claims to be. Authorization focuses on what a user is permitted to do once he or she has passed the authentication stage, and accounting or auditing tracks who did what to a network file, service, or other resource. Windows Server 2003 addresses all three facets of this security standard with the use of the user authentication strategies that we ll discuss in this chapter.

Regardless of which protocol or technical mechanism is used, all authentication schemes need to meet the same basic requirement of verifying that a user or network is actually who or what it claims to be. This can include verifying a digital signature on a file or an entire hard drive, or verifying the identity of a user or computer that is attempting to access network resources such as a file share. Windows Server 2003 offers several protocols and mechanisms to perform this verification process, including (but not limited to) the following:

• Kerberos

• NTLM

• SSL/TLS

• Digest authentication

• Smart cards

• Virtual Private Networking (VPN) and Remote Access Services (RAS)

User authentication is a necessary first step within any network security infrastructure, because it establishes the identity of the user. Without this key piece of information, Windows Server 2003 access control and auditing capabilities would not be able to function. Once you understand how the various Windows authentication schemes and protocols work, you ll be able to create an effective user authentication strategy for your network. The location of your users, whether they are connected to the LAN via a high-speed network connection or a simple dial-up line, and the client and server operating systems in use throughout your organization will dictate the best authentication strategy to implement within your security design. Keep in mind that a real-world authentication strategy will almost certainly involve a combination of the strategies and protocols described in this chapter, since a single solution will not meet the needs of an enterprise organization. Your goal as a network administrator is to create an authentication strategy that provides the optimum security for your users, while allowing you to administer the network as efficiently as possible. In the following sections, we ll describe the particulars of each authentication mechanism available with Windows Server 2003, and how you can use each to improve your network security design.

Objective 5.1.1, 5.1.2: Analyzing Authentication Requirements

The most common authentication mechanism, one that goes back as far as the days of mainframe computing, is the use of password authentication . In this model, the user supplies a password to a server or host computer, and the server compares the supplied password with the information that it has stored in association with the username in question. If the two items match, the system permits the user to log on. Simple password authentication is not in heavy use anymore because of concerns that user passwords were being transmitted via clear-text over a network connection, thus allowing anyone monitoring network communications to steal the password. This concern is so great that many modern password authentication schemes such as NTLM and Kerberos never actually transmit the user password over the network at all.

Another concern with password authentication that is perhaps even more difficult to address is that of user education. Even after continually reminding users to choose strong passwords and to avoid sharing their login credentials, many still use their children s names as passwords or share their passwords with coworkers or assistants. In an enterprise network that is connected to the Internet, the importance of creating strong password policies as part of your network s security plan simply cannot be overstated. To assist in this, Windows Server 2003 allows you to establish password policies to mandate the use of strong, complex passwords. You can also mandate that your users log in using smart cards, a topic that we ll cover in depth in a later section.

A key feature of Windows Server 2003 is its support for Single Sign-on, an authentication feature that allows domain users to authenticate against any computer in a domain, while only needing to provide their login credentials one time, usually when they log on to their local workstation. This mechanism will allow you to manage a single account for each user on your network, rather than face the administrative load of establishing and maintaining multiple user accounts across different servers or domains. This greatly enhances convenience for users as well as administrators, since accessing the network is simplified by only needing to maintain a single password or smart card. However, whether your authentication scheme uses single sign-on or not, any authentication process will involve two major steps. First, the user must perform an Interactive Logon to access the local computer. After users have authenticated themselves to their local workstations, Network Authentication will allow users to access other resources located elsewhere on the network. In this section, we ll examine both of these processes in detail.

Network users perform an interactive logon when they present their network credentials to the operating system of the computer that they are attempting to log on to. (This is usually their desktop workstation.) The logon name and password can either be a user account stored in the local computer s account database, or a domain account stored on a DC. When logging on using a local computer account, the user presents credentials that are stored in the Security Account Manager (SAM) database on the local machine. While any workstation or member server can store the SAM, the accounts within the local SAM can only be used for access to that specific computer. When using a domain account, the user s domain information is forwarded to the Active Directory database. This allows the user to gain access, not only to the local workstation, but to the Windows Server 2003 domain itself. In this case, the user s domain account bypasses the workstation s SAM database entirely, authenticating to the local workstation using the information stored in Active Directory. Figure 10.4 provides a comparison of these two processes.

Figure 10.4: Interactive Logons Using Local vs. Domain Accounts

Network Authentication

Once users have gained access to a physical workstation, it s almost a given that they will require access to resources stored on other machines on the local or wide area network. Network authentication is the mechanism that will confirm the users identity to whatever network resource they attempt to access. Windows Server 2003 provides several mechanisms to enable this type of authentication, including Kerberos, Secure Socket Layer/Transport Layer Security (SSL/TLS), and NTLM to provide backward compatibility with Windows NT 4.0 systems.

Users who log on using a local computer account must provide logon credentials every time they attempt to access a network resource, since the local computer account only exists within the individual workstation or member server s SAM database rather than a centrally managed directory service like Active Directory. (Refer to the description of the Interactive Logon process in the previous section to see how this works.) If users are logged on to the network using a domain account, however, their logon credentials will be automatically submitted to any network services they need to access. Because of this, the network authentication process is transparent to users in an Active Directory environment; the network operating system handles everything behind the scenes without the users even being aware of it. This feature provides for single sign-on in a Windows Server 2003 environment by allowing users to easily access resources in their own domain, as well as other trusted domains.

Test Day Tip  

Network authentication using a domain account can be accomplished via a username and password or with a smart card device.

Head of the Class
Microsoft Passport Authentication

If you ve ever logged on to the MCP Secure Site at www.microsoft.com, you ve already seen Passport Authentication in action. Any business that wants to provide the convenience of Single Sign-on to its customers can license and use Passport Authentication on their Web site. Sites that rely on Passport Authentication use a centralized Passport server to authenticate users, rather than hosting and maintaining their own proprietary authentication systems. Companies can also use Passport Authentication to map logon information to additional data in a sales or customer database, which can offer Passport customers a more personalized Web experience through the use of targeted ads, content, and promotional information. As the Microsoft Passport program has gained wider commercial acceptance, the Passport Sign-on logo (shown in Figures 10.5 and 10.6) has begun to appear on more and more corporate and e-commerce Web sites.

Figure 10.5: Passport Sign-On through www.ebay.com

Figure 10.6: Passport on www.expedia.com

From a technical perspective, Passport Authentication relies on standards-based Web technologies including SSL encryption, HTTP redirects, cookies, and symmetric key encryption. Because the technology used by Passport Authentication is not proprietary, it is compatible with both Microsoft Internet Explorer and Netscape Navigator, and some flavors of UNIX systems and browsers. The single sign-on service is similar to forms-based authentication that is common throughout the Internet; it simply extends the functionality of the sign-on features to work across a distributed set of participating sites.

Microsoft introduced the .NET Passport service in 1999, and since then, Passport Authentication has authenticated more than 200 million accounts for businesses such as McAfee, eBay, NASDAQ, Starbucks, and many others. If you are considering integrating Passport Authentication into your user authentication strategy, here are some of the advantages that will be available for Web authentication:

• Single sign-in allows your users to sign on to the Passport site once to access information from any participating Web site. This alleviates the frustration of registering at dozens of different sites and maintaining any number of different sets of logon credentials. The Passport service will allow the over 200 million Passport users quick and easy access to your site.

• The Kids Passport service provides tools that will help your business comply with the legal provisions of the U.S. Children s Online Privacy Protection Act (COPPA). Your company can use this service to conform to the legal aspects of collecting and using children s personal information, and to customize your Web site to provide age-appropriate content.

• Maintain control of your data Since the Passport service is simply an authentication service, your customer information and data will still be controlled inhouse, and is not shared with the Passport servers unless you configure your Web site to do so.

  At the time of writing, there are two fees for the use of Passport Authentication: a USD$10,000 fee paid by your company on an annual basis, and a periodic testing fee of USD $1,500 per URL. The $10,000 is not URL specific and will cover all URLs controlled by a single company. Payment of these fees will entitle your company to unlimited use of the Passport Authentication service for as many URLs as you have registered for periodic testing.

  Microsoft has created several key features within Passport Authentication to ensure that the security and privacy of your customers and users can be maintained at the highest possible level. Some of the security features employed by Passport Authentication include:

• The Web pages used to control the sign-in, sign-out, and registration functions are centrally hosted, rather than relying on the security mechanisms of each individual member site.

• All centrally hosted pages that are used to exchange usernames, passwords, or other credential information always use SSL encryption to transmit information.

• Passport Authentication-enabled sites use encrypted cookies to allow customers to access several different sites without retyping their login information. However, an individual site can still opt to require users to return to the Passport sign-in screen when accessing their site for the first time.

• All cookie files related to Passport Authentication use strong encryption: when you set up your site to use Passport, you will receive a unique encryption key to ensure the privacy of your users personal information.

• The central Passport servers will transmit sign-in and profile information to your site in an encrypted fashion. You can then use this information to create local cookies, avoiding any further client redirection to the Passport servers.

• A Web site that participates in Passport Authentication will never actually receive a member s password. Authentication information is transmitted via a cookie that contains encrypted timestamps that are created when the member first signs on to Passport. The Microsoft Passport sign-out function allows users to delete any Passport-related cookies that were created on their local machine during the time that they were logged on to Microsoft Passport.

• A participating Web site will only communicate directly with the central Passport server to retrieve configuration files, which are then cached locally by the individual member server. All information that is exchanged between clients and the Passport servers takes places using HTTP redirects, cookies, and encrypted queries.

 

Securing User Accounts

So, now that you ve seen how Windows user accounts factor into the authentication process, what s the best way to go about securing them? There are any number of security settings within Group Policy that you can configure for an entire Windows Server 2003 domain, as we ve already discussed in Chapter 8, Securing Active Directory, and these security settings will carry over to your local workstations. Most of the best practices for securing user accounts center around the use (and controlling the potential misuse ) of administrative accounts. Some key factors to keep in mind, especially when securing your end-user workstations, include:

• Restrict administrator accounts to log on to specific computers only. You can use the Account Properties tab within Active Directory Users and Computers to restrict the members of the Domain Admins group to only log on to servers and specific administrative workstations. This can obviously create some administrative headaches if you need to use administrative rights on a disallowed workstation, but it might be appropriate for extremely high-security environments.

• Require multifactor authentication. You can install smart card readers on your servers and/or workstations, and require administrators to use smart cards to authenticate when logging on with an administrative account. You can extend this to include Terminal Services authentication.

• Control membership in Administrative groups. You should only add a new user to the Domain Admins, Enterprise Admins, or Schema Admins group if that user has a legitimate need to perform the kinds of duties associated with those security groups. You might be faced with a technical support call for a third-party application that is malfunctioning and be told to Add the user to the local administrators group, since that fixes the problem. This type of shortcut is one that you should avoid at all costs, since it makes for lazy security standards and potential vulnerabilities for your entire network. In most circumstances, you would not want regular end users to have administrative access to their workstations, since any virus or worm that they encounter would be able to function in the security context of an administrative user, creating the potential for even more damage resulting from any sort of malicious code or attack.

• Require administrators to use a non-administrative account for day-to-day activities. There is no good reason for a system administrator to log on to a machine using administrative access if all she is doing is checking e-mail or doing Internet research. While this practice is difficult to enforce from a technical standpoint, promote security awareness among your network administrators to encourage the use of the RunAs function to use administrative access only when necessary.

Securing Account Naming Conventions

Even the names you select for your network user accounts can either improve or hinder your overall network security. Sound paranoid ? Try this on for size : An internal employee notices that all network accounts use the convention of first initial-last name, so that Joanna Smith is jsmith, Bryan Hopkins is bhopkins, and so forth. Let s say that this person wants to try to look at secured files that only the CFO has access to. If he knows that the CFO s name is Evan Lansing, then he can easily deduce that the user account whose password he needs to figure out is elansing. To look at another example, many automated hacking tools that are available for download from the Internet attempt to break in to well-known user account names like Administrator, backup, SQLAgent, Supervisor, and so on. If even one of these well-known accounts is in use on your network and possesses a weak password, a so-called script kiddie could gain access to your network without too much difficulty. Depending on the security requirements of your organization, you can lower the risk of these kinds of attacks by varying the account naming conventions to include random numbers or letters , and certainly avoid using commonly known account names like Administrator. Remember that when dealing with password-based authentication schemes, the logon process is a puzzle containing two pieces: the username and the password. If attackers can determine a username to attempt to undermine, then they re already halfway to breaking into your network.

Choosing Authentication Protocols

Windows Server 2003 offers several different authentication methods to meet the needs of even the largest heterogeneous corporate network. The default authentication protocol for a pure Windows Server 2003 environment is Kerberos version 5. This protocol relies on a system of tickets to verify the identity of network users, services, and devices. For Web applications and users, you can rely on the standards-based encryption offered by the SSL/TLS security protocols, as well as Microsoft Digest. In addition, to provide backward compatibility for earlier versions of Microsoft operating systems, Windows Server 2003 still provides support for the NTLM protocol as well. In this section, we ll examine the various authentication options available to you as you create your network design.

Kerberos

As we just mentioned, the primary authentication protocol in a Windows Server 2003 Active Directory domain is Kerberos version 5. Kerberos provides comprehensive authentication by verifying the identity of network users, and the validity of the network services that users are attempting to access. This latter feature was designed to prevent users from attaching to dummy services created by malicious network attackers to trick users into revealing their passwords or other sensitive information. Verifying both the user and the service that the user is attempting to use is referred to as mutual authentication . Kerberos authentication can only be used by network clients and servers running Windows 2000, Windows Server 2003, or Windows XP Professional; any Windows 9 x or NT clients that attempt to access a Kerberos-secured resource will use NTLM authentication instead. (We ll discuss NTLM more fully in the next section.) All 2000/2003/XP Professional machines that belong to a Windows Server 2003 or Windows 2000 domain will use the Kerberos protocol as the default mechanism for network authentication for domain resources.

Kerberos authentication relies on a Key Distribution Center (KDC) to issue tickets to enable client access to specific network resources. Each DC in a Windows Server 2003 domain functions as a KDC, which creates fault tolerance in the event that a DC becomes unavailable. Network clients will use Domain Name Service (DNS) to locate the nearest available KDC; once they ve located the KDC they will provide a pass phrase in order to acquire a ticket . Kerberos tickets contain an encrypted password that confirms the user s identity to the requested service. These tickets will remain active on a client computer system for a configurable amount of time, usually 8 or 10 hours. The longevity of these tickets allows Kerberos to provide single sign-on capabilities, where the authentication process as a whole becomes transparent to the users once they ve initially entered their logon credentials.

Exam Warning  

The obvious downside to this is that the ticket will remain active on the client workstation even if the user leaves the machine unattended: if someone else gains physical access to the workstation while the Kerberos ticket is still active, he or she will be able to access resources using that ticket. Shortening the ticket lifespan will reduce the risk of this, but will force users to re-enter their pass phrase more often.

When users enter their network credentials on a Kerberos-enabled system, the following steps take place to process the authentication and authorization request.

These steps occur completely behind the scenes; the users are only aware that they ve entered their password or PIN number as part of a normal logon process.

1. Using a smart card or a username/password combination, a user authenticates to the KDC. The KDC issues a ticket-granting ticket (TGT ) to the client system. The client retains this TGT in memory until needed.

2. When the client attempts to access a network resource, it presents its TGT to the ticket-granting service (TGS) on the nearest available Windows Server 2003 KDC.

3. If the user is authorized to access the service that it is requesting, the TGS issues a service ticket to the client.

4. The client presents the service ticket to the requested network service. Through mutual authentication , the service ticket will prove the identity of the user and the identity of the service.

   Exam Warning  

   Kerberos authentication relies on timestamps to function properly. As such, all clients that are running the Kerberos client must synchronize their time settings with a common time server. If the time on a network client is more than five minutes slow or fast compared to the KDC, Kerberos authentication will fail.

The Windows Server 2003 Kerberos authentication system can also interact with non-Microsoft Kerberos implementations such as MIT and UNIX-based Kerberos systems. This new realm trust feature, covered in Chapter 4, Securing the Network Management Process, will allow a UNIX client in a Kerberos realm to access resources in an Active Directory domain, and vice versa. This interoperability will allow Windows Server 2003 DCs to provide authentication for client systems running UNIX/MIT Kerberos, including clients that might be running operating systems other than Windows XP Professional or Windows 2000. Conversely, it will also allow Windows-based clients to access resources within a UNIX-based Kerberos realm. (We discussed this interoperability more fully in Chapter 1.)

NTLM Authentication

Instead of Kerberos, Windows operating systems prior Windows 2000 use NT LAN Manager (NTLM) to provide network authentication. In a Windows Server 2003 environment, NTLM will be used to communicate between two computers when one or both of them is running NT4 or earlier, as well as communications between computers that are not part of an Active Directory domain. For example, NTLM authentication would be used in the following situations:

• Workstations or stand-alone servers that are part of a peer-to-peer workgroup, rather than a domain, will use NTLM authentication.

• Windows 2000 or Windows XP Professional computers logging on to an NT 4.0 primary domain controller (PDC) or backup domain controller (BDC).

• A Windows NT 4.0 Workstation client authenticating to an NT4.0, Windows 2000, or Windows Server 2003 DC.

• Users in a Windows NT 4.0 domain that has a trust relationship with a Windows 2000 or Windows Server 2003 domain or forest.

NTLM encrypts user logon information by applying a mathematical function (or hash ) to the user s password. The NT4.0 SAM database doesn t store the user s password, but rather the value of the hash that is created when NTLM encrypts the password. Using simple numbers for the sake of an example, let s say that the NTLM hash takes the value of the password and multiplies it by 3. Let s say further that user LHunter has a password of 4. The conversation between LHunter, LHunter s workstation, and the DC will go something like this:

LHunter: My password is ˜2

LHunter s workstation: Hey, Domain Controller! LHunter wants to log in.

DC: Send me the hash value of LHunter s password.

LHunter s workstation: The hash value of her password is ˜6 .

DC: That s not the hash value that I have stored for LHunter. Care to try again?

LHunter s workstation: Hey, LHunter. That password was incorrect. Sure you typed it in right?

LHunter: Sorry. My password is ˜4 .

LHunter s workstation: The has value of LHunter s password is ˜12 .

DC: Okay, the number ˜12 matches the value that I have stored in the SAM database for the hash of LHunter s password. I ll let her log in.

To further improve security, the client machine actually applies the hash to the user s password before transmitting it to the DC, which means that the user s password is never actually transmitted across the network. (And the transmission of the hash value itself is transmitted in an encrypted form, increasing the protocol s security even further.)

Digest Authentication

Microsoft uses Digest Authentication as a means of providing authentication for Web applications running on IIS. Digest Authentication uses the Digest Access Protocol , a challenge-response mechanism for applications that are using HTTP or Simple Authentication Security Layer (SASL)-based communications. When a user logs on to a Web application using Digest Authentication, IIS creates a session key that is stored on the Web server and used to authenticate subsequent authentication requests without needing to contact a DC for each individual authentication request. Similar to NTLM, Digest authentication sends user credentials across the network as an encrypted hash. Digest Authentication requires the following:

• Clients using Digest Authentication need to be using Internet Explorer 5 or later.

• The user attempting to log on to the IIS server, as well as the IIS server itself, need to be members of the same domain or belong to another domain that is connected via a trust relationship.

• The authenticating users need a valid account stored in Active Directory on the DC.

• The domain that the IIS server belongs to must contain a DC running Windows  2000 or Windows Server 2003. The Web server itself also needs to be running Windows 2000 or later.

• Digest Authentication requires user passwords to be stored in a reversibly encrypted (clear-text) format within Active Directory. You can establish this from the Account tab of a user s Properties sheet in Active Directory Users and Computers, or use a group policy to enable this feature for a large number of users. After changing this setting, your users will need to change their passwords so that a reversibly encrypted hash can be created: the process is not retroactive.

SSL/TLS

Anytime you visit a Web site that uses an https :// prefix instead of http://, you re seeing SSL encryption in action. SSL provides three major functions in encrypting Web-based traffic:

• Server authentication allows a user to confirm that an Internet server is really the machine that it is claiming to be. This is another example of mutual authentication, similar to that provided by the Kerberos protocol. For example, server authentication assures the users that they re looking at a legitimate site and not a duplicate created by a hacker to capture their credit card and other personal information.

• Client authentication to allow a server to confirm a client s identity. This would be important for a bank that needed to transmit sensitive financial information to a server belonging to a subsidiary office, for example.

• Encrypted connections allow all data that is sent between a client and server to be encrypted and decrypted, allowing for a great deal of confidentiality. This function also allows both parties to confirm that the data was not altered during transmission.

The next generation of SSL is the Transport Layer Security (TLS) protocol, which is currently under development by the Internet Engineering Task Force (IETF). It will eventually replace SSL as a standard for securing Internet traffic, while remaining backward compatible with earlier versions of SSL. RFC 2712 describes the way to add Kerberos functionality to the TLS suite, which will potentially allow Microsoft and other vendors to extend the usefulness of Kerberos beyond LAN/WAN authentication and allow it to be used throughout the Internet as a whole.