> For the complete documentation index, see [llms.txt](https://0xa1mn.gitbook.io/cyber-explained/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xa1mn.gitbook.io/cyber-explained/technologies/kerberos.md). # Kerberos ### What is kerberos ? Kerberos is a protocol for **authenticating** service requests between trusted hosts across an untrusted network, such as the internet. Kerberos support is built in to all major computer operating systems, including Microsoft Windows, Apple macOS, FreeBSD and Linux. ### What is Realm? A Kerberos realm is the domain over which a Kerberos authentication server has the authority to authenticate a user, host or service. A realm name is often, but not always the upper case version of the name of the DNS domain over which it presides. ### What is the difference between Kerberos and NTLM? Before Kerberos, Microsoft used an authentication technology called NTLM. NTLM stands for NT Lan Manager and is a challenge-response authentication protocol. The target computer or domain controller challenge and check the password, and store password hashes for continued use. The biggest difference between the two systems is the third-party verification and stronger encryption capability in Kerberos. This extra step in the process provides a significant additional layer of security over NTLM. NTLM systems can get hacked in a matter of hours these days: it’s simply older technology, and you shouldn’t rely upon NTLM to protect sensitive data. ### Kerberos vs LDAP When reading about Kerberos, you’ll frequently see mentions of LDAP. Kerberos and LDAP are commonly joined together (including in Active Directory) to provide a centralized user directory (LDAP) and authentication (Kerberos) services. LDAP, the Lightweight Directory Access Protocol, stores information about users, groups, and other objects (like computers) in a central location. It can also provide for simple authentication, however these native protocols, unlike Kerberos, generally require the user’s secret (i.e. password) to be transmitted over the network. Each resource the user wants to access must handle the user’s password and separately authenticate the user to the directory. Unlike LDAP, Kerberos provides for single sign-on functionality. Once a user has authenticated to the KDC, no other service (like an intranet site or file share) needs the user’s password. The KDC – that trusted third-party – is responsible for issuing tickets that each service trusts. The combination of LDAP and Kerberos provides centralized user management and authentication, and in larger networks this provides substantial security benefits. ### **Transport layer** Kerberos uses either UDP or TCP as transport protocol, which sends data in cleartext. Due to this Kerberos is responsible for providing encryption. Ports used by Kerberos are UDP/88 and TCP/88. ### Kerberos items #### 1. Agents these components work together to provide authentication in Kerberos * **Client or user** who wants to access to the service. * **services or AP** (Application Server) which offers the **service** required by the user. * **KDC** (Key Distribution Center), the main service of Kerberos, responsible of issuing the tickets, installed on the DC (Domain Controller). It is supported by the **AS** (Authentication Service), which issues the TGTs. ![](https://3550763689-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLmPdoBONhckxJWWSmjo5%2Fuploads%2FvzQXbCmuagJAvjR6p5SG%2FUntitled.png?alt=media\&token=f57fc55c-a062-4990-8123-9eb1c5498ea5) #### 2. Encryption keys There are several structures handled by Kerberos, as tickets. Many of those structures are encrypted or signed in order to prevent being tampered by third parties. These keys are the following: * **KDC or krbtgt key** which is derivate from krbtgt account NTLM hash. * **User key** which is derivate from user NTLM hash. * **Service key** which is derivate from the NTLM hash of service owner, which can be an user or computer account. * **Session key** which is negotiated between the user and KDC. * **Service session key** to be use between user and service. #### 3. Tickets The main structures handled by Kerberos are the tickets. These tickets are delivered to the users in order to be used by them to perform several actions in the Kerberos realm. There are 2 types: * The **TGS** (Ticket Granting Service) is the ticket which user can use to authenticate against a service. It is encrypted with the service key. * The **TGT** (Ticket Granting Ticket) is the ticket presented to the KDC to request for TGSs. It is encrypted with the KDC key. #### 4. **PAC** The **PAC** (Privilege Attribute Certificate) is an structure included in almost every ticket. This structure contains the privileges of the user and it is signed with the KDC key. It is possible to services to verify the PAC by comunicating with the KDC, although this does not happens often. Nevertheless, the PAC verification consists of checking only its signature, without inspecting if privileges inside of PAC are correct. Furthermore, a client can avoid the inclusion of the PAC inside the ticket by specifying it in *KERB-PA-PAC-REQUEST* field of ticket request. #### 5. **Messages** Kerberos uses differents kinds of messages. The most interesting are the following: * **KRB\_AS\_REQ**: Used to request the TGT to KDC. * **KRB\_AS\_REP**: Used to deliver the TGT by KDC. * **KRB\_TGS\_REQ**: Used to request the TGS to KDC, using the TGT. * **KRB\_TGS\_REP**: Used to deliver the TGS by KDC. * **KRB\_AP\_REQ**: Used to authenticate a user against a service, using the TGS. * **KRB\_AP\_REP**: (Optional) Used by service to identify itself against the user. * **KRB\_ERROR**: Message to comunicate error conditions. Additionally, even if it is not part of Kerberos, but NRPC, the AP optionally could use the **KERB\_VERIFY\_PAC\_REQUEST** message to send to KDC the signature of PAC, and verify if it is correct. ![](https://3550763689-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLmPdoBONhckxJWWSmjo5%2Fuploads%2FoOaJ56oId4eU93HZZS7N%2FUntitled%201.png?alt=media\&token=3ead51f7-764b-42f7-a023-b799149c6321) ### Authentication process In this section, the sequency of messages to perform authentication will be studied, starting from a user without tickets, up to being authenticated against the desired service. check this video: ![](https://3550763689-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLmPdoBONhckxJWWSmjo5%2Fuploads%2FYtD492UwqdtfrqnIyqdn%2FUntitled%202.png?alt=media\&token=3ed835ac-24d5-4185-a316-9621e8dcd419) ![](https://3550763689-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLmPdoBONhckxJWWSmjo5%2Fuploads%2FXyeL4UiyZugLkIRBTuP1%2FUntitled%203.png?alt=media\&token=4199886c-8a67-469d-a960-19d143ca971e) #### 1. KRB\_AS\_REQ: Request TGT from Authentication Service (AS) Firstly, user must get a TGT from KDC. To achieve this, a KRB\_AS\_REQ must be sent: ![https://www.tarlogic.com/wp-content/uploads/2019/03/KRB\_AS\_REQ.png](https://www.tarlogic.com/wp-content/uploads/2019/03/KRB_AS_REQ.png) KRB\_AS\_REQ schema message *KRB\_AS\_REQ* has, among others, the following fields: * A encrypted **timestamp** with client key, to authenticate user and prevent replay attacks * **Username** of authenticated user * The service **SPN** asociated with **krbtgt** account * A **Nonce** generated by the user Note: the encrypted timestamp is only necessary if user requires preauthentication, which is common, except if [*DONT\_REQ\_PREAUTH*](https://support.microsoft.com/en-us/help/305144/how-to-use-the-useraccountcontrol-flags-to-manipulate-user-account-pro) flag is set in user account. #### 2. **KRB\_AS\_REP: TGT Received from Authentication Service** After receiving the request, the KDC verifies the user identity by decrypting the timestamp. If the message is correct, then it must respond with a *KRB\_AS\_REP*: ![https://www.tarlogic.com/wp-content/uploads/2019/02/KRB\_AS\_REP.png](https://www.tarlogic.com/wp-content/uploads/2019/02/KRB_AS_REP.png) KRB\_AS\_REP schema message *KRB\_AS\_REP* includes the next information: * **Username** * **TGT**, which includes: * **Username** * **Session key** * **Expiration date** of TGT * **PAC** with user privileges, signed by KDC * Some **encrypted data** with user key, which includes: * **Session key** * **Expiration date** of TGT * User **nonce**, to prevent replay attacks Once finished, user already has the TGT, which can be used to request TGSs, and afterwards access to the services. #### 3. **KRB\_TGS\_REQ: Present TGT and TGS request** In order to request a TGS, a *KRB\_TGS\_REQ* message must be sent to KDC: ![https://www.tarlogic.com/wp-content/uploads/2019/02/KRB\_TGS\_REQ-1.png](https://www.tarlogic.com/wp-content/uploads/2019/02/KRB_TGS_REQ-1.png) KRB\_TGS\_REQ schema message *KRB\_TGS\_REQ* includes: * **Encrypted data** with session key: * **Username** * **Timestamp** * **TGT** * **SPN** of requested service * **Nonce** generated by user #### 4. **KRB\_TGS\_REP**: Receive TGS from KDC After receiving the *KRB\_TGS\_REQ* message, the KDC returns a TGS inside of *KRB\_TGS\_REP*: ![https://www.tarlogic.com/wp-content/uploads/2019/02/KRB\_TGS\_REP.png](https://www.tarlogic.com/wp-content/uploads/2019/02/KRB_TGS_REP.png) KRB\_TGS\_REP schema message *KRB\_TGS\_REP* includes: * **Username** * **TGS**, which contains: * **Service session key** * **Username** * **Expiration date** of TGS * **PAC** with user privileges, signed by KDC * **Encrypted data** with session key: * **Service session key** * **Expiration date** of TGS * User **nonce**, to prevent replay attacks #### 5. **KRB\_AP\_REQ: Present TGS to Application Server for Authorization** To finish, if everything went well, the user already has a valid TGS to interact with service. In order to use it, user must send to the AP a *KRB\_AP\_REQ* message: ![https://www.tarlogic.com/wp-content/uploads/2019/02/KRB\_AP\_REQ.png](https://www.tarlogic.com/wp-content/uploads/2019/02/KRB_AP_REQ.png) KRB\_AP\_REQ schema message *KRB\_AP\_REQ* includes: * **TGS** * **Encrypted data** with service session key: * **Username** * **Timestamp**, to avoid replay attacks #### 6. KRB\_AP\_REP: Grant Client Access to the Service After that, if user privileges are rigth, this can access to service. If is the case, which not usually happens, the AP will verify the PAC against the KDC. And also, if mutual authentication is needed it will respond to user with a *KRB\_AP\_REP* message. * The client receives the message and decrypts it with the service session key. * The Application Server extracts the Privilege Attribute Certificate (PAC) from the service ticket to verify its contents with a domain controller. * Validation of the ticket/PAC only happens when the Ticket Granting Ticket (TGT) is older than 20 minutes. ### Important Factors There are a handful of factors that influence how Kerberos operates, and can be sources of problems if not sufficiently provided for. * **Replication between domain controllers** If multiple domain controllers (i.e. multiple KDCs) are deployed, then replication must be enabled and converge in a timely manner. Should replication fail or convergence be delayed, authentication failures are possible when a user changes their password. * **Clients and KDCs must use NETBIOS and DNS name resolution** Kerberos Service Principal Names normally include NETBIOS and DNS addresses, which means both the KDC and Client must be able to resolve those names the same way. In \[certain situations]\([https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip#:\~:text=by IP address.-,Configuring a Service Principal Name as IP Address,%2Ffs.contoso.com .)](https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip#:~:text=by%20IP%20address.-,Configuring%20a%20Service%20Principal%20Name%20as%20IP%20Address,%2Ffs.contoso.com%20.\)), IP addresses may also be used in Service Principal Names. * **Clients and KDCs must have their clocks synchronized** Accurate measurement of time is important in Kerberos to prevent replay attacks. Kerberos supports a configurable time skew (default 5 minutes) outside of which authentication will fail. * **Clients and KDCs must be able to communicate on the network** Kerberos traffic occurs on TCP and UDP port 88, which must be accessible from all clients to at least one KDC (domain controller). * **Clients, Users, and Services must have unique names** Duplicate names for computers, users, or Service Principal Names can cause Kerberos unexpected Kerberos authentication failures. resources: