This article details Kerberos Authentication & Delegation within a Windows Domain environment.
What is Kerberos?
Kerberos is the preferred authentication protocol within a Windows / Active Directory environment, it is responsible for authenticating your user account to majority of on-premises services.
The name Kerberos comes from the Greek mythology Cerberus, the dog with 3 heads. Kerberos was adopted in Windows 2000, replacing New Technology LAN Manager (NTLM) as the default authentication protocol.
NTLM is a legacy authentication method that relies on a challenge-response protocol, it is insecure in the fact that parts of the authentication exchange are clear text, and the password hash is not salted — leaving the authentication exchange susceptible for interception where the user’s password can be cracked offline or used in pass-the-hash attacks.
Kerberos utilises symmetric-key cryptography and uses several ticket exchanges within Active Directory to provide authentication. Kerberos also provides extension of authentication by way of SPNs and Delegation.
What is Kerberos Delegation?
Kerberos delegation is an extension within the Kerberos authentication protocol that permits a server to act as an intermediary, impersonating a client and acquiring tickets to access additional network resources. By doing so, the server can leverage the authenticated identity of the client to perform actions on their behalf without requiring the client to reauthenticate for each resource individually.
Kerberos Constrained Delegation(KCD) is the desired end state is for each implementation of Delegation.
Delegation relies on Kerberos Authentication, Service Principal Names and SeEnableDelegation Privilege.
Before discussing delegation, we need to have a high-level understanding of how Kerberos Authentication works, as Delegation is an extension of Authentication.
Terminology & Attributes
Key Distribution Center (KDC): The KDC is an integrated service on each Domain Controller, the role of the KDC is to supply tickets to clients for the purpose of authentication using Kerberos.
Authentication Service (AS): The Authentication service is a component of the KDC, the role of the AS is to receive initial logon or authentication requests and in response, deny or provide a TGT to the requesting client, provided the client has met all requirements in proving their identity.
Ticket-Granting-Ticket (TGT): The TGT is the initial ticket required by clients to retrieve additional tickets. The TGT is a ticket provided to a client to prove their identity and authenticity. TGTs are then used later in the Kerberos Authentication process to request access to other services which in return provide additional tickets for access.
Ticket-Granting Service (TGS): The TGS is a service that verifies a clients request to a service via the supplied TGT. The TGS will provide a ‘service ticket (ST)’ to the requesting client for its own Domain or a referral to a neighboring Ticket-Granting Service in another trusted domain. The TGS is a component of the KDC.
Service Ticket (ST): The ST is used to authenticate to a Service. The ticket contains
Authenticator: Authenticators are included in the ticket exchange messages, they include details of the client’s identity and timestamp, as well as other details. The authenticator is encrypted by the client with sessions keys provided by the KDC during different stages of exchanges.
Service Ticket Exchange (STE): The Service verifying the Service Ticket trusts the KDC (mutual trust) through the process of receiving its own TGT, therefore when a Service Ticket comes to be validated, it knows that it can be trusted as the process of obtaining a Service Ticket requires the client to receive a TGT and a ST through the KDC.
S4U2PROXY: Service for User to Proxy (S4u2Proxy) is a Kerberos extension used in Constrained Delegation as part of impersonation. The S4u2Proxy allows the Service receiving a Service Ticket from client the ability to request admission to another service through the TGS Process. This is how Delegation works.
S4U2SELF: Service for Users to Self (S4u2Self) is used in Constrained Delegation with Protocol Transition. The purpose of this extension is to allow a Service to request a Service Ticket on behalf of a user to its own Service for the purpose of further delegation.
A good example of this is a client authenticates using NTLM to a HTTP Web Server that has delegation to a CIFS/SQL Back-End dependency. The client has authenticated via NTLM and therefore has does not have a forwardable ticket to be passed through the Delegation process to the Back-End dependency.
The S4u2Self extension will request a Service Ticket for the client, on behalf of the client to its own service that can then be used for the S4u2Proxy Extension and the client therefore receives admission to the HTTP Backend.
Kerberos Authentication Process
The authentication process works in 2 Phases and is dependent on 2 services within the KDC; The Authentication Server & the Ticket Granting Server.
Initial Authentication & Request for Service
The desired end state of the initial authentication process is for a client to have validated their identity and retrieved a TGT. The client then requests a Service ticket to the KDC using their TGT.
The KDC will respond with a Service ticket that can then be passed onto the requested service to validate.
The process is performed in 4 Steps.
1. KRB_AS_REQ
2. KRB_AS_REP
3. KRB_TGS_REQ
4. KRB_TGS_REP
KRB_AS_REQ: Kerberos Authentication Service Request
This process happens when a user logs onto a workstation or server and sends a message to the Authentication Server requesting a TGT. The initial request sent to the AS contains the username, domain name, client IP address
Because Kerberos Pre-Auth is enabled by default on all accounts, the user will also send a Timestamp (mitigates replay attacks) that is encrypted by the clients Password.
KRB_AS_REP: Kerberos Authentication Service Reply
The KDC receives all relevant information, in particular the username, domain name, IP Address.
Because the KDC knows the password of the client, it can decrypt the timestamp with that password. Therefore, verifies the identity of the client requesting as authentic.
The KDC then sends the Reply containing a variety of data including a TGT and session key.
KRB_TGS_REQ: Kerberos Ticket-granting Server Request
When the client requires access to a service, it will send a request to the TGS containing the TGT, Authentication Header and a TGS body containing details of what service this request is intended for — This is in the form of a Service Principal Name (SPN)
KRB_TGS_REP: Kerberos Ticket-granting Server Reply
The KDC receives the TGS Request and replies with a Service Ticket, encrypted using the Service Accounts secret key (e.g., svc_web@contoso.com)
Accessing the Service
The final phase of getting access to a Service is using what we have received in the initial authentication process.
The Service ticket does NOT determine authorization, only authentication — It is up to the Service receiving the Service ticket to determine what authorization to services are available based on the client username and group memberships received in the Service Ticket.
This process is performed in 2 steps:
1. KRB_AP_REQ
2. KRB_AP_REP
KRB_AP_REP: Kerberos Application Server Request
The client now talks directly to the Service, it Provides the Request containing a Service Ticket and Authenticator
KRB_AP_REP: Kerberos Application Server Reply
The Application Server receives the REQ from the client and uses its session keys to decrypt the authenticator message — it evaluates the details in the request, in particular the time stamp within the authenticator.
The Application Server then responds with a reply to the client. The client will evaluate the details within the reply and compare that the timestamps match (time skew). If this is true, then the connection proceeds.
Authentication & Request for Service (High Level) — https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fintroductiontokerberosauthentication.htm
Delegation
There are four different types of delegation in Kerberos:
1. Constrained Delegation — Kerberos Only (Preferred)
2. Constrained Delegation with Protocol Transition
3. Unconstrained Delegation (Insecure)
4. Resource Based Constrained Delegation.
Constrained Delegation — Kerberos Only. (KCD)
Constrained Delegation Kerberos only is the most secure of all Delegation and Constrained Delegation.
KCD uses the S4u2proxy extension from (“Service A”) to request a TGS on behalf of the connecting client to reach (“Service B”) if (“Service A”) is allowed to delegate to (“Service B”) through (“msDS-AllowedToDelegate”), the TGS will be provided and will have the ‘Forwardable’ flag set.
The Forwardable Flag is never set for accounts that are configured for “Sensitive, cannot delegate (“USER_NOT_DELEGATED” attribute) or if the user is a member of the ‘Protected Users Group’.
Kerberos Constrained Delegation — https://eladshamir.com/2019/01/28/Wagging-the-Dog.html
Attributes Used and Configured:
TrustedForDelegation: $False
TustedToAuthForDelegation: $False
msds-AllowedToDelegateTo: <SPNs of Services Delegating to>
Constrained Delegation configured in GUI
S4U2Proxy — https://www.notsoshant.io/blog/attacking-kerberos-constrained-delegation/
Constrained Delegation with Protocol Transition (KCD-PT)
Delegation is constrained to a chosen server and service, but an authentication method is not strictly Kerberos. This can mean a client can authenticate to a service using NTLM.
Service A requires a Service Ticket from the client before it can be delegated to another service.
(“Service A”) will use S4u2Self to request to a Service Ticket for that client to authenticate to itself before using S4u2Proxy and requesting a Service Ticket on behalf of that client for delegation to (“Service B”).
Attributes Used and Configured:
TrustedForDelegation: $False
TrustedToAuthForDelegation: $True
msds-AllowedToDelegateTo: <SPNs of Services Delegating to>
Constrained Delegation with Protocol Transition in GUI
S2U2Proxy & S4U2Proxy — Screenshot: S4U2Proxy — https://www.notsoshant.io/blog/attacking-kerberos-constrained-delegation/
Kerberos Unconstrained Delegation (KUD)
Insecure in the fact that a service uses the clients TGT to request a TGS for the client and then impersonate that user to ANY service it requests.
Kerberos Unconstrained Delegation — https://eladshamir.com/2019/01/28/Wagging-the-Dog.html
The following examples of Unconstrained Delegation show it looks in the GUI and cmdline.
User 1 & 2 both with alternate Protocol Transition flags set
Attributes Used:
TrustedForDelegation: $True
Both accounts are configured for Unconstrained Delegation.
User 1 also has the ‘TrustedtoAuthForDelegation’ flag set for protocol transition but since ‘TrustedForDelegation’ is configured, it is redundant.
User 1 Delegation GUI
User 2 Delegation GUI
Resource Based Constrained Delegation (RBDC)
RBCD makes use of msds-AllowedToActOnBehalfOfOtherIdentity attribute.
Like classic Constrained Delegation but in Reverse. With RBCD, we configure the (“Service B”) to receive Delegation from (“Service A”)
GMSAs and Delegation
GMSA’s should be configured with Constrained Kerberos Delegation Only.
1. TrustedForDelegation: $false
2. TrustedToAuthForDelegation: $false
3. msDS-AllowedToDelegateTo: $null
The only thing required to configure delegation is to configure no.3 (msDS-AllowedtoDelegateTo).
By Default, configuring delegation requires the SeEnableDelegation privilege which is reserved only to Domain and Enterprise Administrators.
I hope I will be able to give you inspiration and ways to deal with machines related to AD environment, thanks for reading and stay tuned for more articles and articles
Ahhh and don’t forget to follow me ;)
See you in the next article
