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.
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.
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.
c.The service’s account must be enabled for delegation.
|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
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.