AD authentication uses two main protocols: Kerberos and NTLM
NTLM
The certification process is as follows:
- The client generates an NTLM hash locally, and the value is the hash value of the user's password.
- client sends the username to the application server.
- The application server generates a random value for the client, which is usually called nonce or challenge.
- client encrypts the nonce with NTLM hash and sends it to the application server.
- After receiving it, the application server sends it to the AD server along with the user name and nonce.
- AD generates an NTLM hash based on the user's password, encrypts the nonce, and then compares the client's message.
- If the values are the same, the authentication passes, and if they are different, the authentication fails.
Kerberos
Key terms:
- KDC: Key Distribution Center, which provides two services: Authentication Service (AS) and Ticket-Granting Service (TGS). The domain generates a domain account called krbtgt for KDC, and TGT uses the password for encryption and decryption. When a domain user accesses for the first time, they want the AS to authenticate, and after passing, the AS requests TGS to provide a ticket (TGT) to the domain user.
- SPN：Service Principal Name。 In addition to user accounts, AD accounts also have service accounts. The application will also have a service account associated with it, which will facilitate the application to access server resources, such as exchange, SQL, IIS, etc. SPN is a service used to associate the service, enabled by the application, with the service account in AD.
Certification Process:
1. When a domain user logs in, an AS request (AS_REQ) is sent to the DC, which contains an encrypted timestamp that is encrypted with the user's password hash and username.
2. After receiving the request, the DC uses the username and password hash of the user to decrypt it. The DC replies an AS reply (AS_REP) to the client, which includes a session key and a TGT (Ticket Granting Ticket). The session key is encrypted with the user's password hash. The TGT contains the group membership, domain, timestamp, client IP, and session key. TGT is also encrypted, encrypted with the KDC service account password, and the client cannot decrypt it. (TGT is valid for 10 hours by default, and updates that occur after that do not require the user to re-enter the password)
3. When a user requests a resource in the domain, a Ticket Granting Service Request (TGS_REQ) is sent, including the username, timestamp, TGT, and SPN. Timestamps and usernames are encrypted with a session key.
4. After receiving the request, the KDC first determines whether there is an SPN in the request, then decrypts the TGT, extracts the session key and the timestamp in TGT, and uses the session key in the TGT to decrypt the encrypted username and timestamp. Perform several checks:
(1) The timestamp decrypted by TGT must be valid. (If a replay attack occurs, the timestamp is invalid.) ）
(2) Whether the username in the TGT is consistent with the username in the request.
(3) Whether the IP address in the TGT is the same as the IP address in the request.
The check will reply to the client's Ticket Granting ServiceReply(TGS_REP), which contains the SPN authorized access, the new session key used for access between the client and the SPN, and the new Service Ticket service ticket (including the new session key, user name, and user group). Both the SPN authorized and the session key that accesses the SPN are encrypted with the session key in TGT. The service ticket is encrypted with the password of the corresponding SPN service account.
1. After the above process, the user has obtained the session key and service ticket related to the application service. The user sends an Application Request (AP_REQ) to the application service, which contains the user name and timestamp, and is encrypted with a session key.
2. The application service uses the service account password hash to decrypt the service ticket and extract the user, user group, and session key. Decrypt the username and timestamp in the AP_REQ with the decrypted session key. AP_REQ If so, the request is accepted, and the application service assigns permissions based on the user group information in the service ticket, and then the user can access the requested service.
Original address:The hyperlink login is visible.
|
Posted on 8/22/2023 7:16:28 PM
|
|
|
|
