Client, KDC, service, and krbtgt: Kerberos actors and trust relationships

1. Core mechanism

The decision is made on the KDC when a principal wants to be proven to another principal: the KDC decides with whose key to seal and verify the ticket he presented. The boundary of this lesson is the identity of the actors, key ownership and trust relationship; The full field structure of the AS-REQ/TGS-REQ flow and the separation of the ticket and the KDC-reply enc-part are covered in 06.02. The question here is not 'how does the ticket flow', but 'which key seals who and what'.

Interfaces and specifications

• Client: the ordinary password-based AS path uses its long-term key as the reply key. Other pre-authentication mechanisms can select a different reply key. The client does not know the krbtgt key or open the TGT ciphertext.
• KDC: is a service of the domain; It has two components: Authentication Service (AS) issues TGT, Ticket-Granting Service (TGS) issues service tickets. It runs as a single process in LSA on the domain controller and cannot be stopped.
• krbtgt: KDC's account; It is created automatically when the domain is created, it cannot be deleted and its name cannot be changed; It has a random password, and from this password the key that seals the TGTs is derived. The krbtgt key is the root of domain-wide trust.
• Service: the SPN associates an instance with its sign-in account. The KDC protects the service-ticket enc-part with that account's key. One account may support multiple SPNs or instances; a separate key per instance is not guaranteed.
• Trust (inter-realm): when trust is established between two realms, a common trust account and an inter-realm key derived from it are created; The cross-realm referral ticket is sealed with this key.

Four actors, four key ownerships

In the ordinary password-based path, the client and KDC use the client account's long-term key. When pre-authentication is required, the KDC checks the submitted proof first. An AS reply can also be issued when pre-authentication is not required; issuance alone does not prove that the requester knows the account secret.

The KDC resolves the requested SPN to an account and protects the ticket with that account's key. The client carries the ticket without opening its ciphertext. Other instances using the same account share the key boundary, so the SPN name and account scope must be distinguished.

KDC's own key is the key to the krbtgt account. TGT (Ticket-Granting Ticket) is a special ticket that literally 'services krbtgt': the KDC seals the TGT it issues with the krbtgt key, so that only it (with the same krbtgt key) can later verify that TGT.

KDC is a domain service, not a separate box

KDC is not an abstract 'server'; It is a service of the domain and uses Active Directory as the account database. If a user or machine is defined in the domain, the KDC can read its key from the directory. Therefore, KDC runs on every domain controller and acts as an extension of the directory.

KDC consists of two logical components but operates as a single process: Authentication Service (AS) issues a TGT to the client, while Ticket-Granting Service (TGS) issues tickets for certain services in exchange for a valid TGT. This distinction is the basis of the 'prove your identity once, then get away with a ticket' model.

KDC is a service that runs within the LSA process on the domain controller and cannot be stopped. The implication of this is practical: there is no such thing as 'closing' the DRC; it is integral to the DC's authentication function.

krbtgt: the root of trust

krbtgt is KDC's service account. The domain is created automatically when first installed and cannot be deleted or renamed; The account is assigned a random, unknown password. This password is important because the key derived from it is the key that seals every TGT in the domain.

This makes the krbtgt key the root of the domain-wide trust. Each client carries a TGT; Each TGT is sealed with the krbtgt key; Each TGS-REQ starts with the KDC verifying this TGT with the same key. So all Kerberos flow in the domain relies on the confidentiality of the krbtgt key.

The artifact of this lesson embodies just that: a Ticket [APPLICATION 1] structure; The sname field in it is krbtgt/IYELABS.EXAMPLE and the enc-part field is opaque because it is sealed with the krbtgt key. Ticket external fields (version, realm, service name) are read openly; The enc-part containing the secrets is only meaningful for the KDC who knows the krbtgt key.

Ticket enc-part and KDC response enc-part are siblings

In AS-REP, ticket [5] and the reply enc-part [6] are sibling fields. The krbtgt key protects the TGT enc-part; the client's reply key protects the reply enc-part. The ordinary password-based path uses the client long-term key, while RFC 4120 §5.4.2 also allows a key selected through pre-authentication.

These two fields are for different parties: the enc-part of the ticket is opened by the service (krbtgt in TGT) and carries the session key and authorization data; The enc-part of the response is opened by the client and securely transmits the same session key to the client. To think that the two are 'the same thing' is to misread which key protects what.

Since this lesson focuses on actors, the artifact only shows a ticket structure (ticket + its opaque enc-part); The sisterhood of the response's own enc-part and the ticket's enc-part and the full AS/TGS field structure are the subject of 06.02. The purpose here is to clarify the boundary 'enc-part of TGT belongs to the krbtgt key'.

State and data flow

1. This basic example uses the client account's password-based long-term key; the KDC can access the account's key material.
2. The client contacts AS. On a path requiring pre-authentication, the KDC verifies the proof; TGT issuance is not an identity proof independent of this condition.
3. KDC seals the enc-part of the TGT it produces with the krbtgt key; TGT's sname is krbtgt/<realm>.
4. The separate AS-REP reply enc-part is protected with the client's reply key: the long-term key in this example, or a different key selected by another mechanism.
5. When the client wants to access a service, it presents its TGT to TGS; KDC verifies TGT with key krbtgt.
6. The KDC protects the service ticket with the SPN account's key; that account may also own other SPNs.
7. The client presents the ticket. The target opens it with the SPN account's key; resource authorization remains a separate decision.
8. When accessing a different realm, the KDC generates a referral ticket with the inter-realm key derived from the trust account and transfers the flow to the KDC of the target realm.

2. Exploitation

Broken trust assumption

The mistaken assumption is that each key belongs to one service instance. A service-account key spans the SPNs and instances using that account; the krbtgt key belongs to the domain's TGT trust boundary. The phrase 'a key leaked' does not describe the same impact in both cases.

Technical prerequisites

• Obtaining the krbtgt key requires very high authority at the domain level (e.g. access to directory secrets on DC / DCSync style replication right, 05.05). So krbtgt infiltration is not a start, but typically the perpetuation of a position that has already taken over the domain.
• If a service-account key is exposed, identify the account's SPNs and instances; do not assume a single-service scope.
• For the client key, the client's password is targeted; This affects the identity of that client, but does not give it the ability to seal other principals' tickets.
• For the inter-realm key, the trust account's key is targeted; scope is the trust path between two realms, not an entire single realm.

Exploitation mechanism

Key ownership identifies the protected boundary. A service-account key concerns the ticket ciphertext and its session key. This does not imply decryption of all application traffic: subsequent protection depends on the application protocol and available messages. The krbtgt key belongs to the domain boundary protecting TGTs. Defensive assessment first identifies the key, account scope and affected message parts.

Why krbtgt is a different category

The key of an ordinary account only protects the identity of that account. krbtgt, on the other hand, has not an identity, but a seal: every TGT in the domain is sealed with its key. So knowing the krbtgt key means sharing the KDC's authority to generate/verify TGT, not impersonating a single account.

The practical consequence of this is that someone who knows the krbtgt key can generate valid-looking TGTs with whatever identity and authority claims they want; Since KDC verifies these tickets with its own krbtgt key, it cannot discriminate. This is a long-lived, domain-wide persistence limit.

So krbtgt is the root key of the domain trust, not 'one more password'. To consider it in the same risk class as a service password is to confuse the most critical limit with the most ordinary limit.

Separate the service name from account scope

Two SPNs on one account do not establish two independent key owners. Without identifying where the account is used, the incident cannot be narrowed to one host or application.

Leaking the client key gives the identity of that client. The attacker may request TGT like the client; but this is not the ability to imitate any principal. The client cannot seal other tickets because it does not know the krbtgt key.

Client, service-account and krbtgt keys have different scopes. Assess the owner, account usage and protected ticket part together; one fixed priority order does not fit every environment.

Limit: it's not a flow, it's a lesson in ownership

This lesson does not walk through a ticket generation/forge technique; The goal is to clarify which key seals which border. Concrete techniques such as golden/silver tickets are built on this ownership map and are the subject of advanced lessons.

Key ownership is not a security vulnerability per se; It is the design itself. The vulnerability arises from deficiencies in the protection of these keys (specifically krbtgt), not the mechanism itself.

Prioritize using key ownership, account usage and reachable resources. Broad boundaries such as krbtgt need special protection; a critical application account also needs assessment of its own business impact.

3. Defense & Detection

Telemetry scope

• 4768 records a TGT request result; 4769 records a service-ticket request result at the KDC. Target acceptance and resource authorization need separate evidence; 4624 is relevant only when this path creates a logon.
• Collect 4768 on the DC and read Status with PreAuthType. PreAuthType=0 denotes no pre-authentication; a successful issuance record then does not establish proof of the client secret.
• Successful 4768 typically has ServiceName=krbtgt; a failure record may use krbtgt/REALM_NAME and have a NULL ServiceSid.
• Changes to the krbtgt account itself (such as password resets) are a separate high-value signal; Since krbtgt is not routinely managed like a service account, such events are examined carefully.
• Kerberos auditing is configured with subcategories Audit Kerberos Authentication Service (4768/4771) and Audit Kerberos Service Ticket Operations (4769); If it is off, these events are not generated.

Events and relevant fields

• 4768 / TargetUserName and TargetDomainName: the requested principal and realm, not standalone pre-authentication proof.
• 4768 / ServiceName and ServiceSid identify the TGT service context. Success typically has krbtgt and its account SID; failure can have a realm-qualified name and NULL SID. Read them with Status.
• 4768 / TicketEncryptionType: Encryption type of the enc-part of the TGT (e.g. 0x12 = AES256-CTS-HMAC-SHA1-96). This value reflects the type of krbtgt key; monitored to detect downgrades.
• 4768 / PreAuthType and Status: pre-authentication type and result. Failed pre-auth (certain Status codes) are reported separately as 4771; issuance success/failure can be read here.
• 4768 / IpAddress: The source address from which the TGT request comes; It is used in abnormal location/host analysis.
• 4769 / ServiceName is the resolved account/principal, not necessarily the requested SPN string.

Separating proof of access with Issuance

First inspect the result and pre-authentication type in 4768. Do not equate a successful record with file access at a target: service-ticket issuance, target acceptance and resource authorization are separate decisions.

For example, a DC may record 4769 while FS01 denies the requested file access. Next inspect the relevant session and resource decision on FS01; TicketEncryptionType on the DC does not explain the file's DACL result.

Why is krbtgt key tracked privately?

krbtgt is not an identity, it is the seal of all TGTs in the domain. That's why events related to krbtgt (especially password/key changes) are a much heavier signal than those of an ordinary service account and are always examined with justification.

4768, where krbtgt appears as ServiceName in the trace, is normal issuance and is expected; The main attention is given to the administrative operations performed on the krbtgt account and the paths to the key of that account (directory secrets / replication rights on the DC).

A robust defense keeps root-of-trust keys (krbtgt, trust account) at the highest layer of protection. Since the scope of these keys is the entire domain/forest, protecting them takes precedence over protecting individual services.

Detection logic · KQL

// 4768: TGT request result at the DC; typical success ServiceName=krbtgt.
// Failure names may be realm-qualified. Review Status and PreAuthType separately.
SecurityEvent
| where EventID == 4768
| where TimeGenerated > ago(24h)
| summarize Count = count(), EncTypes = make_set(TicketEncryptionType) by TargetUserName, IpAddress, Status
| order by Count desc

Query assumptions

• 4768 appears only if the Audit Kerberos Authentication Service subcategory is enabled and the event is collected on a domain controller; Since KDC only operates on DC, these events come from DC logs.
• The SecurityEvent table and field names (EventID, TargetUserName, TargetDomainName, ServiceName, TicketEncryptionType, Status, IpAddress) assume an environment that collects Windows Security events; In a different schema, field names may vary.
• This summary groups request counts and TicketEncryptionType; it does not assess PreAuthType, target acceptance or resource authorization. Those require event details and target evidence.
• TicketEncryptionType values ​​are numeric codes (e.g. 0x12 AES256); Monitoring weak types (RC4 etc.) requires a separate rule and is only summarized here.
• This query was not run on a real SIEM; Field names and event meaning are based on Microsoft 4768 documentation and should be validated against the schema of the version used.

False positives

• Normal user login activity: each successful domain login can generate a 4768; A high count alone is not abnormal.
• Batch/automation accounts: scheduled tasks and services generate regular TGT demand.
• New device or VPN range: an expected IPAddress change changes the issue record but does not indicate malicious intent.
• Negative example: If the Audit Kerberos Authentication Service is turned off or DC logs are not collected, 4768 does not appear at all; Absence of record does not mean 'no authentication'. This query is a layer of visibility, not proof of access.

Hardening

• manage krbtgt key as most critical secret: do password reset (twice, waiting for replication) only with reason and plan; Don't treat krbtgt as a routine service account, because it is the root of domain-wide trust.
• Collect DC issuance and target-service records separately; matching principal names alone do not establish the same access attempt.
• Monitor TicketEncryptionType: Verify expected strong types (AES) in TGT and service tickets, look for falls to weak types such as RC4.
• Enable Audit Kerberos Authentication Service (4768/4771) and Audit Kerberos Service Ticket Operations (4769) subcategories on domain controllers and collect DC security logs centrally; Since KDC only operates in DC, these events are generated there.
• Restrict access to root-of-trust accounts such as krbtgt and trust account to Tier-0; The path to these keys (access to directory secrets / replication right on the DC) is directly monitored and minimized.
• Verification step: log in with a test user, see that event 4768 is generated on the DC with ServiceName=krbtgt and TargetUserName=<user>; then request a service ticket to a file share and observe that the flow is recorded separately as 4769, where ServiceName is the account/service principal that KDC resolves (it may not be the exact requested SPN string); Verify that 4769 is only issuance by comparing the actual acceptance with the evidence on the target side.

Read the examples

61 62 30 60 a0 03 02 01 05 a1 11 1b 0f 49 59 45
4c 41 42 53 2e 45 58 41 4d 50 4c 45 a2 24 30 22
a0 03 02 01 02 a1 1b 30 19 1b 06 6b 72 62 74 67
74 1b 0f 49 59 45 4c 41 42 53 2e 45 58 41 4d 50
4c 45 a3 20 30 1e a0 03 02 01 12 a1 03 02 01 02
a2 12 04 10 c0 ff ee 00 11 22 33 44 55 66 77 88
99 aa bb cc

Two reality checks

Assumption: A Kerberos key compromise affects a single account; krbtgt is also an account after all.

In fact: Impact depends on the key owner. A service account may span several SPNs or instances; krbtgt protects the domain's TGT boundary. Inspect account usage rather than treating a service name as the account scope.

Assumption: When a user receives a TGT (4768), it indicates that that user is accessing a server/service.

In fact: 4768 records a TGT request result at the KDC; examine Status and PreAuthType for pre-authentication context. Subsequent service-ticket issuance and target acceptance need different evidence. Ticket issuance does not establish a resource DACL grant.

Sources

• IETF · RFC 4120 — The Kerberos Network Authentication Service (V5)
  §1.1 actors and key concepts; §5.3 Ticket and EncTicketPart structure; §3.1/§3.3 AS and TGS exchanges; sealing the ticket enc-part with the service key and the KDC reply with the client key.
• Microsoft · Kerberos authentication overview
  KDC's AS+TGS components, TGT concept, krbtgt, and the KDC service running on the domain controller.
• Microsoft · Key Distribution Center
  KDC is a domain service; single process, AS and TGS; runs inside LSA on a DC and cannot be stopped; krbtgt is created automatically, cannot be deleted/renamed, and a TGT key is derived from a random password; inter-realm key from trust.
• Microsoft · 4768(S, F) A Kerberos authentication ticket (TGT) was requested
  Subcategory Audit Kerberos Authentication Service; DC only; ServiceName=krbtgt; fields TargetUserName, TargetDomainName, ServiceName, TicketEncryptionType, PreAuthType, Status, IpAddress; 4771 failed pre-auth.
• Microsoft · Service principal names
  SPN, instance and service sign-in account relationship.