Authentication Requests Test

Authentication of domain user logins is a core function of an Active Directory server. The default authentication protocol used by the AD server is Kerberos. Kerberos authentication is based on specially formatted data packets known as tickets. In Kerberos, these tickets pass through the network instead of passwords. Transmitting tickets instead of passwords makes the authentication process more resistant to attackers who can intercept the network traffic.

In a Kerberos environment, the authentication process begins at logon. The following steps describe the Kerberos authentication process:

1. When a user enters a user name and password, the computer sends the user name to the KDC (Key Distribution Center). The Key Distribution Center (KDC) maintains a database of account information for all security principals in the domain. The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long term key. The long term key is derived from a user's logon password.
2. Upon the receipt of a user name, the KDC looks up the user's master key (KA), which is based on the user's password. The KDC then creates two items: a session key (SA) to share with the user and a Ticket-Granting Ticket (TGT). The TGT includes a second copy of the SA, the user name, and an expiration time. The KDC encrypts this ticket by using its own master key (KKDC), which only the KDC knows.
3. The client computer receives the information from the KDC and runs the user's password through a one-way hashing function, which converts the password into the user's KA (i.e., master key). The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.
4. When a Kerberos client needs to access resources on a server that is a member of the same domain, it contacts the KDC. The client will present its TGT and a timestamp encrypted with the session key that is already shared with the KDC. The KDC decrypts the TGT using its KKDC. The TGT contains the user name and a copy of the SA. The KDC uses the SA to decrypt the timestamp. The KDC can confirm that this request actually comes from the user because only the user can use the SA.
5. Next, the KDC creates a pair of tickets, one for the client and one for the server on which the client needs to access resources. Each ticket contains the name of the user requesting the service, the recipient of the request, a timestamp that declares when the ticket was created, and a time duration that says how long the tickets are valid. Both tickets also contain a new key (KAB) that will be shared between the client and the server so they can securely communicate.
6. The KDC takes the server's ticket and encrypts it using the server master key (KB). Then the KDC nests the server's ticket inside the client's ticket, which also contains the KAB. The KDC encrypts the whole thing using the session key that it shares with the user from the logon process. The KDC then sends all the information to the user.
7. When the user receives the ticket, the user decrypts it using the SA. This exposes the KAB to the client and also exposes the server's ticket. The user cannot read the server's ticket. The user will encrypt the timestamp by using the KAB and send the timestamp and the server's ticket to the server on which the client wants to access resources. When it receives these two items, the server first decrypts its own ticket by using its KB. This permits access to the KAB, which can then decrypt the timestamp from the client.

In situations where a domain controller is not available or is unreachable, NTLM (the NT LAN Manager) is used as the authentication protocol. For example, NTLM would be used if a client is not Kerberos capable, the server is not joined to a domain, or the user is remotely authenticating over the web.

In some other environments, Digest authentication is supported. Digest authentication offers the same functionality as Basic authentication; however, Digest authentication provides a security improvement because a user's credentials are not sent across the network in plaintext. Digest authentication sends credentials across the network as a Message Digest 5 (MD5) hash, which is also known as the MD5 message digest, in which the credentials cannot be deciphered from the hash.

Regardless of the protocol/authentication mode used, the quality of a user's experience with the AD server largely relies on how fast his/her login is authenticated by the AD server. The slightest of delays will hence not be tolerated! Administrators therefore need to keep their eyes open at all times for authentication-related latencies, isolate their source, and fix the problems, so that users are able to login to their systems quickly. The Authentication Performance test helps administrators in this regard.

This test reports the rate at which Kerberos, NTLM, and Digest authentication requests are serviced by the AD server and thus promptly reveals delays in authentication (if any). Where latencies are noticed in Kerberos requests, the test goes one step further and indicates the probable source of the latencies - could it be because the KDC took too long to grant TGTs to the clients? or is it because the KDC took too long to process the TGTs and grant the clients access to authorized resources?

Target of the test : An Active Directory or Domain Controller on Windows

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every Active Directory site that is being monitored

Configurable parameters for the test

Parameters	Description
Test period	This indicates how often should the test be executed.
Host	The IP address of the machine where the Active Directory is installed.
Port	The port number through which the Active Directory communicates. The default port number is 389.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Kerberos requests	Indicates the number of times per second that clients use a ticket to authenticate to the domain controller.	Reqs/Sec	A low value indicates a bottleneck when processing Kerberos requests.
Digest requests	Indicates the rate at which requests from a potential user were received by a network server and then sent to a domain controller.	Reqs/Sec	A low value indicates a bottleneck when processing Digest requests.
NTLM requests	Indicates the rate at which NTLM authentication requests were serviced by the domain controller.	Reqs/Sec	A low value indicates a bottleneck when processing NTLM requests. A high value for this measure indicates that the user requested some network resource, which basically belongs to the Windows NT network. Accessing this kind of resource needs authentication, which is serviced by the domain controller, who is having the PDC emulator operation role. Installing the domain controller with PDC emulator operation role in the target environment can solve this problem.
Authentication requests	Indicates the number of Authentication Server (AS) requests serviced by the Kerberos Key Distribution Center (KDC) per second.	Reqs/Sec	AS requests are used by the client to obtain a ticket-granting ticket. If the AD server appears to be taking too long to process Kerberos requests - i.e., if the value of the Kerberos requests measure is too high - then you can compare the value of this measure with that of the Ticket requests measure to know where the request spent too much time - when granting TGTs to clients? or when processing the TGTs to allow users access to a resource?
Ticket requests	Indicates the number of Ticket Granting Server (TGS) requests serviced by the KDC per second.	Reqs/Sec	TGS requests are used by the client to obtain a ticket to a resource. If the AD server appears to be taking too long to process Kerberos requests - i.e., if the value of the Kerberos requests measure is too high - then you can compare the value of this measure with that of the Authentication requests measure to know where the request spent too much time - when granting TGTs to clients? or when processing the TGTs to allow users access to a resource?