CHAPTER 3
DESIGNING
AUTHENTICATION FOR A
MICROSOFT WINDOWS
2000 NETWORK
Chapter Scenario: Market Florist
Lesson 1: Designing
Authentication in a Microsoft Windows 2000 Network
During the design of the authentication system for your Windows 2000 Network, you should
ensure the business requirements include these areas:
Reduce Total Cost of Ownership. You can accomplish this by enforcing Group Policies to ensure
security. They will be applied by Active Directory in the Windows 2000 environment, but if it was
Windows NT you would have had to edit the registry.
Identify security risks in the network. Windows 95 & 98 use LAN Manager (LM) authentication.
But with the installation of Directory Services Client in the Windows 2000 network, Windows 95
and 98 clients use the NTLMv2 authentication protocol, which gives more security.
Network authentication must be available even if WAN links are not. By deploying DNS, DCs
and Global Catalog servers at each of the remote sites, you ensure that each site has the services
needed to provide local authentication. Network authentication must occur quickly. If over a
WAN link it will be slower and security will be compromised. DCs must not be overloaded
with authentication requests. Microsoft provides a tool known as the Active Directory Sizer
(ADSizer), which helps you plan the optimal number of DCs that you require for your network.
Lesson Summary:
objectives defined by your organization.
======================================================================
winsec3.html PAGE 2 2002/04/14
Lesson 2:
Designing Kerberos Authentication
Windows 2000 is designed to use Kerberos V5 as the default
authentication protocol.
Kerberos Components:
Key distribution center (KDC). A network service that supports both ticket granting TGTs
and service tickets to users and computers on the network. The KDC contains two services:
the Authentication Service and the Ticket Granting Service. The Authentication Service
provides the initial authentication of the users on the network and provides the user with a TGT.
Whenever users request access to a network service, they supply their TGT to the Ticket
Granting Service. Then they are granted a service ticket for authentication with the target
network service.
TGT. Provided to users the first time they authenticate with the KDC. The TGT is a service
ticket for the KDC. Windows 2000 by default always verifies that the user account is still
active every time a TGT is presented to the KDC.
Service Ticket. The user provides a service ticket whenever he connects to a service on the
network. This ticket contains the target server’s copy of a session key and also contains
information about the users who’s connecting. This information is used to desired network
service by comparing the authentication information.
Referral ticket. Issued anytime a user attempts to connect to a target server that’s a member
of a different domain. The referral ticket is actually a TGT to the domain where the resource is
located that’s encrypted using the interdomain key between the initial domain and the target
domain.
These four components allow Kerberos authentication to take place between Windows 2000
clients and Windows 2000 DCs.
Designing Kerberos Authentication
Kerberos provides the following advantages over the NTLM protocol:
Mutual authentication. For all Kerberos transactions, both the user and the server are
authenticated.
Single sign-on. Within a forest, a user who authenticates to the network using Kerberos V5
authentication won’t have to provide any other credentials when accessing any resources in the
forest.
Ticket Caching. After acquiring a service ticket from the KDC, the user then caches the service
ticket in the client’s personal ticket cache.
======================================================================
winsec3.html PAGE 3 2002/04/14
Delegation. Kerberos lets services impersonate connecting users when the service connects to
services located on other servers.
Standard-based protocol. Kerberos is an industry standard authentication protocol. The
Windows 2000 implementation of Kerberos V5 is compliant with Request for Comment
1510 and 1964.
Interoperability. You can use Kerberos authentication to provide interoperable authentication
between Windows 2000 domains and Kerberos realms in a UNIX environment.
Understanding the Kerberos Message Exchanges
There are three different message exchanges:
Authentication Service Exchange. Used by the KDC to provide a user with a logon session key
and a TGT for future service ticket requests.
Ticket Granting Service Exchange. Used by the KDC to distribute service session keys and service
tickets. The service ticket that’s returned is encrypted using the master key shared by the KDC
and the target server so that only the target server can decrypt the service ticket.
Client/Server Authentication Exchange. A user uses this message exchange when presenting a
service ticket to a target service on the network.
NOTE: If the case of a failed authentication, all three message exchanges would replace the
response sent from the KDC or the target server to the client with a Kerberos Error message
(KRB_ERROR) that explains why the authentication attempt failed.
Analyzing Kerberos Authentication
Kerberos authentication is used in a Windows 2000 network in many circumstances.
Initial Authentication with the Network
The authentication Service Exchange is used when a user initially logs on to the network. This
exchange provides the user with a logon session key and a TGT that will be used to acquire
service tickets during the session. Each user shares a long-term key with the KDC. The long-
term key is derived from the account’s password.
======================================================================
winsec3.html PAGE 4 2002/04/14
The Importance of Time in Kerberos Transactions
The Windows 2000 the current time of the client is included in any client request sent to a target
server or to the KDC. The time is compared with the target server’s current time. By default,
if the difference between the two times is greater than 5 minutes, the connection attempt is
considered invalid.
There is a time synchronization service (W32time.exe) that’s based on the Simple Network
Time Protocol (SNTP).
The following
processes occur in order to ensure time synchronization:
The PDC emulator in the forest root domain is considered the authoritative time source for the
entire forest. Net^time/setsntp:<NTP host time
For every other domain in the forest, the PDC emulator in that domain contacts the PDC
emulator in the parent domain for clock synchronization.
Within each domain, all DCs synchronize their clocks with the PDC emulator of their domains.
All client computers in the domain synchronize their clocks with the authenticating DC. If the
authenticating DC’s clock is ahead of the local time or the time difference between the two
clocks is more than 2 minutes, the time is immediately reset to match the DC’s clock. If the
authenticating DC’s clock is behind the current time, the computer’s clock is recalibrated
over the next 20 minutes until the times match.
The Kerberos authentication exchange:
The user presses Ctrl+alt+
name, password and domain you want to enter.
The client computer queries the DNS server to find a _Kerberos service locator SRV
resource record based on the client’s domain and site. The returned SRV resource record
is for a KDC that’s at the client’s local site for the domain the user wants to log on to.
The user sends a Kerberos Authentication Service Request (KRB_AS_REQ) to the DC
indicated in the returned SRV resource record.
The authentication service at the KDC authenticates the user, generates a TGT for the user,
and then sends back the TGT to the user in a Kerberos Authentication Service Response
KRB_AS_REP) message.
The following steps
explain how to acquire the service ticket for the computer:
The user sends a Ticket Granting Service Exchange Request (KRB_TGS_REQ) to the
KDC to acquire a service ticket for his computer.
======================================================================
winsec3.html PAGE 5 2002/04/14
The Ticket Granting Service of the KDC checks the TGT and the authenticator. If both
are valid, the Ticket Granting Service generates a service ticket and sends it back to the
user using a Ticket Granting Service Response (KRB_TGS_REP).
At the client computer, the service ticket is presented to the Local Security Authority,
which will create an access token for the user.
Network Authentication
Once a computer has been authenticated by the Network, the computer must be
authenticated by other computers, if they want to access resources on those computers.
Each an every time a computer access another computer on the network they must go
through this authentication process, top of page 77.
The user initiates by sending a Ticket Granting Service Request
(KRB_TGS_REQ) to the KDC to acquire a service ticket
for the target computer. It includes the TGT and an authenticator.
The Ticket Granting Service of the KDC checks the authenticator and the TGT, generates
a new service ticket, and sends it back to the user using a Kerberos Ticket Granting
Service Response (KRB_TGS_REP). The service ticket is encrypted using the long-
term key between the KDC and the target service.
The user sends the service ticket and an authenticator to the target server using a Kerberos
Application Request (KRB_AP_REQ).
The target server verifies the ticket with the authenticator, decrypts the session key using
the master key that’s shared with the KDC, and sends back an authenticator to the user
in a Kerberos Application Response (KRB_AP_REP).
Smart Card Authentication
All of your smart card information is on the stripe on the smart card. Windows 2000
supports the use of smart card authentication by using PKINIT extensions for Kerberos.
This allows public/private keys to be used to authenticate the user when he logs on to the
network in place of the standard Kerberos Authentication Service Request and Response.
KRB_AS_REQ and KRB_AS_REP are replaced with the PA_PK_AS_REQ and
PA_PK_AS_REP messages.
======================================================================
winsec3.html PAGE 6 2002/04/14
Private and Public Key Usage for Smart Card Logon
====================================================================
Process Key
Uses
====================================================================
Client-side encryption of the
Preauthorization data Private Key
KDC-side decryption of the
Preauthorization data Public Key
KDC-side encryption of
Session key Public Key
Client-side decryption of
Session key Private Key
=======================================================================
The user starts the logon process by introducing a smart card and by authenticating to
the card using the user PIN code. The smart card contains the user’s public key
credentials, private/public key pair, and certificate. A modified Kerberos Authentication
Service Request (PA_PK_AS_REQ) message is sent to the KDC.
The KDC validates the request by verifying the user’s certificate and the digital signature
with the Certification Authority (CA) that issued the certificate. The KDC queries Active
Directory to determine the mapping between the certificate included in the PA_PK_AS_REQ
and a Windows 2000 SID. When the mapping is determined, the KDC will issue a TGT for
the corresponding SID.
The KDC sends the TGT back to the user in a modified Kerberos Authentication
Service Response (PA_PK_AS_REP). The user retrieves the session key by decrypting the
session key with the private key located on the smart card.
Multiple Domain Authentication
Your forest often needs to have more than one domain. If it does, authentication will be
accomplished by using TGTs, referral tickets (TGTs for other domains), and service
tickets.
*** See page 79 ***
The following process would take place if a user in the west.Microsoft.com domain
attempted to access a network share on the computer named srv1.east.Microsoft.com:
======================================================================
winsec3.html PAGE 7 2002/04/14
The user sends a Ticket Granting Service Request (KRB_TGS_REQ) to the KDC in
his domain to acquire a service ticket for the srv1.east.Microsoft.com computer. Because
the target computer is in a different domain, the KDC that receives the request looks the
trust relationships that exist for the domain. Because no explicit trust relationship exists
between the west.Microsoft.com domain and the east.Microsoft.com domain, only the
default transitive trusts of a Windows 2000 forest, the KDC issues a TGT referral ticket
to the Microsoft.com domain in the KRB_TGS_REP packet that’s sent back to the client.
NOTE: If this connection is accessed frequently, you could set up a short-cut trust, or a
cross-link trust.
The user sends a KRB_TGS_REQ message to a KDC located in the Microsoft.com
domain to acquire a service ticket for the srv1.east.Microsoft.com computer. Because
there are different domains, the
KDC issues a KGT referral ticket to the east.Microsoft.com
domain in the KRB_TGS_REP packet that’s sent back to the client. The TGT is encrypted
using the interdomain key between the Microsoft.com domain and the east.Microsoft.com
domains.
The user sends a KRB_TGS_REQ message to the KDC located in the east.microsoft.com
domain to acquire a service ticket for the srv1.east.Microsoft.com computer. The service
ticket is encrypted using the long-term key shared by the KDC and the srv1.east.Microsoft.com
computer.
The user sends a KRB_AP_REQ containing the service ticket to the srv1.east.Microsoft.com
computer. The user can now access the resource.
Delegation
In client/server environments you might sometimes deploy multitiered client/server applications
(commonly referred to as n-tiered applications). In these scenarios, the first server that the user
connects to must often impersonate that user when the server connects to additional servers in
order to ensure that the entire process is run in the connecting user’s security context.
Delegation can take place only when the following criteria are met:
back-end services must all be running Windows 2000 in a Windows 2000 domain.
properties of the user account in Active Directory Users and Computers.
======================================================================
winsec3.html PAGE 8 2002/04/14
NOTE: If the service account is running under the local system account, the computer account
itself must be trusted for delegation. To enable this, open the properties of the computer
account in Active Directory Users and computers. In the General Tab select the Trust Computer
for Delegation check box.
When the account is designated as trusted for delegation, this enables the forwardable flag
on the service ticket. This flag allows services to request service tickets on behalf of the
client and run processes in the security context of the client.
Kerberos authentication when delegation takes place
Server1. The KDC sends the service ticket KRB_TGS_REP back to the user.
ticket to access Server2 in the security context of the user.
to access Server2.
authentication. Server1 now has access to services on the Server2 at the security level of the
original user.
Making the Decision
When you design your network for Kerberos Authentication support, you must consider
the following points:
Each site defined in Active Directory should have at least one domain controller for
authentication.
Kerberos authentication services.
======================================================================
winsec3.html PAGE 9 2002/04/14
authenticating DC must contact a global catalog server to enumerate universal group membership.
zone, where forestrootdomain
authentication. Even with the Directory Service Client loaded, Windows 95 & 98 and Windows
NT clients can’t authenticate using Kerberos.
Applying the Decision
Only the Windows 2000 clients in the Market Florist network can authenticate using Kerberos
V5. (Remember that Windows 95, NT can’t use Kerberos for authentication).
To ensure that Kerberos authentication is optimized for all four sites, you must include the
following components in the authentication design for Market Florist:
Each of the domains has sufficient DCs
at each of the four sites. The
have a dedicate DNS server. If the
WAN link to
access the DNS server to find SRV resource records for Kerberos authentication. This can result
in cached credentials being used
for authentication. The DNS servers in
don’t have a secondary zone for the _msdcs.marketflorist.ltd domain. If the WAN link is down
authentication can be a problem. You should configure this zone as a secondary zone on the
DNS servers in
The
configure at least one DC at these sites.
Lesson Summary:
your network infrastructure supports Kerberos authentication.
domain.
======================================================================
winsec3.html PAGE 10 2002/04/14
Lesson 3:
NTLM Authentication
Only Windows 2000 clients and UNIX clients can use Kerberos authentication in a Windows
2000 domain. To provide access to Windows NT 4.0 clients and Windows 95& 98 clients
running the Directory Service client, Windows 2000 continues to support the use of the
Windows NT LAN Manager (NTLMP) authentication tool.
Designing NTLM Authentication
This is used with Windows 2000 Professional users or users on Windows 2000 that aren’t
part of a domain.
The first version has lots of leaks, so another version 2 was developed. NTLM version 2,
was developed for Windows NT 4.0 Service Pack 4. The new security features are:
Unique session keys per connection. Each time a new connection is established, a unique
session key is generated for that session. Session Keys protected with a key exchange.
You must obtain the key pair to protect the session.
Unique keys generated
for the encryption and integrity of session data.
The key that’s used for the encryption of data from the client to the server will be different
from the one that’s used for the encryption of data from the server to the client.
In this environment the client is connecting to a server. Active Directory uses the MSV1_0
sub-authentication filter to perform the authentication.
The NTLM challenge response is sent from the client computer to the server that the client
is connecting to. The application server uses the local security authority (LSA) to log on to
the domain using the netlogon service.
The Netlogon service queries Active Directory using the MSV1_0 subauthentication filter to
validate the user.
If the user is validated, the Netlogon service returns the user and group SIDs from the
authenticating DC back to the server. For the logon process, NTLMv2 introduces a secure
channel to protect the authentication process.
======================================================================
winsec3.html PAGE 11 2002/04/14
Making the Decision
Because Kerberos authentication is available only to Windows 2000 client computers, your
network design must ensure that the next strongest form of authentication is available to non-
Windows 2000 client computers and Windows 2000 client computers.
Determining when NTLMv2 Authentication is Used
Client Use UTLMv2
when …….
Windows 2000 1. Authenticating to the local SAM database of a
Stand-alone Windows 2000-based computer
Authenticating with a Windows NT 4.0 computer
With SP4 or higher installed.
Windows NT 4.0 1. Authenticating with Windows 2000 and Windows
NT 4.0 servers and the client has service pack 4
Or higher applied.
Authenticating with Windows 2000 and Windows
NT 4.0 servers and the client has the
Directory Services Client installed.
Windows 95 & 98 1. Authenticating with Windows 2000 and Windows
NT 4.0 servers and the client has the Directory
Services Client installed.
Applying the Decision
The scenario has a combination of Windows NT 4.0 Workstation and Windows 95 clients
hat are unable to use Kerberos when authenticating with the network.
All the non-windows 2000 clients use NTLMv2 authentication. The Windows NT clients
Lesson Summary:
NTLM authentication is still used in a Windows 2000 network. Be sure that you know
when NTLM authentication is used and plan the deployment for the Directory Service
Client software to ensure that Windows 95 & 98 and Win NT 4.0 clients can use the added
security of NTLMv2 authentication. When Kerberos can’t be used, NTLMv2 provides
strong authentication security.
Lesson 4:
Authenticating Down-Level Clients
planning to allow these clients to authenticate with Active Directory without compromising
security on the network.
======================================================================
winsec3.html PAGE 12 2002/04/14
Analyzing Standard Authentication:
Windows 95 & 98 and NT 4.0 need the updated service pack to keep the security there.
With NTLMv2 updated service pack the above clients can have up-to-date security features.
The Microsoft Directory Service Client (DSClient) has been developed to counteract these
weaknesses, for the non-Windows 2000 clients.
Analyzing the Directory Services Client
The Directory Services client provides additional functionality to down-level clients so that
they can operate securely and efficiently in a Windows 2000 network environment.
NTLMv2 authentication protocol. Windows 95 & 98 & Windows NT 4.0 clients use this
when authenticating with Active Directory.
Site awareness. The DS client software allows the client to query DNS to find a DC in the
same site.
Search for objects in Active Directory. The DSClient software allows clients to search Active
Directory for printers and users from the Start/Search menu.
Reduces dependency on the PDC. The can connect to any domain controller for password
changes, not just the PDC.
Active Directory Services Interface (ADSI). Allows scripting to take place at the client that
writes changes to Active Directory.
Distributed Files System (DFS) fault tolerance client. Client can find DFS file shares in
Active Directory.
Active Directory Windows Address Book (WAB) property pages.
It’s also important to note that there are some features that the DSClient software doesn’t
provide.
Kerberos support. The DSClient software doesn’t provide Kerberos support to Windows
95 & 98 and Windows NT 4.0 clients.
======================================================================
winsec3.html PAGE 13 2002/04/14
Group Policy/Intellimirror support. Even with the DSClient software loaded, a Windows
95 & 98 or Windows NT 4.0 client won’t participate in Group Policy or Intellimirror.
NOTE: By default, Windows 95 and Windows 98 clients will connect to the PDC unless
the Load Balancing option is enabled in system policy. This is enabled in Default
Computer/Network/System Policies Update\Remove Update and Setting The Load
Balancing option.
IPSec/L2TP support. Windows 95 & 98 and NT 4.0 only support PPTP for VPN
connections. There’s no support for L2TP/IPSec connections.
Server Principal Name (SPN)/mutual authentication. The DSClient doesn’t provide
SPNs or mutual authentication to Windows 95, 98 and NT clients.
Dynamic DNS support. For Windows 95 & 98 and NT clients, the DHCP server must
be configured to update the DNS resource records on behalf of the client computers.
User Principal Name (UPN) authentication. The DSClient software doesn’t allow users
to authenticate using their UPN (user@domain.com). This is only allowed for Windows
2000 clients.
Once you’ve distributed the DSClient software to your down-level client computers, you
can restrict which protocols can be used to authenticate with a Windows 2000 computers.
down-level clients that use either LM or NTLM for authentication can authenticate with the
server.
support NTLMv2, this setting allows the use of NTLMv2 to be negotiated.
restrict the use of WIN 95 & 98 clients.
NTLMv2 authentication for down-level authentication requests.
respond with only the NTLMv2 authentication for down-level authentication requests.
NOTE: Windows NT 4.0 with Service Pack 4.0 or later will also support NTLMv2
authentication.
======================================================================
winsec3.html PAGE 14 2002/04/14
5 (Send NTLMv2 response only\refuse LM & NTLM). Ensures that only NTLMv2 responses
are sent and that authentication request that don’t use NTLMv2 will be rejected.
You can deploy the LMCompatibilityLevel setting using Windows 2000 Group Policy.
Making the Decision
When Windows 95, 98 and Windows NT 4.0 clients exist on the network, the default
authentication mechanism for the clients don’t use the strongest available form of
authentication.
NT 4.0 but all should have it for consistency.
has the new service pack. Develop a plan for the distribution of the DSClient software
and any registry updates that must be performed for client computers.
computers from the network if they can’t support NTLMv2 authentication.
Applying the Decision
Each of Market Florist’s four offices locations has down-level clients. Based on the
current network configuration, these down-level clients by default use less secure authentication
mechanisms.
Market Florist must ensure that a plan is created for the distribution of the DSClient
software to all Windows 95 and Windows NT 4.0 client computers.
Market Florist must ensure that all necessary registry settings are deployed to Windows
NT 4.0 and 95 clients.
You must configure Group Policy after the DSClient software is fully deployed to allow
only NTLMv2 authentication to be used. DNS services must be configured locally at each
site to ensure that down-level clients use the DSClient software can locate local DCs and
global catalog servers in the event that the WAN link is down the DNS services can’t be contacted.
======================================================================
winsec3.html PAGE 15 2002/04/14
Lesson Summary:
don’t create the proper design.
requirements as it removes the dependency of down-level clients on the PDC emulator
in a domain.
link failure to access the network.
Lesson 5:
Planning Server Placement for Authentication
DCs perform Windows 2000 authentication. A key part of your security design is ensuring
that Windows 2000 DCs are readily available to clients when they require DC services.
Determining Server Placement for Authentication
When you’re planning server placement for authentication services, the only servers to
consider are those that play a part in the authentication process and they are:
Planning DNS Server Placement
The DNS server must contain zone information so it has all the information needed to service
all areas of the network. In other words, each site must have a localized DNS server. The
zone _msdcs.forestrootdomain is available at all remote sites because the following
information is stored within this zone:
All global catalog servers in the forest. DNS doesn’t store the global catalog server
SRV resource records based on domains.
The globally Unique Identifier (GUID) representation of each domain. In
future versions it will be possible to rename Windows 2000 domains without reinstalling.
The GUID representation of each DC. DCs find replication partners based on the
DCs GUID, not on the DCs DNS fully Qualified domain name.
======================================================================
winsec3.html PAGE 16 2002/04/14
NOTE: You may need to install WINS for resolving NetBIOS names if you have pre-
windows 2000 clients.
Making the Decision
When designing your Windows 2000 network for authentication, you must configure the
DNS service to provide the following:
all clients if the WAN link to a central site is down.
accessed at that site.
Applying the Decision
Market Florist’s current network design doesn’t have sufficient DNS coverage should
WAN links be unavailable. To prevent the loss of DNS access in the event of a WAN
link failure, you should add the following components to the Market Florist network, See
page 96.
The DNS servers
at the
integrated zone to allow the zone to be replicated to child domains for the purpose of
locating the global catalog servers.
The
This is for fault tolerance.
Too confusing see the diagram.
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. This can be either
configured locally at each client computer or by using DHCP to assign the correct DNS IP
address based on IP address scope.
Planning DC Placement
DCs hosts the KDC service (kerberos) for Windows 2000. If the user attempts to longon
locally with a local DC. If unable, it links to another site.
======================================================================
winsec3.html PAGE 17 2002/04/14
Making the Decision
To ensure that clients authenticate locally, place at least two DCs at each remote site. It there
are no client computers or users at a remote site for a specific domain, there’s no reason to
deploy a DC for that domain at that remote site. Remember if the WAN link is down, users
are restricted to logon to cached credentials.
Applying the Decision
Each of Market Florist’s four sites has at least two DCs. Their presence ensures that all
authentications for the local domain won’t occur over the WAN. By installing the DSClient
software to all Windows 95 and Windows NT 4.0 clients, Market Florist also ensures that
all password changes can be made to local DCs, rather than to the PDC emulator for the
domain.
Planning Global Catalog Server Placement
Global catalog servers are contacted during the following authentication scenarios:
When the domain is in native mode, the authenticating DC contacts a global catalog server to
determine if the authenticating user is a member of any universal group. If the user cannot be
authenticated, they must be authenticated with cached credentials.
NOTE: In two cases a global catalog server isn’t required for authentication purposes. The
first is when the forest has only a single domain. Because there’s only a single domain, all
universal group memberships can be determined by querying the domain itself. The second
is when a domain is in mixed mode. Universal security groups don’t exist in a mixed mode
domain, so there’s no need to enumerate universal security groups.
When a user logs on at a Windows 2000-based computer using a User Principal Name
UPN), the global catalog is referenced to determine the account that’s associated with the
UPN. If the global catalog server is unavailable, the user will fail the authentication.
======================================================================
winsec3.html PAGE 18 2002/04/14
Making the Decision
Consider the following when placing global catalog servers:
Locate at least one global catalog server at each site. This ensures that clients will be able
to contact a local global catalog server if the WAN link is unavailable. Ensure that the
_msdcs.forestrootdomain DNS domain is available at all remote sites on a local DNS server.
Even in a single-domain environment, you must designate global catalog servers. LDAP
queries are sent to TCP port 3268, TCP port 3268 is only available on a DC when it’s
configured as a global catalog server.
Applying the Decision
There should be lots of duplication and each site should have a global catalog server and a
DNS. If the authentication happens over the WAN link you could be using cached
credentials.
Planning PDC Emulator Placement
Windows NT 4.0, Windows 95 & 98 clients connect to the PDC emulator for password
changes, and Windows 95 & 98 clients will connect to the PDC emulator for system policy
application by default.
Making the Decision
emulator for password changes.
of the network that’s easily accessible from all remote sites.
Applying the Decision
The main location of the network that will benefit from the application of the DSClient
software is the
domain is located at the
perform password changes across the
WAN link to
installed.
======================================================================
winsec3.html PAGE 18 2002/04/14
Lesson Summary:
server, and the PDC emulator to ensure that authentication requests are handled in a timely
manner.
network.