Active Directory - Authentication Methods
Active Directory Authentication Overview
Active Directory supports multiple authentication protocols and techniques that implement authentication to Windows computers as well as those running Linux and macOS.
Active Directory supports several older protocols including WDigest. While these may be useful for older operating systems like Windows 7 or Windows Server 2008 R2.
NTLM Authentication
NTLM authentication is used when a client authenticates to a server by IP address (instead of by hostname), or if the user attempts to authenticate to a hostname that is not registered on the Active Directory-integrated DNS server. Third party applications may also choose to use the NTLM authentication instead of Kerberos.
NTLM Authentication follows 7 steps:
The computer calculates a cryptographic hash, called the NTLM hash, from the user's password.
The client computer sends the username to the server.
The server returns a random value called the nonce or challenge.
The client then encrypts the nonce using the NTLM hash, now known as a response and sends it to the server
The server forwards the response along with the username and the nonce to the domain controller.
The domain controller then performs the validation since it already knows the NTLM hash of all users. The domain controller encrypts the nonce itself with the NTLM hash of the supplied username and compares the response it received from the server.
If the compared hashes are equal, then the authentication request is successful, and the domain controller approves the authentication.
Kerberos Authentication
The Kerberos authentication protocol is adopted from Kerberos version 5 created by MIT. While NTLM authentication works via a challenge-and-response paradigm, Windows-based Kerberos authentication uses a ticket system.
A key difference between these two protocols is that with NTLM authentication, the client starts the authentication process with the application server itself, as discussed in the previous section. On the other hand, Kerberos client authentication involves the use of domain controller in the role of a Key Distribution Center (KDC). The client starts the authentication process with the KDC and not the application server. A KDC service runs on each domain controller and is responsible for session tickets and temporary session keys to users and computers.
When a user logs in to their workstation, an Authentication Server Request (AS-REQ) is sent to the domain controller. The AS-REQ contains a timestamp that is encrypted using a hash derived from the password of the user and their username.
The domain controller, acting as the Key Distribution Center, receives the request and looks up the password hash associated with the specific user in the ntds.dit file and attempts to decrypt with the timestamp. If the decryption process is successful and the timestamp is not a duplicate, the authentication is considered successful.
The domain controller replies to the client with an Authentication Server Reply (AS-REP). Kerberos is a stateless protocol, so the AS-REP contains a session key and a Ticket Granting Ticket (TGT). The session key is encrypted using the user's password hash and may be decrypted by the client and reused. The TGT contains information regarding the user, the domain, a timestamp, the IP address of the client, and the session key. To avoid tampering, the TGT is encrypted by a secret key (NTLM hash of the ktbtgt account) known only to the KDC and cannot be decrypted by the client.
Once the client receives the session key and the TGT, the KDC considers the client authentication complete. By default, the TGT will be valid for ten hours, after which a renewal occurs. This renewal does not require the user to re-enter their password.
When a user wishes to access resources of the domain, it must construct a Ticket Granting Service Request (TGS-REQ) packet consisting of the current user, and a timestamp encrypted with the session key, the name of the resource, and the encrypted TGT and sends it to the KDC.
The Ticket-granting service on the KDC receives the TGS-REQ and if the resource exists in the domain, the TGT is decrypted using the secret key known only by the KDC. The session key is then extracted from the TGT and used to decrypt the username and timestamp of the request and the KDC performs several checks:
The TGT must have a valid timestamp
The username from the TGS-REQ has to match the username from the TGT
The client IP address needs to coincide with the TGT IP address
If this verification process succeeds, the ticket-granting service responds to the client with a Ticket Granting Server Reply (TGS-REP). This packet contains three parts:
The name of the service for which access has been granted.
A session key to be used between the client and the service
A service ticket containing the username and group memberships along with the newly-created session key.
The service ticket's service name and session key are encrypted using the original session key associated with the creation of the TGT. The service ticket is encrypted using the password hash of the service account registered with the service in question. Once the authentication process by the KDC is completed and the client has both a session key and a service ticket, the service authentication begins.
Service Authentication
First, the client sends the application server an Application Request (AP-REQ), which includes the username and a timestamp encrypted with the session key associated with the service ticket along with the service ticket itself.
The application server decrypts the service ticket using the service account password hash and extracts the username and the session key. It then uses the latter to decrypt the username from the AP-REQ. If the AP-REQ username matches the one decrypted from the service ticket, the request is accepted. Before access is granted, the service inspects the supplied group memberships in the service ticket and assigns appropriate permissions to the user, after which the user may access the requested service.
PKI in AD
Microsoft provides the AD role Active Directory Certificate Services (AD CS) to implement a PKI, which exchanges digital certificates between authenticated users and trusted resources.
If a server is installed as a Certification Authority (CA), it can issue and revoke digital certificates (and more). We could issue certificates for web servers and use HTTPS or to authenticate users based on certificates from the CA via Smart Cards.
These certificates may be marked as having a non-exportable private key for security reasons. If so, a private key associated with a certificate cannot be exported even with administrative privileges. However, there are various methods to export the certificate with the private key.
We can rely again on Mimikatz to accomplish this. The crypto module of mimikatz contains the capability to either patch the CrpytoAPI function with crypto::capi or Keylso service with crypto::cng, making non-exportable keys exportable.
Last updated