AD验证的过程
AD验证的过程
看看忘忘,忘忘看看。
摘录于这里
或者更多的信息看这里
User logs on with username & password.
-
Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ). 1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).
-
The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data.
-
The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket.
-
The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).
-
The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.
-
If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that added UNC hardening).
Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the DC.
Active Directory Kerberos Key Points:
Microsoft uses the NTLM password hash for Kerberos RC4 encryption. Kerberos policy is only checked when the TGT is created & the TGT is the user authenticator to the DC. The DC only checks the user account after the TGT is 20 minutes old to verify the account is valid or enabled. TGS PAC Validation only occurs in specific circumstances. When it does, LSASS on the server sends the PAC Validation request to the DC’s netlogon service (using NRPC) If it runs as a service, PAC validation is optional (disabled). If a service runs as System, it performs server signature verification on the PAC (computer account long-term key).
Forging Kerberos Tickets:
Forging Kerberos tickets depends on the password hash available to the attacker Golden Ticket requires the KRBTGT password hash. Silver ticket requires the Service Account (either the computer account or user account) password hash. Create anywhere and user anywhere on the network, without elevated rights. Spoof access without modifying AD groups. Once the KRBTGT account password is disclosed, the only way to prevent Golden Tickets is to change the KRBTGT password twice, since the current and previous passwords are kept for this account.