Chapter 3, Designing Authentication for a Microsoft Windows 2000 Network

|1| Chapter Overview

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

Chapter 3, Lesson 1

|2| Designing Authentication in a Microsoft Windows 2000 Network

1. Determining Business and Technical Requirements

A. Introduction

1. Authentication allows network administrators to

a. Determine who is accessing the network

b. Design restrictions so that each authenticated user can only access desired areas of the network

2. Good authentication design allows trusted users access to the network at all times.

|3| B. Business requirements

1. Reduce total cost of company’s ownership

a. Use Group Policy to enforce standardized security configurations.

b. In Microsoft Windows NT 4.0 networks, the registry had to be edited manually to apply many advanced security settings.

c. With Group Policy, Windows 2000 can ensure that common registry modifications are enforced centrally using Active Directory.

2. Identify security risks in the network

a. Many down-level clients can’t use more secure methods of authentication.

b. DSClient

(1) Allows Windows 95, Windows 98, and Windows NT clients to use the NTLMv2 authentication protocol

(2) Provides higher authentication security and reduces the risk of password cracking

|4| C. Technical requirements

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

a. Deploy DNS servers, DCs, and global catalog servers at each remote site.

(1) Ensures that each site has the necessary hardware to provide local authentication

b. Only Windows 2000 clients are site-aware by default.

c. DSClient software installed on down-level clients makes them site-aware.

2. Network authentication must occur in a timely manner.

a. Authentication performance suffers over WAN links.

b. Site-aware clients find network services on the local segment of the network.

c. To ensure all clients are site-aware, deploy

(1) DSClient software to all down-level clients

(2) Active Directory sites correctly

3. DCs must not be overloaded with authentication requests.

a. Microsoft Active Directory Sizer (ADSizer) tool determines

(1) The ideal number of DCs required

(2) The processor and memory requirements for each DC

Chapter 3, Lesson 2

|5| Designing Kerberos Authentication

|6| 1. Advantages of Kerberos Authentication

A. Mutual authentication

1. User and server are authenticated.

2. Prevents identity spoofing of both the user and the server

3. Ensures that only desired communications take place

B. Single sign-on

1. Authenticated Kerberos users do not have to provide any other credentials when accessing any resources in the forest.

C. Ticket caching

1. The user caches the service ticket (ST) in his personal ticket cache.

2. Reduces the number of times that a user must contact DCs for authentication

3. Users can present their existing STs any time they are required to authenticate with the server.

4. When the ticket expires, the user is required to contact a DC to acquire another ST.

Note The ticket cache can be viewed at any time by using Microsoft Windows 2000 Server Resource Kit utilities. You can use the Klist.exe utility and the Kerbtray.exe utility.

D. Delegation

1. Services can impersonate connecting users when the service connects to services located on other servers.

2. Allows an application server to query a database under the security context of the connected user

E. Standards-based protocol

1. Industry standard authentication protocol

2. Compliant with RFC 1510 and RFC 1964

F. Interoperability

1. Provides interoperable authentication between Windows 2000 domains and UNIX Kerberos realms

2. Eases access to resources using a secure authentication protocol

|7| 2. Understanding the Kerberos Message Exchanges

A. Authentication service exchange

1. Used by the key distribution center (KDC) to provide a user with

a. A logon session key

b. A TGT for future ST requests

B. Ticket granting service exchange

1. Used by the KDC to distribute service session keys and STs

C. Client/server authentication exchange

1. Used when users present an ST to a target service on the network.

Note In the case of a failed authentication, all three message exchanges have the response sent from the KDC or the target server to the client replaced with a Kerberos Error message (KRB_ERROR) that details why the authentication attempt failed.

Note The highlighted section titled “The Importance of Time in Kerberos Transactions,” You need to know that Windows 2000 uses the Windows Time Synchronization Service (W32time.exe) that is based on SNTP to ensure that all computers in a forest have synchronized clocks. You can use the following process to ensure time synchronization:

1. The PDC emulator in the forest root domain is considered the authoritative time source for the entire forest and should synchronize its clock to an Internet Network Time Protocol (NTP) time source, using the following command:
net time /setsntp:<NTP host name>

2. Within each domain, all DCs synchronize their clocks with the PDC emulator of their domain.

3. For every other domain in the forest, the PDC emulator in that domain contacts the PDC emulator in the parent domain for clock synchronization.

All client computers in the domain synchronize their clocks with the authenticating DC.

3. Analyzing Kerberos Authentication

|8| A. Initial authentication with the network

1. Authentication Service Exchange is used when a user initially logs on to the network.

2. This exchange provides the user with a logon session key and a TGT that will be used to acquire STs during the session.

3. Information contained within the KRB_AS_REP response is encrypted with the user’s long-term key so that only the user can decrypt the session key and TGT within the response message.

4. Each user shares a long-term key with the KDC.

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

|9| B. Kerberos authentication exchange

1. The user presses Ctrl+Alt+Del.

2. The client computer queries the DNS server to find a _Kerberos SRV resource record based on the client’s domain and site.

3. The user sends a KRB_AS_REQ message to the DC indicated in the returned SRV resource record.

4. The authentication service at the KDC authenticates the user, generates a TGT for the user, and then sends back the TGT to the user.

5. If the user is using a Windows 2000–based computer, he must now acquire an ST for that computer.

|10| C. Acquiring an ST for the computer

1. The user sends a KRB_TGS_REQ message to the KDC to acquire an ST for the computer he is using.

a. The KRB_TGS_REQ contains an authenticator and the TGT that was issued to the client.

2. The Ticket Granting Service of the KDC checks the TGT and the authenticator.

a. If both are valid, then the Ticket Granting Service generates an ST and sends it back to the client, using a KRB_TGS_REP response.

3. At the client computer, the ST is presented to the Local Security Authority, which will create an access token for the user.

a. From then on, any process acting on behalf of the user can access the local machine’s resources.

|11| D. Network authentication

1. The user sends a KRB_TGS_REQ message to the KDC to acquire an ST for the target computer.

a. The KRB_TGS_REQ includes the TGT and an authenticator.

2. The TGS of the KDC checks the authenticator and the TGT, generates a new ST, and sends it back to the client, using a KRB_TGS_REP response.

a. The ST will be encrypted by use of the master key between the KDC and the target service.

3. The client sends the ST and an authenticator to the target server, using a KRB_AP_REQ message.

4. The target server verifies the ticket with the authenticator, decrypts the session key using the long-term key that is shared with the KDC, and sends back an authenticator to the client in a KRB_AP_REQ message.

a. This authenticator provides mutual authentication of the client and server.

|12| E. Smart card authentication

1. The user introduces a smart card and authenticates the card, using the PIN code.

a. The smart card contains the user’s

(1) Public key credentials

(2) Private/public key pair

(3) Certificate

2. A modified Kerberos Authentication Service Request (PA_PK_AS_REQ) message is sent to the KDC.

a. This request contains the user principal name (UPN), time stamp, and a copy of the user’s certificate.

b. The UPN and time stamp are signed by the user’s private key.

3. The KDC validates the request by verifying the user’s certificate and the digital signature with the certification authority (CA) that issued the certificate.

4. The KDC then queries Active Directory to determine the mapping between the certificate included in the PA_PK_AS_REQ message and a Windows 2000 security identifier (SID).

a. When the mapping is determined, the KDC issues a TGT for the corresponding SID.

5. The KDC sends back the TGT to the user in a modified Kerberos Authentication Service Response (PA_PK_AS_REP).

a. Within the response, the session key is encrypted with the user’s public key.

b. This ensures that only the correct user can decrypt the session key.

6. The user retrieves the session key by decrypting the session key with the private key located on the smart card.

|13| F. Multiple-domain authentication

1. The user sends a KRB_TGS_REQ message to the KDC in his domain to acquire an ST for the srv1.east.company.com computer.

a. The KDC that receives the request looks at the trust relationships that exist for the domain.

b. The KDC issues a TGT to the company.com domain in the KRB_TGS_REP packet.

c. The TGT is encrypted by use of the interdomain key between the west.company.com domain and the company.com domain.

d. Shortcut trusts can be established to minimize this process transaction length.

2. The user sends a KRB_TGS_REQ message to a KDC in the company.com domain to acquire an ST for the srv1.east.company.com computer.

a. The KDC that receives the request looks at the trust relationships that exist for the domain.

b. The KDC in the company.com domain issues a TGT to the east.company.com domain in the KRB_TGS_REP packet.

c. The TGT is encrypted by use of the interdomain key between the company.com domain and the east.company.com domains.

3. The user sends a KRB_TGS_REQ message to a KDC in the east.company.com domain to acquire an ST for the srv1.east.company.com computer.

a. The KDC that receives the request verifies the TGT and the authenticator provided in the KRB_TGS_REQ.

b. If valid, the KDC will issue a KRB_TGS_REP that contains an ST to connect to the srv1.east.company.com computer.

c. The ST is encrypted by use of the long-term key shared by the KDC and the srv1.east.company.com computer.

4. The user sends a KRB_AP_REQ containing the ST to the srv1.east.company.com computer.

a. The srv1.east.company.com validates the ST and, if it is valid, responds with a KRB_AP_REP message.

b. b. The user can now access the resource.

|14| G. Criteria for delegation

1. Introduction

a. Multitiered client/server applications (commonly referred to as n-tiered applications) can be deployed in client/server environments.

b. The first server the user connects to must often impersonate that user to ensure that the entire process runs in the security context of the connecting user.

c. When the account is designated as trusted for delegation

(1) Enables the forwardable flag on the ST

(2) Allows services to request STs on behalf of the client and run processes in the security context of the client

2. Delegation can only take place when the following criteria are met:

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

(1) Computers hosting the client process

(2) Computers running the service process

(3) Computers running processes for any back-end services

b. The client’s user account must be enabled for delegation.

Note You can enable a user account for delegation by editing the properties of the user account in Active Directory Users And Computers. In the Account tab, under Account options, enable the Account Is Trusted For Delegation check box and ensure that the Account Is Sensitive And Cannot Be Delegated option is cleared.

c. The service’s account must be enabled for delegation.

Note If the service account is running under the local system account, then the computer account itself must be trusted for delegation. Open the properties of the computer account in Active Directory Users And Computers. In the General tab, enable the Trust Computer For Delegation check box.

|15| 3. Kerberos authentication when delegation takes place

a. The client sends a KRB_TGS_REQ message to the KDC requesting an ST for Server1.

b. The KDC sends the ST in a KRB_TGS_REP message back to the client.

c. The client sends the ST to Server1 in a KRB_AP_REQ message.

d. Server1 responds to the authentication request with a KRB_AP_REP message.

e. Server1 sends a KRB_TGS_REQ message, impersonating the client, to the KDC for an ST to access Server2 in the security context of the client.

f. The KDC sends a KRB_TGS_REP message containing the ST that allows the client to access Server2.

g. Server1 sends the ST to Server2 in a KRB_AP_REQ message.

h. Server2 responds to the authentication request with a KRB_AP_REP message validating the authentication.

i. Server1 now has access to services on Server2 at the security level of the original client.

|16| 4. Making the Decision: Designing Kerberos Authentication

A. Kerberos authentication relies on Windows 2000 DCs being available on the network.

1. Each site defined in Active Directory should have at least one DC available to ensure authentication.

B. DNS services must be available to find Windows 2000 DCs.

1. A Windows 2000 client computer queries DNS for a _Kerberos SRV resource record when attempting to connect to a KDC.

2. If DNS services are unavailable, the client cannot find a KDC for authentication.

C. The authenticating DC must contact a global catalog server to enumerate universal group membership.

1. The Windows 2000 domain must be in native mode with multiple domains existing in the forest.

2. A global catalog server should be located at each remote site to ensure that a global catalog server is available.

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

1. The variable forestrootdomain represents the name of the domain in question.

2. This zone should be delegated to DNS servers at remote sites to ensure that global catalog servers can be found by authenticating DCs.

E. Only Windows 2000 clients and UNIX clients can authenticate using Kerberos authentication.

1. Even with the DSClient loaded, Windows 95, Windows 98, and Windows NT clients cannot authenticate using Kerberos.

F. Smart card logon requires that Kerberos be used for authentication.

1. If Kerberos services are unavailable, then the smart card logon attempt will fail.

G. Kerberos settings are part of the domain account policy.

1. The Kerberos settings include the option to enforce logon restrictions.

2. This setting should always be applied to ensure that disabled user accounts can no longer acquire STs once the account is disabled.

3. These Kerberos settings can be edited in the Default Domain policy in Windows Settings\Security Settings\Account Policies\Kerberos Policy.

|17| 5. Applying the Decision: Designing Kerberos Authentication at Market Florist

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

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

1. If the WAN link to Seattle is unavailable, the clients cannot access a DNS server to find SRV resource records for Kerberos authentication.

2. Result: Cached credentials may be used for authentication.

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

1. If the WAN link is down to either of these sites, the authenticating DCs will be unable to find a global catalog server for universal group enumeration.

2. This zone should be configured as a secondary zone on the DNS servers in Winnipeg and Monterrey.

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

1. At least one DC at each site should be configured as a global catalog server to ensure that all global catalog access is not over the WAN links as currently configured.

Chapter 3, Lesson 3

|18| NTLM Authentication

1. Introduction

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

B. Windows 2000 continues to support NTLM.

C. NTLM is also used to authenticate logons to Windows 2000 computers that are not participating in a domain.

D. Security weaknesses were found with the NTLM protocol.

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

|19| 2. Additional NTLMv2 Security

A. Unique session keys per connection

1. Generated each time that a new connection is established

2. A captured session key has no useful purpose.

B. The session keys are protected with a key exchange.

1. The session key cannot be intercepted and used unless the key pair used to protect the session key is obtained.

C. Unique keys are generated for the encryption and integrity of session data.

1. The key used for the encryption of data from the client to the server is different from the key used for the encryption of data from the server to the client.

|20| 3. NTLMv2 Authentication

A. The NTLM challenge response is sent from the client computer to the server being connected to.

B. The application server uses the local security authority (LSA) to log on to the domain using the Netlogon service.

C. The Netlogon service queries Active Directory using the MSV1_0 subauthentication filter to validate the user.

D. If validated, the Netlogon service returns the user and group SIDs from the authenticating DC back to the server.

E. NTLMv2 introduces a secure channel to protect the authentication process.

|21| 4. Making the Decision: Implementing NTLMv2 Authentication

A. Introduction

1. Kerberos authentication is available to Windows 2000 client computers only.

2. Network design must ensure that the next strongest form of authentication is available to non–Windows 2000 client computers.

B. NTLMv2 authentication is used in the following circumstances:

1. Windows 2000 authenticating with

a. Local Security Accounts Manager (SAM) database of a standalone Windows 2000–based computer

b. Windows NT 4.0 computer with SP4 or later installed

2. Windows NT 4.0 authenticating with

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

b. Windows 2000 and Windows NT 4.0 servers when the client has the DSClient installed

3. Windows 95/Windows 98 authenticating with

a. Windows 2000 and Windows NT 4.0 servers using the DSClient

|22| 5. Applying the Decision: Implementing NTLMv2 Authentication at Market Florist

A. Windows 95 and Windows NT 4.0 Workstation clients cannot use Kerberos authentication.

B. The DSClient must be deployed to the Windows 95 clients.

C. Windows NT 4.0 Workstation does not require the DSClient.

Chapter 3, Lesson 4

|23| Authenticating Down-Level Clients

Note Microsoft uses the hierarchical concept of up-level (Active Directory and Kerberos) and down-level (directory database and NTLM). Remember that the default setup configuration is the deployment of Windows 2000 servers and legacy NT 4.0 PDCs in an enterprise structure (a mixed mode organization).

1. Analyzing Standard Authentication

|24| A. Windows NT 4.0 clients

1. Windows NT 4.0 clients without service packs use NTLM.

2. Information that is exchanged between a DC and an authenticating client is not secure if they are only protected using NTLM.

3. NTLMv2 was introduced with SP4.

|25| B. Windows 95/Windows 98 clients

1. Use LAN Manager (LM) authentication protocol

2. LM authentication is the weakest of the authentication protocols.

3. LM authentication is not case sensitive.

4. The LM password protection scheme is easily cracked.

5. Sensitive account passwords can be decrypted if they are maintained in LM format within Active Directory.

|26| C. DSClient

1. DSClient was designed to counteract the weaknesses in LM authentication.

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

2. Analyzing the DSClient

|27| A. DSClient functionality

1. NTLMv2 authentication protocol

a. Windows 95, Windows 98, and Windows NT 4.0 clients use NTLMv2 for authentication when authenticating with Active Directory.

2. Site awareness

a. The DSClient software allows the client to query DNS to find a DC in the same site.

3. Search for objects in Active Directory

a. The DSClient software allows clients to search Active Directory for printers and users from the Start|Search menu.

4. Reduced dependency on the PDC

a. Allows Windows 95 and Windows 98 clients to connect to any DC in the domain for password changes

5. Active Directory Services Interface (ADSI)

a. Provides a common programming API for Active Directory

6. Distributed File System (DFS) fault tolerance client

a. Allows clients to access and find Windows 2000 DFS file shares in Active Directory

7. Active Directory Windows Address Book (WAB) property pages

a. Allows users to changes attributes of their user object using the Start|Search|For People menu option

b. Subject to the security settings on their user object

|28| B. Features the DSClient does not provide

1. Kerberos support

a. Does not provide Kerberos support to down-level clients

b. Must use NTLMv2 to strengthen authentication security

2. Group Policy/Intellimirror support

a. Does not participate in Group Policy or Intellimirror

b. To deliver similar functionality, System Policy must be maintained in the Active Directory environment.

3. IPSec/L2TP support

a. Down-level clients only support PPTP for VPN connections

b. No support for L2TP or IPSec connections

4. Server Principal Name (SPN)/mutual authentication

a. Does not provide SPN or mutual authentication to down-level clients

5. Dynamic DNS support

a. Does not allow down-level clients to update their own DNS resource records using dynamic update

b. For down-level clients, the Dynamic Host Configuration Protocol (DHCP) server must be configured to update the DNS resource records on behalf of the client computers.

6. User principal name (UPN) authentication

a. Does not allow a user to authenticate using his UPN (user@domain.com)

b. Only available in Windows 2000 clients

C. Restricting protocols that can be used to authenticate with a Windows 2000 computer

1. Adjust registry value HKLM\System\CurrentControlSet\control \LSA\LMCompatibilityLevel and set one of the six values for the REG-DWORD value.

2. REG-DWORD value

a. 0: Send LM & NTLM responses

b. 1: Send LM & NTLM–use NTLMv2 session security if negotiated

c. 2: Send NTLM response only

d. 3: Send NTLMv2 response only

e. 4: Send NTLMv2 response only\refuse LM

f. 5: Send NTLMv2 response only\refuse LM

|29| D. Controlling authentication level with Group Policy

1. The LMCompatibilityLevel setting can be deployed using Group Policy.

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

3. For DCs, apply this at the Domain Controllers OU.

4. Establish the following Group Policy setting: Group Policy Container\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\LAN Manager Authentication Level

|30| 3. Making the Decision: Authenticating Down-Level Clients

A. Plan for distribution of the DSClient software.

1. Down-level clients should have the DSClient software installed to allow the use of NTLMv2 for authentication.

2. The DSClient software makes clients site aware and less PDC dependent.

B. Ensure that all Windows NT 4.0 clients have the latest service pack installed.

1. NTLMv2 functionality was introduced in Windows NT 4.0 SP4.

C. Identify any registry updates to be performed for client computers after DSClient installation.

D. After DSClient installation, set the LMCompatibilityLevel at the servers to require NTLMv2 authentication.

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

|31| 4. Applying the Decision: Authenticating Down-Level Clients at Market Florist

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

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

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

D. Configure DNS services locally at each site.

Chapter 3, Lesson 5

|32| Planning Server Placement for Authentication

1. Introduction

A. DCs perform Windows 2000 authentication.

B. Ensure that Windows 2000 DCs are readily available to clients.

C. Consider only the servers that play a part in the authentication process.

1. DNS servers

2. DCs

3. Global catalog servers

4. The PDC emulator

|33| 2. Planning DNS Server Placement

A. Introduction

1. DNS servers act as the locator service.

2. Must deploy a DNS server that contains zone information for all domains located at each remote site

3. Must ensure that the _msdcs.forestrootdomain zone is available at all remote sites

B. Information stored within the _msdcs.forestrootdomain zone

1. All global catalog servers in the forest

a. DNS does not store the global catalog server SRV resource records based on domains.

b. Site location is more relevant for global catalog servers.

2. The Globally Unique Identifier (GUID) representation of each domain

a. In future versions of Windows 2000, it will be possible to rename domains.

b. If the domain name is renamed, then the GUID host record can be referenced to find the renamed domain.

3. The GUID representation of each DC

a. DCs find replication partners based on the DC’s GUID, not the DC’s DNS fully qualified domain name.

b. If the DNS service cannot be contacted, then the client computers will be unable to find the nearest KDC for authentication.

c. Authentication will then fall back to NetBIOS methods and use NTLMv2 for authentication.

Note If there are clients on the network that are not Windows 2000–based, or if there are down-level clients with the DSClient software installed, it would be best to deploy WINS for NetBIOS name resolution. Make sure that a locally accessible WINS server is located at each remote site and that WINS replication is correctly configured so that clients can authenticate with remote DCs if necessary.

|34| C. Making the decision: DNS server placement

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

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

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

a. If clients can authenticate with two different domains at a site, DNS services should have replicas of the zones for those two domains hosted at a local DNS server.

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

a. Each DNS server in a forest should have a replica of the _msdcs.forestrootdomain zone to ensure that the global catalog (_gc) resource records can be resolved by the local DNS server.

|35| D. Applying the decision: DNS server placement at Market Florist

1. The DNS servers at the Seattle site should configure the _msdcs.marketflorist.tld domains as a separate Active Directory–integrated zone.

2. A DC at the San Francisco site should be configured as a DNS server.

a. For fault tolerance, the second DC can also be configured as a DNS server.

3. A second DC in the ca.marketflorist.tld domain should be configured as a DNS server to provide fault tolerance of the ca.marketflorist.tld domain.

4. The two DNS servers at the Winnipeg site should be configured as secondaries of the _msdcs.marketflorist.ca domain.

5. The second DC in the mx.marketflorist.tld domain should be configured as a DNS server to provide fault tolerance of the mx.marketflorist.tld domain.

6. The two DNS servers at the Monterrey site should be configured as secondaries of the _msdcs.marketflorist.ca domain.

7. All Windows 95, Windows NT, and Windows 2000 clients should be configured to use two DNS servers at their site as their primary and secondary DNS services.

a. Can be configured locally at each client computer or by using DHCP to assign the correct DNS IP addresses based on IP address scope

|36| 3. Planning DC Placement

A. Introduction

1. DCs host KDC service for Windows 2000.

2. The client attempts to authenticate with a local DC.

3. If a local DC is unavailable, the site link costs are checked to determine what the closest site to the current site is, based on the lowest cost.

|37| B. Making the decision: DC placement

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

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

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

a. This could result in the user accessing the network with group memberships that have changed since the last successful logon attempt.

|38| C. Applying the decision: DC placement at Market Florist

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

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

a. Ensures all password changes can be made to the local DC, rather than to the PDC emulator for the domain

|39| 4. Planning Global Catalog Server Placement

A. Global catalog servers are contacted during the following authentication scenarios:

1. When the domain is in native mode

a. The authenticating DC contacts a global catalog server to determine if the authenticating user is a member of any universal groups.

b. If the global catalog server cannot be contacted, the user must be authenticated with cached credentials.

c. Explicit deny permission assignments may exist for universal groups of which the user is a member.

2. When a user logs on at a Windows 2000–based computer using a UPN

a. The global catalog is referenced to determine the account that is associated with the UPN.

b. If a global catalog server is unavailable, the user will fail authentication.

|40| B. Making the decision: global catalog server placement

1. Place at least one global catalog server at each site.

a. There is no additional WAN replication cost if additional global catalog servers are placed at the remote site.

b. One global catalog server will be nominated as the bridgehead server for global catalog replication.

c. There will not be extra intersite replication related to the global catalog server.

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

a. This ensures that the SRV resource records associated with global catalog servers are available when the WAN link is not available.

b. The _msdcs.forestrootdomain DNS domain can be implemented as either an Active Directory–integrated zone or as a secondary DNS zone.

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

a. Any Lightweight Directory Access Protocol (LDAP) queries against the entire forest are sent to a global catalog server listening on TCP port 3268.

b. Only available on a DC configured as a global catalog server

|41| C. Applying the decision: global catalog server placement at Market Florist

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

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

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

4. 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| 5. Planning PDC Emulator Placement

A. Down-level clients

1. Connect to the PDC emulator for password changes

2. Connect to the PDC emulator for system policy application by default

3. 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| B. Making the decision: PDC emulator considerations

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

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

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

4. 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| C. Applying the decision: PDC emulator placement at Market Florist

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

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

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