ntml certification
Generally used in workgroup environments, that is, personal PCs.
Process:
1. The client sends the user name to the server
2. The server sends a challenge to the client and encrypts it with the NTML hash of the sent user name to generate NET-NTML and store it in the memory.
3. After receiving the challenge, the customer encrypts it with its own NTML hash to generate a response, and sends the response to the server
4. The server verifies whether the response is equal to the NET-NTML in the memory. If they are equal, the authentication is successful.
Kerberos authentication
If cat wants to access the Tom server, it will go through the following authentication steps.
1. The client sends an authenticator to kdc's as to say that it is a cat, and its content is a Timestamp encrypted by the Master key of the Client, and it also sends Client name & realm in plain text: Simply put, it is Domain name\Client such as test \zhangsan. The parameter server name will also be sent. At this time, the server name is the name of tgs, and there are other things such as ip and encryption. Because the client needs to access tgs next to get the ticket.
Send Content:
1.authenticator (master key encrypted timestamp)
2.client info (id and ip)
3.serverName here is the name of tgs
4.tgt lifetime
2. After receiving the data, as uses cat's master to decrypt the authenticator and analyze the results. If the verification is successful, as uses cat's master to encrypt a randomly generated challenge to generate the first value. This challenge is the session key (C -KDC). Then generate a tgt encrypted with the hash of krbtgt. This tgt contains the user information of cat, the timestamp, and the session key used to communicate with the client and kdc, which is the previously generated challenge.
Send Content:
1. tgt: client name, client ip, tgs name, timestamp, expiration time of tgt, session key (kdc-client)
2. session key (kdc-client) tgs encrypted by the client's master key Name, timestamp, expiration time
3. The client receives these two pieces of information and decrypts it with its own master key to obtain the session key. Then use the session key to encrypt your own information and timestamp to get the authenticator. Send the three data of authenticator, server name you want to access, and TGT to TGS.
Send Content:
1.authenticator. The timestamp encrypted by the session key (kdc-client) also has the name of the client
2.tgt. Same as above
3.serverName Here is the name of the service to be accessed
4.Ticket lifetime
4. TGS gets these three values. First decrypt the TGT with your own master key to get the client info, timestamp and session key (C-KDC). Use this session key to decrypt the authenticator to get the client info and timestamp. Compare two user information. If they are the same, the authentication is successful, proving that the client is the person it claims. After the authentication is successful, the client info is used to encrypt the client info with the master key of the server applying for access and a session key dedicated to the communication between the client and the specified server to be accessed. These things are combined to form the contents of the ticket. Then use the session key used for communication between the KDC and the client to encrypt the session key between the client and the server. Send these two sets of data to the client.
Send Content:
1. Ticket: client name, client ip, expiration time, session key (client-server), server name is tom, timestamp. The previous ones are encrypted by the master key of the server.
2. The session key (client-server) encrypted by the session key (kdc-client), timestamp, expiration time, server name
The principle of the gold bill is to use the hash of krbtgt to forge the content of the TGT. Change the client parameters and session key inside. Let TGS think that I am who I claim to be, of course I generally claim to be an administrator. The fourth step is mainly to verify the identity of the client.
5. The client gets a ticket and data encrypted by the (client-KDC) session key. First use the session key (C-KDC) to decrypt the data to get the session key (SC). Use this session key (SC) to encrypt your client info and timestamp to generate an authenticator. Send the authenticator and ticket to the server to be accessed.
Send Content:
1.authenticator. The timestamp encrypted by the session key (cs) and client info
2.ticket
###A silver bill is a counterfeit ticket. The core point of forging a TGS ticket is to be able to obtain the ntlm hash of the target server.
The ###spn attack is to find the server whose "master" is krbtgt. In this way, you can request a ticket encrypted with krbtgt's hash. The encrypted content of this ticket is client info, a session key, and timestamp. At this time, brute force cracking techniques can be used to crack the ticket. Knowing that there is client info related information in the cracking result, the cracking is considered successful. Then get the krbtgt password, which can be used as a golden ticket to win the entire domain environment.
6. The server decrypts the ticket with its own master key to obtain the session key and client info. Then use the session key to decrypt the authenticator. Compare the information to determine whether the verification is successful. After success, it will return a message encrypted with session key (sc) containing client info and timestamp.
The contents of TGT and ticket are basically the same. Only the encryption method is different. One is encrypted with krbtgt's hash, and the other is encrypted with sever's hash.
The content inside is the client's info and timestamp or session key, but a session key is between the client and kdc, and the other is between the client and the server.
PAC certification
Pac authentication is when the second step of kerberos authentication is successful, pac will be clipped in the returned TGT to the client. After that, tgs will be stored in the ticket returned to the client and finally transmitted to the server.
Implementation of PAC
After the authentication process between the user and the KDC is completed, when the Client needs to access a certain service provided by the Server, the Server needs to pass the Client's User SID and other information to the KDC in order to determine whether the user has legal authority, and the KDC judges the user through the SID The user group information, user permissions, etc., and then return the results to the Server, and the Server compares this information with the ACL of the resource requested by the user, and finally decides whether to provide the user with the corresponding service.
The PAC will encrypt the AS in the TGT in the KRB_AS_REP and send it to the Client, and then forward it to the TGS to verify the service requested by the Client.
The PAC contains two digital signatures, PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM. These two digital signatures are encrypted by the server-side password HASH and the KDC password HASH, respectively.
At the same time, after TGS decrypts, it verifies whether the signature is correct, and then reconstructs a new PAC in the ticket and returns it to the client. The client sends the ticket to the server for verification.
Appendix:
The detailed content of the first set of information ticket: (encrypted by the master key of the server)
your name/ID
HTTP service name/ID
your network address (if there are multiple hosts, it is an IP list. If it is any one Machine, then it is null) The lifetime of the
timestamp
ticket
HTTP Service Session Key
The second set of information: the lifetime of the ticket with the
HTTP service name/ID
timestamp encrypted by the session key (kdc-C) HTTP Service Session Key
The content of the first set of information tgt: encrypted by the master key of krbtgt
Your name/ID is the name of the client
TGS name/ID
timestamp
your network address (if there are multiple hosts, it is an IP list. If it is Any machine, then it is null)
The lifetime of TGT
TGS Session Key is used to communicate with C and KDC
The second set of information:
the name/ID
timestamp of the TGS encrypted by the master key of the client
Life
TGS Session Key