Chapter 4: Designing an Authentication Strategy for Active Directory

---

In this chapter, we will show you how to design an authentication strategy. You will learn about the different trust models and about the interoperability of authentication types between different operating systems. In the latter section of this chapter, we will discuss password requirements and the different techniques that you can use to employ them in a Windows Server 2003 environment.

Designing Authentication for Active Directory

In a server-based networked environment, where resources are centrally stored and managed on servers, there are typically two functions to securing resources:

• Authentication, which is the process of determining an identity (for example, a user)

• Authorization, which is the process of determining the resources the user can access once authenticated

You must consider the authentication requirements of your entire organization when designing the authentication infrastructure. This includes services that your company exposes, applications that contain their own authentication mechanism, even the level of remote access that you intend to support. Obviously, a heterogeneous environment can add a level of complexity to your design considerations, but even on an all-Microsoft network, there are several authentication methods that are used. Users may authenticate locally, remotely, or over the Internet.

Authentication security is critical in thwarting potential vulnerabilities of your organization. It is common for an attacker to attempt to obtain valid credentials from a machine or service that they have already compromised.

You will need to make sure that your passwords are kept secure no matter how or where they’re stored. One of the most egregious violations of this is when the user writes their network password on a piece of notepaper and tapes it to their monitor.

Any user that takes resources off site will need to be properly trained on the storing of passwords and other sensitive material. Specifically, users with laptops will need to learn about the different techniques that they can employ to further secure the data on their computer. The Windows Encrypting File System (EFS) is an excellent way to further secure data on a mobile computer that is not physically secured on site.

Note

EFS is covered in Chapter 5, “Designing an Access Control Strategy for Network Resources.”

There are three types of vulnerabilities that pertain to authentication, and all can be used to compromise an entire organization:

Passwords The importance of keeping passwords secure goes without saying; you need to make sure that you avoid the common vulnerabilities of passwords. One of the main goals in your password security strategy should be to prevent passwords from falling into the hands of unauthorized individuals. There are many utilities available that give a computer on a network the capability to record all of the packets that are being transmitted across the network. There are several resources that accept the username and password in cleartext; this is especially common across the Internet. The cleartext transmission is usually a result of IIS configured to use basic authentication when receiving the credentials from the user. Unfortunately, other types of IIS authentication are not supported by most browsers. You should prevent passwords from being transmitted in cleartext. An attacker could sniff the authentication packets, and a simple analysis of the packets would reveal the logon credentials, password included.

If you allow users to log in to your network from outside of the office, including accessing Outlook Web Access (OWA) or a secure Internet website, you will need to make sure that the credentials being transmitted are encrypted to prevent passwords from being sniffed. You can secure this type of remote access by using Secure Sockets Layer (SSL) to encrypt all of the traffic to your Internet site or by requiring that all access to the network’s resources be through a virtual private network (VPN) connection. SSL is used when accessing websites using the HTTPS protocol as opposed to the non-encrypted HTTP protocol.

Consider the Real-World Scenario “Cleartext Passwords Across a Network” when gauging the vulnerability of passwords being transmitted in clear- or plaintext.

There are also several examples of Trojan horse applications or keystroke logging utilities that store and forward passwords to an attacker. You’ll need to make sure that you have appropriate policies in place to prevent this software from getting installed. There are also products that need only the hash of the password in order to break the password. One of the best examples of this is L0phtcrack from @stake, or LC4 as it is now called, which can sniff the hash on the network and then attack it using dictionary or brute force attacks. To prevent this from happening in your organization you’ll want to make sure that the password hashes are not sent across the network.

You can see LC4 in Figure 4.1 after only a few seconds of processing a typical network password list. Using a utility like LC4, most passwords are broken in the first few minutes. You can minimize its usefulness by not storing passwords on the local machine and preventing its installation on a machine that has access to your network.

Figure 4.1: LC4 password recovery

There are several available network utilities that will let you detect when a network card is placed in promiscuous mode, which allows it to record all packets—including those not destined for it. Also, certain types of network hardware can prevent most sniffing utilities from working easily. One of the best ways to prevent all types of attacks is to prevent an unknown computer from gaining access to your network. The same notion can be applied to software. Don’t let unknown software be installed on any computer that accesses your network.

Real World Scenario: Cleartext Passwords Across a Network.

Jim is a traveling salesman for InnaTech banking software and accesses his e-mail remotely, including from his home, where he has cable modem access. InnaTech has enabled Outlook Web Access (OWA) and made it available outside the corporate firewall. The IIS web server is configured to use basic authentication through HTTP (port 80) so that Jim and the other salespeople can access their e-mail, calendar, and contacts from anywhere.

Because InnaTech uses both basic authentication and an insecure communications channel, anyone on the network that Jim uses to check his e-mail would be able to sniff his credentials from the network and the credentials will be in cleartext. If Jim uses his home computer, in many cases his neighbors would be able to sniff his network packets traveling to and from his provider. In addition to the vulnerabilities associated with a cable modem, they could also be sniffed from a wireless network at a coffee shop or in an airport.

If Jim and the other salespeople truly need this access, you should, at a minimum, require SSL and use a higher level of authentication such as Integrated or Digest.

Real World Scenario: Stored Credentials Are Easy to Exploit

Marc is the server administrator at a small consulting company named WTF Consultants. Marc manages all of the Windows 2000 and Windows Server 2003 servers for his company and does most of the management, patch installation, service pack installation, and so on from his laptop computer using a Terminal Services session. Marc is tired of entering the long and complex passwords required for him to log on to these servers remotely and decides that he will store the password in an RDP file on his notebook along with the other settings for the connection to the server. The following screen shot shows the Remote Desktop Connection Editor.

His credentials are cached in the file, which is now stored on his laptop. The file does encrypt the password. Should someone open it using a text editor, they would see something similar to this.

Now that this file exists on his laptop, he simply double-clicks the previously saved RDP file and his terminal session opens and logs him on.

Marc has exposed himself and his server to a couple of vulnerabilities. First, should someone gain access to the RDP file, they would be able to use his credentials to log on to WTF’s servers without even trying to break the password. In addition, even though the password is encrypted, it is stored in the file and could be broken in time.

One rule of thumb that you should maintain is that, whenever possible, do not store credentials. It may be a nuisance to enter the password, which is thankfully complex, but it would be a bigger nuisance to have to recover from an attack.

Interoperability and Compatibility If you are using older systems or software, you are only as secure as the weakest system. As you will learn later in this chapter, a trust relationship between a Windows Server 2003 domain and a Windows NT 4 domain is much less secure than between Windows 2003 domains. In addition, if you must have authentication in place that is compatible with a non-Microsoft network operating system, you may be forced to lower the functionality of your authentication in the name of compatibility.

Encryption Passwords that are stored somewhere need to be using a strong encryption algorithm. Older authentication methods tend to use weak encryption, which is only marginally better than no encryption at all. Many older applications or operating systems use weak encryption that can be easily broken.

In the “Evaluating Windows Authentication Methods” Design Scenario, you will be evaluating a scenario and determining the potential decisions that you will need to make regarding authentication in Active Directory.

Once an account is successfully authenticated, with either the correct username and password combinations or a valid smart card, there is little that can be done to determine the validity of the person using the account. To prevent these incidents from occurring you must design a secure authentication strategy. This is accomplished by designing security for authentication. In the next section, you will learn how to design a secure authentication strategy that is in line with your organization’s business requirements.

Determining Authentication Requirements

When determining your organization’s authentication requirements, you’ll need to analyze its business requirements. There are two fundamental steps in determining the authentication requirements of your network: first you must determine the effect of the business requirements on your network, and then you must determine the interoperability requirements.

Many organizations have strict authentication requirements that must be in accordance with government regulations. You’ll want to discover these types of requirements in the early stages of design because your business’s viability may be dependent on meeting them. You will need to talk

Design Scenario: Evaluating Windows Authentication Methods

You are the administrator for a small certified public accounting firm, Hunter Cliffs Incorporated, that works primarily with individuals. The company has been in business for over 50 years and is in the process of reengineering the way that its employees interact with its customer base. The company wants to attract new and diverse customers by updating its business model to do business across the Internet. Hunter Cliffs has three Windows Server 2003 servers participating in a native Windows 2003 domain. The application developer on staff has decided to create a web application that will allow customers to fill out their financial information on a web page and submit it over the Internet to the customer database. This will allow for an automated evaluation followed by an employee evaluation before the tax form is finalized. You need to design a solution that will give each customer secure access to the new web system.

The proposed solution is to create a text file that will store the tax data for each customer on the web server. When users access the secure tax information page, they enter their credentials using a web form at the following address: http://www.hctaxescorp.com/taxdata.asp. On the web server, basic authentication has been enabled and you must create user accounts for all customers wishing to access this system.

1. Question: Is this proposed solution a secure one? Why or why not? Answer: The site that the user s enter their credentials on is insecure because HTTP is used instead of HTTPS. In addition, basic authentication is in place, which means that the usernames and passwords will be transmitted from the customer to your web server in plaintext and would be an excellent target for an attack.

to your supervisor to determine if there are external security requirements that your design must adhere to. If there is a department dedicated to standards and practices, the department members may have the information that you require. When you are conducting your interviews, you’ll want to pay attention to any statement that guarantees security or privacy. A marketing vice president, for example, may mention a privacy policy that guarantees “…that customer information will be viewed only by valid corporate representatives.” This type of statement would require that customer data be specifically addressed in the authentication design.

Once you have established external authentication constraints, you need to determine the interoperability requirements with older operating systems. If you must incorporate Windows 95 or Windows NT 4 workstations into your design, it will play a role in determining the type of authentication that can be used. You must also determine any application compatibility requirements; many applications require a specific authentication mechanism. To determine what operating systems you must support, you’ll need to audit your company’s computing infrastructure. You will need to learn the applications and services running in your organization so that you can make the appropriate interoperability design considerations.

Once you’ve discovered all of this information, you will be in a better position to begin the design phase. In the section that follows, you will be introduced to the different protocols that are used for network authentication as well as the issues that each one introduces to your environment.

Selecting the Authentication Protocols to support

There are several techniques that Windows supports for authentication on a local area network (LAN). It’s important to determine, given your environment, which authentication protocol to support. Typically, the new types of authentication are stronger but are less likely to be compatible with older applications and environments. In Windows 2000 and higher, the Security Support Provider Interface (SSPI) will determine which authentication protocol should be used for account validation.

The following network authentication protocols are supported in Windows Server 2003 (LAN Manager–based protocols are less secure than Kerberos v5, explained later in this section):

LAN Manager The LAN Manager protocol is used by older Microsoft operating systems such as MS-DOS and Windows 95. This authentication protocol is the least secure method supported in Windows 2000 and Windows Server 2003 and therefore should be used only if the computers must access resources being served by computers running MS-DOS, Windows 95, or Windows 98 operating systems. If your organization does not require LAN Manager, you should remove the LAN Manager password hashes from the account database because an attacker can easily crack a LAN Manager password hash. You should remove the hashes using Group Policy or simply require that passwords be greater than 14 characters long.

NT LAN Manager (NTLM) The NT LAN Manager (NTLM) protocol does a better job of storing passwords than LAN Manager does. NTLM is the default authentication protocol for Windows NT 4 domains and for local SAM accounts in Windows 2000 and Windows XP.

NTLM Version 2 (NTLMv2) The NTLM Version 2 (NTLMv2) protocol is the most secure of the LAN Manager–based protocols in Windows 2000 and Windows XP. This protocol is also available for Windows 95 and newer Microsoft operating systems if the Active Directory client extensions are installed. The NTLMv2 protocol performs mutual authentication and can be more secure when session security is added. Session security will cause the connection to fail if the NTLMv2 protocol is not negotiated.

You can select how the computers in your environment will use the LAN Manager and NTLM authentication by configuring the LAN Manager compatibility level through Group Policy or manually editing the Windows Registry. You should always choose the highest level that your infrastructure and applications support. Table 4.2 explains each level.

You can configure the LAN Manager compatibility level using the Group Policy or local security MMC snap-ins under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\LAN Manager Authentication Level in Windows Server 2003 and Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network Security: LAN Manager Authentication Level in Windows XP.

Table 4.1: Table 4.2 LAN Manager Compatibility Levels

Level	Description
0	Clients use LAN Manager and NTLM authentication and never NTLMv2 session security.
1	Clients use LAN Manager and NTLM authentication and will use NTLMv2 session security if it is supported by the authenticating server.
2	Clients use only NTLM authentication and will use NTLMv2 session security if it is supported by the authenticating server.
3	Clients use NTLMv2 authentication and will use NTLMv2 session security if it is supported by the authenticating server.
4	Clients use NTLM authentication and use NTLMv2 session security if the authenticating server supports it. Domain controllers will reject NTLM and LAN Manager authentication, only accepting NTLMv2.
5	Clients use NTLMv2 authentication and will use NTLMv2 session security if it is supported by the authenticating server. Domain controllers will reject NTLM and LAN Manager authentication, only accepting NTLMv2.

Tip

There is no way to disable NTLM-based authentication completely in Windows 2000 or Windows XP.

The most secure authentication protocol supported by Windows Server 2003 is Kerberos version 5.

The Kerberos v5 authentication protocol is the default authentication protocol for computers running Windows 2000 or higher that are in Active Directory domains. When coupled with strong passwords, the Kerberos v5 protocol is considered the strongest authentication protocol in the Windows arsenal. The Kerberos protocol supports smart cards for multifactor authentication and adheres to RFC 1510. When you use Kerberos, you can interoperate with Unixbased operating systems by creating a trust relationship with a Kerberos realm. Kerberos authentication, to prevent the replay of the information, requires that all computers involved have their time synchronized within a defined threshold (5 minutes in Active Directory).

In the next Design Scenario, you’ll learn how to design client authentication.

In the next section, you will learn about the trust models that apply to both domain and forest design. You’ll learn which trusts are created automatically and which you have to create by hand. You will also determine which of the non-default trusts would better suit a specific infrastructure.

Design Scenario: Designing Client Authentication

Luke Worrall & Associates is a national accounting firm with over 12,000 employees nationwide. LW&A has offices in Dover, Philadelphia, Miami, Minneapolis, and San Francisco. Each office has its own IT staff that reports to the corporate IT staff located at the corporate headquarters in Dover. LW&A has upgraded all of its domain controllers to Windows Server 2003 and has implemented Active Directory running in Windows 2003 Native mode. There are several different operating systems that employees use. LW&A is in the process of standardizing on Windows XP Professional. The offices in Dover, Philadelphia, and Minneapolis are all running Windows XP Professional. The office in Miami has mostly Windows XP Professional, but there are still some desktops running Windows 98, Second Edition and Windows NT 4 Workstation. The office in San Francisco was recently acquired from a competing firm and has two Unix servers. The Unix servers run specific software that the employees in the San Francisco office need to access. All other servers in San Francisco are running Windows Server 2003 and all of the workstations are running Windows XP Professional.

Each office has its own domain organized as in the following graphic:

1. Question: You decide to implement NTLMv2 as the least-secure protocol that will be accepted by the domain controllers in your Dover, Miami, and Minneapolis offices to ensure a secure computing environment. What are potential problems and incompatibilities that may result from this implementation and how would you rectify them? Answer: There are no issues with regard to Dover and Minneapolis. All servers are running Windows Server 2003 and all workstations are running Windows XP Professional, which nati vely supports NTLMv2. In Miami, however, the Windows 98, Second Edition and Windows NT 4 workstations cannot authenticate using NTLMv2 and requiring NTLMv2 as the least-secure protocol that will be accepted on the servers in Miami will prevent these older operating systems from authenticating to the domain. To resolve the problems stated, you would need to install the Active Directory client extensions on the machines running Windows 98, Second Edition and Windows NT 4 or upgrade their operating systems to Windows 2000 or XP Professional.

2. Question: You must incorporate the Unix servers in San Francisco into your network strategy and cannot require the users in that office to have more than a single logon. The users at the San Francisco office must be able to access the data and the services published from the Unix servers. What tasks do you need to complete in order for this problem to be resolved? Answer: You could use Kerberosv5 authentication and create a trust relationship between the San Francisco domain and the Kerberos Unix realm.

---