designing authentication for a microsoft windows 2000 network designing authentication in a...
TRANSCRIPT
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