Exam 70-124: Objective 4.1, 4.1.1: Configuring User Authentication

Very few companies run Windows 2000 as their only operating system. Most companies run a mixed environment of Windows 2000 Server and Windows NT 4.0 Server on their servers and a mixture of Windows 95, Windows 98, Windows NT 4.0 Workstation, and Windows 2000 Professional on their desktops. It is not uncommon for companies to run UNIX servers as well. More and more, administrators may also find themselves having to provide authentication means for users who are external to their network.

From a security standpoint, it is important to know how older operating systems work in the areas of authentication and file security. Security concerns have changed a great deal since the introduction of Windows 95, thus special attention must be paid to local security and authentication security. The best security is achieved when Windows 2000 is run exclusively. Running other systems, especially Windows 95 and Windows 98, weakens network security every time a client logs in. This section covers how to make Windows 95, Windows 98, and Windows NT 4.0 more secure when they authenticate to a Windows 2000 domain. It also examines how to authenticate external users to a domain and how to enable authentication for UNIX servers and legacy Microsoft clients.

Exam 70-124: Objective 4.1.3: Authentication for External Users

External users can easily be authenticated against an Active Directory domain once trust has been established a between your domain and the external domain. Once this trust has been established, security principals from the trusted external domain are automatically represented by a Foreign Security Principal object, which can then become a member of domain local groups. As these objects are automatically created by Active Directory, the administrator does not need to perform any manual modifications of them other than assigning Group membership. To view these foreign security principals, administrators need to enable Advanced Features within Active Directory Users and Computers (see Figure 8.23)

Figure 8.23: Enabling Advanced Features

If there are no trusts established, the administrator can still authenticate external users via Internet Information Server (IIS) using Secure Sockets Layer (SSL), discussed later in this chapter.

Exam 70-124: Objective 4.1.2: Configuring Interoperability with UNIX Servers

The type of authentication used by UNIX clients depends on the applications being used. UNIX clients can authenticate using any of the following methods:

• Cleartext authentication

• Certificate-based authentication

• Kerberos v5 protocol

• NTLM protocol

Using Cleartext Authentication

When UNIX clients use standard applications from the Transmission Control Protocol (TCP)/IP protocol suite, they can authenticate to Active Directory using cleartext authentication. These applications include the FTP, the Trivial File Transfer Protocol (TFTP), the Hypertext Transfer Protocol (HTTP), and Telnet. Unfortunately, cleartext authentication provides no security. Someone could read the packets on the cable and compromise the username and password.

If using cleartext authentication, the administrator should encrypt the communications with the server. They could use Secure Internet Protocol (IPSec) or SSL to encrypt authentication information. SSL is an application layer encryption method; IPSec is a network layer encryption method. In other words, applications must be SSL aware in order to use SSL. IPSec-encrypted packets appear as normal IP packets to applications, so no special support is needed (other than TCP/IP support).

Using Certificate-based Authentication

UNIX clients that are accessing Web sites can use certificate-based authentication. If accessing an SSL- or Transport Layer Security (TLS)-encrypted Web site, they would need a certificate that is trusted by that Web site. This requires both the client and the server to either have the same certificate authority or for their certificate authorities to trust each other. If this is not the case, client authentication fails.

Using the Kerberos v5 Protocol

There are two possible ways that UNIX clients can use Kerberos for authentication:

• They can authenticate directly to a Windows 2000 domain controller. They would view this domain controller as their KDC. Any Windows 2000 domain controller can fulfill the role of KDC.

• They can manually configure a trust relationship between the Windows 2000 domain and the UNIX realm (recall that a realm in UNIX is similar to a domain in Windows).

No matter which method is chosen, the UNIX client must have an account in Active Directory and the Active Directory account must be mapped to the UNIX account. If either of these steps is omitted, Kerberos authentication will not work.

Using NTLM Authentication

UNIX clients can use NTLM only if they are running an additional product that allows them to use Server Message Block (SMB) or Common Internet File System (CIFS). Two such products are Samba and LM for UNIX. If clients are using Samba, they must be running at least version 2.0.6. Any earlier version will result in cleartext authentication.

Configuring Interoperability with Legacy Windows Clients

Microsoft considers all clients running Microsoft operating systems earlier than Windows 2000 to be down-level clients. The most commonly seen legacy (down-level) clients in a network are:

• Windows 95

• Windows 98

• Windows NT 4.0

Each version of Windows has its own default authentication method. Whenever one of these clients authenticates to a Windows 2000 server, it attempts to use its default authentication method. These methods are:

• LM  This is the default for Windows 95 and Windows 98

• NTLM  This is the default for Windows NT 4.0

• NTLMv2  Windows 95, 98, and NT 4.0 can be configured to use NTLMv2

• Kerberos  This method is used by Windows 2000 clients only

Defining LM and NLM Authentication

LM and NTLM are forms of challenge/response authentication. LM is the weakest form of challenge/response authentication. LM is maintained in Windows 2000 for backward compatibility with Windows 3.x and Windows 9.x. It allows Windows 2000 machines to connect to shares on down-level clients. It also allows legacy clients to access a Windows 2000 machine with their default authentication method.

NTLM, the default authentication protocol used in Windows NT 4.0, can be used when computers running Windows 3.x, Windows 9.x, or Windows NT 4.0 authenticate to a Windows 2000 computer. Windows 2000 still supports NTLM for backward compatibility with these down-level clients.

At times, Windows 2000 uses NTLM to access resources. For instance, if computers are standalone servers or members of a workgroup rather than a domain, NTLM is used as the authentication method. When a Windows 2000 server authenticates to a Windows NT 4.0 server, NTLM is used. There are two versions of NTLM: NTLM version 1 and version 2.

Using the Directory Services Client

The purpose of the directory services client (dsclient) is to allow legacy clients to use some of the new features available to Windows 2000. There are two clients: one for Windows 9.x machines and one for Windows NT 4.0 machines. The Windows NT 4.0 directory services client can be downloaded from http://support.microsoft.com/default.aspx?scid=KB;en-us;288358. The Windows 9.x version of the client ships on the Windows 2000 Setup CD. Look in the client\Windows9x folder. The name of the setup executable is dsclient.exe.

Some of the features provided by installing the dsclient are:

• NTLMv2  Legacy clients now use NTLMv2 rather than the weaker NTLM, when authenticating in Windows 2000 domains.

• Site Awareness  This allows client computers to perform queries against DNS to locate the closest domain controller.

• Active Directory Searching  This allows client computers to search Active Directory for a limited number of objects, including printers and users from the Search command on the Start menu.

• Easier Password Changes  The client no longer has to locate and connect to the PDC emulator to change a password. Password changes can be done by connecting to any domain controller.

• Dfs Capability  Clients are now capable of using Distributed file Share (Dfs) shares in Active Directory.

Some of the best features in Windows 2000 will still not be available to legacy clients after installing the dsclient. They include:

• Kerberos  Only Windows 2000 clients can use Kerberos for network authentication.

• Group Policy and Intellimirror  Only Windows 2000 clients can take advantage of the simplified and powerful management features offered by Group Policy and Intellimirror. The closest thing for legacy clients is the continued usage of system policies.

• IPSec and Layer 2 Tunneling Process (L2TP)  There is no native support for IPSec or L2TP in legacy clients provided by the dsclient.

• User Principal Name (UPN) Authentication  Legacy clients cannot authenticate using their UPN ([e-mail]).

Deploying NTLM Version 2

Installing the dsclient to get NTLMv2 support is perhaps the most important reason to install it on the legacy clients. By default, Windows 2000 allows clients to use their default authentication protocols (LM for Windows 9.x and NTLM for Windows NT 4.0). There are two steps to requiring NTLMv2 for use. Step one is configuring the domain controllers to require NTLMv2 and is outlined in Exercise 8.07. Step two involves configuring the clients to use NTLMv2 and is the subject of Exercises 8.08 and 8.09.

Exercise 8.07 : Configuring the Servers to Require NTLMv2

1. Open Active Directory Users and Computers from the Administrative Tools menu (Start | Programs | Administrative Tools | Active Directory Users and Computers).

2. Right-click the Domain Controllers Organization Unit and choose Properties. You will see the Domain Controllers Properties window shown in Figure 8.24.

   
   Figure 8.24: The Domain Controllers Properties Window

3. In the Domain Controllers Properties window, click the Group Policy tab.

4. Use your pointer to select the Default Domain Controllers Policy, and then click Edit.

5. Once in the Group Policy window, navigate to Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options (see Figure 8.25)

   
   Figure 8.25: The Group Policy Editor Window

6. In the details pane (the right side), double-click LAN Manager Authentication Level. This will give you the Security Policy Setting window shown in Figure 8.26.

   
   Figure 8.26: The Security Policy Setting Window

7. Choose the desired setting from the Security Policy Setting Window and click OK.

8. Close the Group Policy window and close Active Directory and Computers.

Each domain controller has six possible settings for its LM authentication level:

• Send LM & NTLM responses

• Send LM & NTLM - use NTLMv2 session security if negotiated

• Send NTLM response only

• Send NTLMv2 response only

• Send NTLMv2 response only\refuse LM

• Send NTLMv2 response only\refuse LM & NTLM

As long as the directory service client is installed on all the legacy clients, it is all right to refuse LM authentication. Administrators should be cautious with this setting, however. If it is enabled it and they still have Win9.x clients without the dsclient installed and configured, those clients will not be able to authenticate to the domain.

Making Clients Use NTLMv2

Configuring legacy clients to use NTLMv2 as their preferred authentication method is not as easy as configuring the server. To enable the clients, administrators must edit the registry. Luckily, it is edited in the same location in the registry as Windows 9.x and Windows NT.

For Windows 9.x clients, the dsclient must be installed before making changes to the registry. Exercise 8.08 walks through the steps for configuring Windows NT 4.0 to use NTLMv2. Exercise 8.09 walks us through configuring Windows 9.x to use NTLMv2.

Exercise 8.08: Configuring Windows NT 4.0 Clients to Use NTLMv2

1. Open a registry editor, such as regedit or regedt32.

2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

3. Add the following value (if the value is already present, verify it):

   • Value Name: LMCompatibilityLevel

   • Data Type: REG_DWORD

   • Value: 3 (possible values are 0 through 5)

Table 8.2 defines the possible values for this key.

Table 8.2: LM Compatibility Levels

Value	Description	Clients Use	Server Supports
0	Never use NTLMv2 session security. Always use LM or NTLM.	LM or NTLM	LM, NTLM, NTLMv2
1	Only use NTLMv2 session security if negotiated.	LM, NTLM, NTLMv2	LM, NTLM, NTLMv2
2	Use NTLM only.	NTLM, NTLMv2	LM, NTLM, NTLMv2
3	Use NTLMv2 only.	NTLMv2	LM, NTLM, NTLMv2
4	Domain controllers deny LM responses.	NTLM, NTLMv2	NTLM, NTLMv2
5	Domain controllers deny LM and NTLM responses	NTLMv2	NTLMv2

To configure Windows 9.x clients to use NTLMv2, complete the steps outlined in Exercise 8.09.

Exercise 8.09: Configuring Windows 9.x Clients to Use NTLMv2

1. Install Internet Explorer 4.x or higher if it is not already installed. Microsoft recommends upgrading to 128-bit support if your local import and export laws allow it. For Windows 95 clients, you need to have the active desktop feature turned on before you go to Step 2.

2. Install the directory services client. It can be found on the Windows 2000 CD at client\Windows9x\dsclient.exe.

3. Open a registry editor, such as regedit or regedt32.

4. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

5. Add the following value (if the value is already present, verify it):

   • Value Name: LMCompatibilityLevel

   • Data Type: REG_DWORD

   • Value: 3 (Possible values are 0 through 5)

6. Again, refer to Table 8.2 for the possible values for this key.

Head of the Class…
Verifying Your Encryption Level

Depending on export laws, if you intend to export, install, or configure a PC outside the United States or Canada, you need to make sure that you are only running 56-bit encryption. Use the following steps to verify the encryption level on your PC:

1. Navigate to %windir%\system (system32 for NT 4.0 clients).

2. Right-click the secur32.dll file.

3. Go to Properties and click the Version tab.

4. The description tells which version you are running:

   • A description of Microsoft Win32 Security Services (Export Version) means that you are running 56-bit encryption.

   • A description of Microsoft Win32 Security Services (U.S. and Canada Only) means that you are running 128-bit encryption.