Designing Authentication for a Microsoft Windows 2000 Network

1
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

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

3
Business Requirements

• Reduce total cost of companys ownership
• Identify security risks in the network

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

5
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

6
Advantages of Kerberos Authentication

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

7
Understanding the Kerberos Message Exchanges

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

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

9
The Kerberos Authentication Exchange
10
Acquiring a Service Ticket for the Computer
11
Network Authentication
12
Smart Card Authentication
13
Multiple Domain Authentication
14
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.

15
Delegation and Kerberos Authentication
16
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.

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

18
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).

19
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

20
NTLMv2 Authentication
21
Making the Decision Implementing NTLMv2
Authentication

• When Windows 2000 is authenticating with
• Local SAM database of a standalone Windows
  2000based 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

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

23
Authenticating Down-Level Clients

• Analyzing standard authentication
• Analyzing the Directory Services Client

24
Analyzing Standard AuthenticationWindows 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.

25
Analyzing Standard AuthenticationWindows 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.

26
Analyzing Standard AuthenticationMicrosoft
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.

27
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

28
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

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

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

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

32
Planning Server Placement for Authentication

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

33
Information Stored Within the_msdcs.forestrootdom
ain Zone

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

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

35
Applying the Decision DNS Server Placement at
Market Florist
36
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.

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

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

39
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 2000based computer
  using a UPN

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

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

42
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

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

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

45
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