Because down-level clients don't support Kerberos authentication, you need to do some planning to allow these clients to authenticate with Active Directory without compromising security on the network.
After this lesson, you will be able to
- Design secure authentication for down-level clients by deploying the Microsoft Directory Services Client
Estimated lesson time: 30 minutes
Analyzing Standard Authentication
Without service packs or additional software, Windows NT 4.0, Windows 95, and Windows 98 clients introduce security weaknesses for authentication on a Windows 2000 network.
Windows NT 4.0 clients without service packs will use the NTLM authentication protocol. Password crackers recently have found ways to decrypt the authentication information that's exchanged between a DC and an authenticating client if it's only protected using NTLM. As mentioned earlier, NTLMv2, introduced in Windows NT 4.0 Service Pack 4, provides stronger authentication protection by using NTLMv2 for authentication.
With Windows 95 and Windows 98 clients the problems are even more evident. By default, these clients use LAN Manager (LM) authentication protocol which is the weakest of the authentication protocols in a Windows 2000 environment. As discussed in Lesson 1, the continued use of LM authentication can lead to the decryption of sensitive account passwords if they're maintained in LM format within Active Directory.
The Microsoft Directory Service Client (DSClient) has been developed to counteract these weaknesses. The DSClient software allows Windows NT 4.0, Windows 95, and Windows 98 clients to use NTLMv2 for authentication in the Windows 2000 network. The following section outlines some of the features of the DSClient software.
The DSClient software for Windows 95 and Windows 98 is included on the Windows 2000 CD in the \clients\win9x folder. The Windows NT 4.0 DSClient software will be shipped with Windows NT 4.0 Service Pack 7.
Analyzing the Directory Services Client
The Directory Services Client provides additional functionality to down-level clients so that they can operate securely and efficiently in a Windows 2000 network environment. When it's installed, the DSClient software adds the following functionality to a client:
- NTLMv2 authentication protocol. Windows 95, Windows 98, and Windows NT 4.0 clients will use NTLMv2, rather than weaker forms of authentication, when authenticating with Active Directory.
- Site awareness. The DSClient software allows the client to query DNS to find a DC in the same site.
- Search for objects in Active Directory.The DSClient software allows clients to search Active Directory for printers and users from the Start|Search menu.
- Reduces dependency on the PDC. Rather than having to connect to the PDC of the domain for password changes, the DSClient software allows down-level clients to connect to any DC in the domain for password changes.
- Active Directory Services Interface (ADSI). The DSClient software provides a common programming API for Active Directory programmers. This allows scripting to take place at the client that writes changes to Active Directory.
- Distributed Files System (DFS) fault tolerance client. The DSClient software allows clients to access and find Windows 2000 DFS file shares in Active Directory.
- Active Directory Windows Address Book (WAB) property pages. The DSClient software allows users to change attributes of their user object using the Start|Search|For People menu option. This is, of course, subject to the security settings on their user object.
It's also important to note that there are some features that the DSClient software doesn't provide. These features require you to upgrade to Windows 2000 as the client operating system:
- Kerberos support. The DSClient software doesn't provide Kerberos support to Windows 95, Windows 98, and Windows NT 4.0 clients. They can use only NTLMv2 to strengthen authentication security.
- Group Policy/Intellimirror support. Even with the DSClient software loaded, a Windows 95, Windows 98, or Windows NT 4.0 client won't participate in Group Policy or Intellimirror. To deliver similar functionality, system policy must be maintained in the Active Directory environment.
By default, Windows 95 and Windows 98 clients will connect to the PDC unless the Load Balancing option is enabled in system policy. This is enabled in Default Computer|Network|System Policies Update|Remote Update And Setting The Load Balancing option. This will allow the Windows 95 or Windows 98 client to load system policy from the authenticating DC.
- IPSec/L2TP support. Windows 95, Windows 98, and Windows NT 4.0 clients only support PPTP for VPN connections. There's no support for L2TP/IPSec connections.
- Server Principal Name (SPN)/mutual authentication. The DSClient doesn't provide SPNs or mutual authentication to Windows 95, Windows 98, and Windows NT clients.
- Dynamic DNS support. The DSClient software doesn't allow Windows 95, Windows 98, or Windows NT clients to update their own DNS resource records using dynamic update. For Windows 95, Windows 98, and Windows NT clients, the Dynamic Host Configuration Protocol (DHCP) server must be configured to update the DNS resource records on behalf of the client computers.
- User Principal Name (UPN) authentication. The DSClient software doesn't allow users to authenticate using their UPN (firstname.lastname@example.org). This functionality is only available in Windows 2000 clients.
Once you've distributed the DSClient software to your down-level client computers, you can restrict which protocols can be used to authenticate with a Windows 2000 computer. You do this by adjusting registry value HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel at all Windows 2000–based computers in the domain, and setting one of the following six values for the REG-DWORD value:
- 0 (send LM & NTLM responses). Offers the most interoperability. Any previous down-level clients that use either LM or NTLM for authentication can authenticate with the server.
- 1 (Send LM & NTLM–use NTLMv2 session security if negotiated). Offers more security when the DSClient software is deployed. If the client computers support NTLMv2, this setting allows the use of NTLMv2 to be negotiated. It's best to use this setting during the deployment of the DSClient software. Clients that have the DSClient software installed use NTLMv2, but the setting won't prevent the authentication of clients who haven't installed the software yet.
- 2 (Send NTLM response only). More useful in Windows NT networks where you want to restrict the use of Windows 95 and Windows 98 clients. This setting prevents the connection of all down-level clients if the DSClient software were deployed to all Windows 95, Windows 98, and Windows NT clients.
- 3 (Send NTLMv2 response only). Configures the Windows 2000 computer to respond with NTLMv2 authentication for down-level authentication requests. You should use this only if all down-level clients have the DSClient software installed, because it will prevent those clients from authenticating with the network.
- 4 (Send NTLMv2 response only\refuse LM). Configures the Windows 2000 computer to respond with only NTLMv2 authentication for down-level authentication requests. If LM authentication requests are sent to the Windows 2000 computer, they're rejected and no NTLMv2 response is sent. This will restrict access to only Windows 2000 computers, and Windows NT, Windows 95 and Windows 98 clients using the DSClient software.
Windows NT 4.0 with Service Pack 4.0 or later will also support NTLMv2 authentication.
- 5 (Send NTLMv2 response only\refuse LM & NTLM). Ensures that only NTLMv2 responses are sent and that authentication requests that don't use NTLMv2 will be rejected. This prevents Windows NT 4.0 clients that don't have Service Pack 4 or greater from connecting to the server. In this scenario, only Windows 2000, Windows NT 4.0 clients with either SP4 or later, or Windows NT 4.0, Windows 95, and Windows 98 clients with the DSClient software will be able to connect to the Windows 2000 computers.
You can deploy the LMCompatibilityLevel setting using Windows 2000 Group Policy. You do this by editing Group Policy at the container where the Windows 2000 computer accounts reside with the following Group Policy setting:
Group Policy Container\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\LAN Manager Authentication Level.
This Group Policy setting will ensure that consistent application of the LMCompatibilityLevel setting takes place. For DCs, be sure to apply this at the Domain Controllers OU. For all other Windows 2000 computers, you can simply apply this Group Policy setting at the domain level.
For details on configuring Windows 95 and Windows 98 clients to use NTLMv2 authentication, see Q239869; How to Enable NTLM 2 Authentication for Windows 95-98 Clients on the Supplemental Course Materials CD-ROM (\chapt03\Q23986.mht).
Making the Decision
When Windows 95, Windows 98, and Windows NT 4.0 clients exist on the network, the default authentication mechanisms for the clients don't use the strongest available form of authentication. To increase the authentication level, you must include the following steps in your design process for authentication:
- Distribute the DSClient software to all clients. All Windows 95, Windows 98, and Windows NT 4.0 clients should have the DSClient software installed. Not only does it allow the use of NTLMv2 for authentication, but also the DSClient software makes clients site-aware and less dependent on the Primary Domain Controller (PDC).
- Ensure that all Windows NT 4.0 clients have the latest service pack installed. NTLMv2 functionality was introduced in Windows NT 4.0 Service Pack 4.
- Develop a plan for the distribution of the DSClient software and any registry updates that must be performed for client computers.
- Once all clients have been upgraded to use the DSClient software, set the LMCompatibilityLevel at the servers to require NTLMv2 authentication.
- Replace or upgrade all older client computers from the network if they can't support NTLMv2 authentication.
Applying the Decision
Each of Market Florist's four office locations has down-level clients. Based on the current network configuration, these down-level clients by default use less secure authentication mechanisms.
In the authentication security plan, Market Florist must include the following steps:
- Market Florist must ensure that a plan is created for the distribution of the DSClient software to all Windows 95 and Windows NT 4.0 client computers. The DSClient software will increase the performance and strength of down-level client authentication by allowing local password changes and use of NTLMv2 for authentication.
- Market Florist must ensure that all necessary registry settings are deployed to Windows NT 4.0 and Windows 95 clients to ensure that the client computers will use NTLMv2 rather than LM or NTLM authentication.
- You must configure Group Policy after the DSClient software is fully deployed to allow only NTLMv2 authentication to be used. You must not configure this setting until all down-level clients have the DSClient software and necessary registry settings, or the down-level clients will lose access to all network data. The setting that you must apply is Group Policy Container \Computer Configuration\Windows Settings\Security Settings\LocalPolicies\Security Options\LAN Manager Authentication Level. This must be applied at each OU where Windows 2000 computers exist.
- DNS services must be configured locally at each site to ensure that down-level clients using the DSClient software can locate local DCs and global catalog servers in the event that the WAN link is down and DNS services can't be contacted.
Down-level clients can potentially introduce security weaknesses to the network if you don't create the proper design. Plan the deployment of the Directory Services Client so that Windows 95 and Windows 98 can utilize NTLMv2 authentication. The deployment of the Directory Services Client will also change your infrastructure requirements as it removes the dependency of down-level clients on the PDC emulator in a domain.
Your network design must include server placement strategies. A down-level client must be able to access the necessary services in the event of a WAN link failure to access the network. Careful planning can reduce down time in the event of a WAN failure.