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 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