Designing Authentication for a Microsoft Windows 2000 Network

Designing Authentication in a Microsoft Windows 2000 Network

Designing Kerberos Authentication NTLM Authentication Authenticating Down-Level Clients Planning Server Placement for Authentication

Planning server placement Planning domain controller (DC) placement Planning global catalog server placement Planning PDC emulator placement

Designing Authentication in a Microsoft Windows 2000 Network

Business requirements Reduce total cost of company's ownership Identify security risks in the network

Technical requirements Network authentication must be available even if

WAN links are not. Network authentication must occur in a timely

manner. DCs must not be overloaded with authentication

requests.

Business Requirements

Reduce total cost of company’s ownership Identify security risks in the network

Technical Requirements

Network authentication must be available even if WAN links are not.

Network authentication must occur in a timely manner.

DCs must not be overloaded with authentication requests.

Designing Kerberos Authentication

Advantages of Kerberos authentication Understanding the Kerberos message

exchanges Analyzing Kerberos authentication Making the decision: designing Kerberos

authentication Applying the decision: designing Kerberos

authentication

Advantages of Kerberos Authentication

Mutual authentication Single sign-on Ticket caching Delegation Standards-based protocol Interoperability

Understanding the Kerberos Message Exchanges

Authentication Service Exchange Ticket Granting Service Exchange Client/Server Authentication Exchange

Initial Authentication with the Network

The Authentication Service Exchange is used when a user initially logs on.

This provides the user with a logon session key and a ticket granting ticket (TGT ) that will be used to acquire service tickets (STs) during the session.

Information contained within the KRB_AS_REP message is encrypted with the user's long-term key.

Each user shares a long-term key with the key distribution center (KDC).

The long-term key is derived from the account's password.

The Kerberos Authentication Exchange

Acquiring a Service Ticket for the Computer

Network Authentication

Smart Card Authentication

Multiple Domain Authentication

Criteria for Delegation

The following computers must be running Microsoft Windows 2000 in a Windows 2000 domain:

Computers hosting the client process Computers running the service process Computers running processes for any back-end

services The client's user account must be enabled for

delegation. The service's account must be enabled for

delegation.

Delegation and Kerberos Authentication

Making the Decision: Designing Kerberos Authentication

Microsoft Windows 2000 DCs must be available on the network.

DNS services must be available to find Windows 2000 DCs.

The authenticating DC must contact a global catalog server.

Global catalog server SRV resource records are stored in the _msdcs.forestrootdomain zone.

Only Windows 2000 and UNIX clients use Kerberos authentication.

Smart card logon requires Kerberos authentication. Kerberos settings are part of the domain account

policy.

Applying the Decision: Designing Kerberos Authentication at Market Florist

Each domain has sufficient DCs at each of the four sites.

The San Francisco site does not have a dedicated DNS server.

The DNS servers in Winnipeg and Monterrey do not have a secondary zone for the _msdcs.marketflorit.tld domain.

The Winnipeg and Monterrey sites do not have a local global catalog server.

NTLM Authentication

Only Windows 2000 clients and UNIX clients can use Kerberos authentication.

Windows 2000 continues to support NTLM. NTLM can also be used to authenticate logons

to Windows 2000 computers that are not participating in a domain.

Security weaknesses were found with the NTLM protocol.

NTLM version 2 was developed for Microsoft Windows NT 4.0 Service Pack 4 (SP4).

Additional NTLMv2 Security

Unique session keys per connection Session keys protected with a key exchange Unique keys generated for the encryption and

integrity of session data

NTLMv2 Authentication

Making the Decision: Implementing NTLMv2 Authentication When Windows 2000 is authenticating with

Local SAM database of a standalone Windows 2000–based computer

Microsoft Windows NT 4.0 computer with SP4 or later installed

When Windows NT 4.0 is authenticating with Windows 2000 and Windows NT 4.0 servers and the client

has SP4 or later applied Windows 2000 and Windows NT 4.0 servers and the client

has the Directory Services Client installed When Microsoft Windows 95 or Microsoft Windows 98 is

authenticating with Windows 2000 and Windows NT 4.0 servers using the

Directory Services Client

Applying the Decision: Implementing NTLMv2 Authentication at Market Florist

Microsoft Windows 95 and Microsoft NT 4.0 Workstation cannot use Kerberos authentication.

The Directory Services Client must be deployed to Windows 95 clients.

Windows NT 4.0 Workstation will not require the Directory Services Client.

Authenticating Down-Level Clients

Analyzing standard authentication Analyzing the Directory Services Client

Analyzing Standard Authentication:Windows NT 4.0 Clients

Windows NT 4.0 clients without service packs use NTLM.

Information exchanged between a DC and an authenticating client is not secure with only NTLM protection.

NTLMv2, introduced with SP4, provides added security.

Analyzing Standard Authentication:Windows 95 and Windows 98 Clients

These clients use LAN Manager (LM) authentication protocol.

LM authentication is the weakest of the authentication protocols.

LM authentication is not case sensitive. The LM password protection scheme is easily

cracked. Sensitive account passwords can be decrypted

if they are maintained in LM format within Active Directory.

Analyzing Standard Authentication:Microsoft DSClient

Microsoft Directory Services Client (DSClient) was designed to counteract the weaknesses in LM authentication.

Allows Windows NT 4.0, Windows 95, and Windows 98 clients to use NTLMv2 for authentication in the Windows 2000 network.

DSClient Functionality

NTLMv2 authentication protocol Site awareness Search for objects in Active Directory Reduced dependency on the PDC ADSI Distributed File System (DFS) fault tolerance

client Active Directory Windows Address Book (WAB)

property pages

Features DSClient Does Not Provide

Kerberos support Group Policy/Intellimirror support IPSec/L2TP support SPN/Mutual authentication Dynamic DNS support User principal name (UPN) authentication

Controlling Authentication Level with Group Policy

The LMCompatibilityLevel setting can be deployed using Group Policy.

Set LMCompatibilityLevel at the container where the Windows 2000 computer accounts reside.

For DCs, set LMCompatibilityLevel at the Domain Controllers OU.

Making the Decision: Authenticating Down-Level Clients

Plan for distribution of the DSClient software. Ensure that all Windows NT 4.0 clients have

the latest service pack installed. Identify any registry updates to be performed

for client computers after DSClient installation. After DSClient installation, set the

LMCompatibilityLevel at the servers to require NTLMv2 authentication.

Replace or upgrade all older client computers from the network if they cannot support NTLMv2 authentication.

Applying the Decision: Authenticating Down-Level Clients at Market Florist

Distribute the DSClient software to all down-level client computers.

Ensure that all necessary registry settings are deployed to Windows NT 4.0 and Windows 95 clients.

After the DSClient software is fully deployed, configure Group Policy to allow only NTLMv2 authentication.

Configure DNS services locally at each site.

Planning Server Placement for Authentication

Planning DNS server placement Planning DC placement Planning global catalog server placement Planning PDC emulator placement

Information Stored Within the_msdcs.forestrootdomain Zone

All global catalog servers in the forest The GUID representation of each domain The GUID representation of each DC

Making the Decision: DNS Server Placement

A DNS server should be located at each remote site to ensure DNS lookup capabilities to all clients if the WAN link is down to a central site.

Each domain must have at least two DNS servers to provide fault tolerance in the event of server or WAN link failure.

The DNS service at each site must contain zone information for all domains that must be accessed at that site.

All global catalog resource records are stored in the forest root domain.

Applying the Decision: DNS Server Placement at Market Florist

Planning DC Placement

DCs host KDC service for Windows 2000. Client will attempt to authenticate with a local

DC. If a local DC is unavailable, the site link costs

will be checked to determine what the closest site to the current site is, based on the lowest cost.

Making the Decision: DC Placement

Place at least two DCs at each remote site to ensure that clients authenticate locally.

If there are no client computers or users at a remote site for a specific domain, there is no reason to deploy a DC for that domain at the remote site.

If the WAN link goes down, clients are restricted to logging on to the network with cache credentials.

Applying the Decision: DC Placement at Market Florist

Each of the four sites for Market Florist has at least two DCs to ensure that authentication for the local domain will not occur over the WAN.

Install the DSClient software to all Windows 95 and Windows NT 4.0 clients.

Planning Global Catalog Server Placement

Global catalog servers are contacted during authentication when

The domain is in native mode A user logs on at a Windows 2000–based computer

using a UPN

Making the Decision: Global Catalog Server Placement

Place at least one global catalog server at each site.

Ensure that the _msdcs.forestrootdomain DNS domain is available at all remote sites on a local DNS server.

Designate global catalog servers, even in a single domain environment.

Applying the Decision: Global Catalog Server Placement at Market Florist

The current design does not include a local global catalog server at the Winnipeg and Monterrey sites.

One DC at each site should be configured as a global catalog server to ensure that global catalog access is not taking place over the WAN.

If the WAN link becomes unavailable, all Windows 2000 clients are authenticated using cached credentials.

The local DNS servers at each site should have a replica of the _msdcs.marketflorist.tld domain to ensure that a local global catalog server can be found by authenticating clients.

Planning PDC Emulator Placement

Down-level clients Connect to the PDC emulator for password changes Connect to the PDC emulator for system policy

application by default Continue to depend on the PDC emulator for domain

browse master functions, password changes, and system policy application until the DSClient software is installed

Making the Decision: PDC Emulator Considerations

If possible, reduce dependency on the PDC emulator by installing DSClient software.

Configure system policy to load balance to ensure the system policy is applied from the authenticating DC, not the PDC emulator.

Upgrade all Windows NT 4.0 BDCs to Windows 2000 DCs as soon as possible to use multimaster replication.

If the DSClient is not deployed, ensure the PDC emulator is on a central portion of the network that is easily accessible from all remote sites.

Applying the Decision: PDC Emulator Placement at Market Florist

The network must ensure the rapid deployment of the DSClient software to the client computers.

The San Francisco site will benefit the most from the quick deployment of the DSClient software.

The PDC emulator will be located on the local network in Monterrey and Winnipeg location, so this will not be much of an issue.

Chapter Summary

Designing Authentication in a Microsoft Windows 2000 Network

Designing Kerberos Authentication NTLM Authentication Authenticating Down-Level Clients Planning Server Placement for Authentication

Planning server placement Planning domain controller placement Planning global catalog server placement Planning PDC emulator placement