SPN and service key: Which identity owns the requested service?

1. Core mechanism

In the TGS exchange, the client (WS01), the domain controller in the KDC role (DC01) and the directory. The requested service is carried as a PrincipalName in the sname field of the KDC-REQ-BODY in the TGS-REQ. KDC resolves this name to an account in the directory via the servicePrincipalName attribute and protects the enc-part of the service ticket with that account's long-term key (key usage 2). The boundary of this lesson is name→account→keychain: the full AS/TGS flow is at 06.02, the pre-authentication and etype detail is at 06.04, and the PAC carried by the ticket is at 06.05.

Interfaces and specifications

• RFC 4120 §5.2.2: PrincipalName ::= SEQUENCE { name-type [0] Int32, name-string [1] SEQUENCE OF KerberosString }.
• RFC 4120 §6.2: name-type NT-PRINCIPAL (1) and NT-SRV-INST (2); sname mostly names the service instance with type NT-SRV-INST.
• RFC 4120 §7.5.1 key usage 2: ticket enc-part is protected by the service key; this is the key to the account from which the sname was resolved.
• RFC 4120 §7.5.9 error codes: KDC_ERR_S_PRINCIPAL_UNKNOWN (7) unknown SPN, KDC_ERR_PRINCIPAL_NOT_UNIQUE (8) same SPN found in more than one account.
• SPN syntax: <service class>/<host>:<port>/<service name>; The first two components are mandatory, port and service name are optional (Microsoft, Name Formats for Unique SPNs).
• Windows Security channel: 4769 / ServiceName, ServiceSid, TicketEncryptionType fields; only on domain controller.

SPN is an identity indicator, not an address

When the tunahan user accesses the SQL instance on \\db01\, the client carries the value sname = MSSQLSvc/db01.outreason.example:1433 in the req-body of the TGS-REQ. The KDC does not look at the target host's IP or network location when resolving this name; searches the directory for the account that hosts this SPN in the servicePrincipalName attribute.

The account found is the critical one: the service ticket enc-part is encrypted with that account’s long-term key. A user-account key may be based on a human-chosen password. Windows manages the machine-account secret and its rollover follows machine-account password policy; Windows generates and manages a gMSA password, with a 30-day default interval that can be changed at account creation. These controls reduce offline password-guessing risk; account type alone is not a safety guarantee.

This distinction is the core of the course. You can also keep the SPN for the same SQL service registered in a user account named svc_mssql or a machine account named MSSQL01$; Both give the same client experience, but the nature of the secret protecting the key to the ticket is completely different.

What do the components of SPN say?

SPN has a four-component syntax: <service class>/<host>:<port>/<service name>. service class specifies the type of service (e.g. MSSQLSvc, HTTP, cifs, ldap). host is the FQDN or NetBIOS name of the machine on which the service is running. The port distinguishes multiple instances of the same class on the same host and is skipped for services running on the default port.

At the Kerberos level, this SPN is encoded as a PrincipalName in the sname field. MSSQLSvc/db01.outreason.example:1433 in the example is divided into two components in the name-string array: the first component is service class (MSSQLSvc), the second component is host:port (db01.outreason.example:1433). name-type is usually NT-SRV-INST (2).

An SPN must be unique in the forest. Microsoft's documentation says this clearly: If the SPN is not unique, authentication will fail. Uniqueness is provided by service class, host and port when necessary.

-- sname inside the TGS-REQ req-body (RFC 4120 5.2.2)
sname  PrincipalName ::= SEQUENCE {
        name-type    [0] Int32           = 2,   -- NT-SRV-INST
        name-string  [1] SEQUENCE OF KerberosString {
              "MSSQLSvc",                        -- service class
              "db01.outreason.example:1433"          -- host:port
        }
}
-- The KDC looks up this name in the servicePrincipalName attribute;
-- the long-term key of the account found protects the ticket enc-part (key usage 2).

Alias, unknown and duplicate SPN cases

An account can carry more than one SPN; servicePrincipalName is a multi-valued attribute. Different spellings such as MSSQLSvc/db01 and MSSQLSvc/db01.outreason.example:1433 may be registered as aliases to the same account. No matter what spelling the client requests, KDC resolves the same calculation and generates a ticket protected by the same key. Alias ​​does not change key ownership.

If the requested SPN is not registered in any account in the directory, KDC returns KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7). This does not mean "no service" but rather "no principal registered with this name found"; SPN typo also produces the same error.

If the same SPN is accidentally registered in two separate accounts, the uniqueness rule is broken. In this case, the KDC cannot determine exactly which key to use, causing authentication errors that result in KDC_ERR_PRINCIPAL_NOT_UNIQUE (0x8) or unverifiable tickets. Duplicate SPN often occurs as a result of manually porting an SPN or installing the same service on two accounts.

Why is the quality of the service key important?

When generating the enc-part of the service ticket, the KDC uses the currently valid key version of the target account and writes kvno in the outer field of the ticket. When the service receives this ticket, it reads from this kvno which key version it is encrypted with; If the version is not available, KRB_AP_ERR_BADKEYVER as seen in 06.02 is returned.

How the key is created determines offline risk. For an SPN registered to a user account, the key is derived from a human-chosen password with string-to-key. Windows manages the machine-account secret, and its rollover is controlled by machine-account password policy. Windows generates and manages a gMSA password; its default change interval is 30 days, though a different interval can be selected when the account is created.

So "Where is the SPN registered?" The question is a security question. If the SPN is in a user account, each ticket protected by that account's key is protected by the strength of that password.

Does the registered account match the running service?

Suppose cifs/files.example.test is registered to svc-files-A while the service runs as svc-files-B. The KDC can issue a ticket using A’s key; issuance does not establish that B’s loaded key can open it. Address resolution, finding the SPN owner and loading the acceptor key are different checks. This example shows that mismatch without assigning a universal native error code.

In a second case, the account name matches but the service may have an older loaded key. Windows-managed gMSA password rotation is not an observation of the key currently used by every service instance. In a third case, first-hop keys match; the identity and permission used for a second service remain separate delegation decisions. Follow account management in 08.04 and the second-hop boundary in 06.06.

State and data flow

1. The client wants to access the target service and creates the SPN of that service: MSSQLSvc/db01.outreason.example:1433.
2. Client prepares TGS-REQ; Writes this SPN as PrincipalName in the sname field of the req-body (NT-SRV-INST).
3. After the KDC verifies the TGT, it resolves the sname to an account in the directory via the servicePrincipalName attribute.
4. If SPN is not found KDC_ERR_S_PRINCIPAL_UNKNOWN (7); if the same SPN is in more than one account, uniqueness is broken (KDC_ERR_PRINCIPAL_NOT_UNIQUE, 8).
5. If the SPN resolves to a single account, the KDC generates a new session key and encrypts the enc-part of the service ticket with that account's long-term key (key usage 2).
6. DC01 produces 4769 at this point; The ServiceName field names the account from which the ticket was issued.
7. The client receives the ticket but cannot open it; Only the service that has the key to the target account can resolve the enc-part.

2. Exploitation

Broken trust assumption

Broken assumption: "SPN is just a tag that tells me which service I want to go to." In effect, the SPN names the owner of the key that protects the encrypted portion of the service ticket. Since any authenticated account can request a ticket for any registered SPN with a valid TGT, the attacker obtains a ciphertext generated with the target account's key without ever touching the target. If the key to that account is based on a human-chosen password, ciphertext is open to offline password challenge.

Technical prerequisites

• Any authenticated account in the Domain and a valid TGT; no privileged membership required.
• Reachability to the KDC over Kerberos. RFC 4120 defines UDP/IP and TCP/IP transports; the default port is 88, while the transport selected by the client/KDC discovery depends on environment configuration.
• An SPN registered to a user account can be a higher-priority offline-guessing target. The OS manages machine-account secrets and Windows manages gMSA passwords; these are harder to guess than human-chosen passwords. Still assess rollover policy, hosts authorized to retrieve a gMSA password, and account configuration.
• The target account's key is based on a guessable password; Otherwise, testing on the resulting ciphertext will not yield meaningful results.
• If the target account is willing to issue a ticket with a weak etype like RC4, it makes the attempt cheaper; A configuration that only accepts AES makes the job significantly more difficult.

Exploitation mechanism

The mechanism is not a protocol vulnerability, but the result of the SPN→key relationship. The client sets the sname to the desired SPN; KDC resolves this to a user account and encrypts the enc-part of the service ticket with that account's long-term key, under key usage 2. This ciphertext can be obtained from the network; Since the sname field is not encrypted, it is clear which account it belongs to. The attacker tries password candidates offline; It checks whether the ciphertext provides integrity control with the key derived for each candidate. Once the right candidate is found, the key to the target account is obtained, and thus the opportunity to assume the identity of that account. This is the core of the technique known as Kerberoasting and it doesn't break a single rule; What's being violated is the "service account password can be chosen by human" assumption.

SPN request is not an authorization check

The KDC does not look at the source DACL of the target service when generating a ticket; nor can it, because the access decision is made on the host hosting the resource. So being able to buy a ticket for an SPN is not the same as being able to access that service. What the attacker wants is not access anyway; is a ciphertext based on the target account's key material.

The demand generates 4769 on DC; The target service will not be notified of this request. Therefore, in telemetry, the point of observation is the KDC, not the source host.

A sudden increase in the number of tickets issued for an account is not, by itself, evidence of an attack. The significant signal is weak etype ticket requests for SPNs registered to user accounts.

Which account type is the target

SPNs registered to the user account are the primary target; because the password for these accounts is often set once and not returned for years. Older application installations may have registered MSSQLSvc, HTTP, or similar SPNs in ordinary user accounts.

OS-managed machine-account secrets and Windows-managed gMSA passwords greatly reduce ordinary password-guessing risk compared with human-chosen service-account passwords. Account type alone does not mean no risk. Host security, gMSA password-retrieval permissions, rollover policy and account configuration require separate review.

The impact is limited to the scope of the compromised service account. "Service account compromised" alone does not mean that the domain is down; The account's memberships, registered SPNs and object rights on it are evaluated separately.

The risk boundary of this example

Writing an SPN is not equivalent to changing the service process identity or every delegation permission. Bound the effect by the actual registration, key and hop.

3. Defense & Detection

Telemetry scope

• The Audit Kerberos Service Ticket Operations subcategory produces Success: 4769 records. For the Kerberoasting signal, this category must be turned on.
• 4769 occurs only on the domain controller; no object SACL required, this is a KDC transaction record.
• 4769 volume is high; Each normal service access produces a record. If the basis for filtering, storing and normal behavior is not planned in advance, the signal will be lost in the noise.
• The SPN inventory is a separate data source: the question of which SPN is registered to which account is extracted from the index (servicePrincipalName) and evaluated together with 4769.
• The actual access on the source side is read from the session and object access records on the target host, not from 4769 on the DC.

Events and relevant fields

• 4769 / ServiceName: the name of the account to which the ticket was issued; it is not the full requested SPN. A trailing $ often points to a computer/gMSA-style managed account, but confirm the account type against directory inventory. A plain name makes an ordinary user service account more likely; it does not prove how its password was chosen.
• 4769 / ServiceSid: SID of the target account; NULL SID may be seen in failed records.
• 4769 / TargetUserName: client requesting the ticket, in normalized UPN format.
• 4769 / TicketEncryptionType: etype of the issued ticket, i.e. the algorithm of the section protected by the service key. 0x17 = RC4-HMAC (weak, makes offline testing cheaper), 0x12 = AES256-CTS-HMAC-SHA1-96.
• 4769 / TicketOptions: requested ticket flags; hexadecimal
• 4769 / Status: the KDC result in Windows audit telemetry; 0x0 is success. An unknown SPN can produce a protocol KRB-ERROR / KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7). That response and a failure 4769 are separate observations: unknown-SPN logging also depends on Audit SPN unknown errors (0x01) in KdcExtraLogLevel. An absent event does not prove an absent request.
• 4769 / IpAddress: address of the client requesting the ticket; used to associate multiple different user-SPN requests from a single source.

The ServiceName field reveals the type

ServiceName in event 4769 is the name of the account to which the ticket was issued, not the full requested SPN. A trailing $ often suggests a computer or managed-service account; it is a first clue, not definitive classification, so confirm with directory inventory. A plain account name makes an ordinary user service account more likely; it does not by itself prove that the password was human-chosen.

So ServiceName and TicketEncryptionType should be read together. The user account + RC4 combination is the telemetry equivalent of both the goal and the cheapness of the offline trial.

A single 4769 record does not indicate that access occurred; It indicates that only one ticket has been issued. In Kerberoasting, the attacker aims to collect ciphertext, not to access it.

Validation after the change

Compare the requested SPN, registered principal, running service identity and loaded key epoch. Do not substitute 4769 issuance evidence for AP acceptance or second-hop success.

Detection logic · KQL

// Kullanici hesaplarina kayitli SPN'ler icin RC4 ile service ticket talepleri.
// Tek basina kanit degildir; SPN envanteri ve normal davranis temeli ile birlikte degerlendirilir.
SecurityEvent
| where EventID == 4769
| where Status == "0x0"
| where TicketEncryptionType == "0x17"                 // RC4-HMAC
| where ServiceName !endswith "$"                       // makine hesaplarini disla
| where ServiceName !startswith "krbtgt"
| summarize Requests = count(), Services = make_set(ServiceName, 50)
          by TargetUserName, IpAddress, bin(TimeGenerated, 1h)
| where array_length(Services) >= 3                     // esik ortam temeline gore ayarlanir

Query assumptions

• The table is the SecurityEvent table in Microsoft Sentinel / Log Analytics; field names reflect the EventData names in the Windows Security channel. If a different ingest scheme (e.g. ASIM or raw WEF) is used, field mapping must be done separately.
• TicketEncryptionType and Status are stored as text ("0x17", "0x0") in this scheme; In a backend that stores numbers, the comparison type must be adapted.
• The threshold (array_length >= 3) and time window (1 hour) are set based on the environment; It is not a fixed value.
• Machine account and krbtgt filters reduce noise but exclude SPNs registered to machine accounts; This is a conscious narrowing.
• This query was not run in an actual Sentinel workspace in this session; only domain names and event semantics were verified against the primary source.

False positives

• In legacy environments where RC4 is still enabled, legitimate clients also receive tickets with RC4; etype by itself does not indicate bad faith.
• Application servers connecting to many backend services quickly request tickets to many different SPNs.
• Backup, inventory, and monitoring agents can produce similar patterns.
• Negative example: if the target account's key is already obtained, the attacker does not need to request a new ticket and this query will see nothing. A query is a scope limit, not a proof.

Hardening

• First inventory: which SPN is registered in which account? Extracts SPNs registered to user accounts via servicePrincipalName; These are the primary risks.
• Where possible, move service SPNs from user accounts to gMSAs. Windows generates and manages the gMSA password; the default change interval is 30 days and can be set at creation. Restrict which hosts can retrieve it; this management lowers offline-guessing risk but does not replace host security.
• Enforce long, random passwords on non-portable service accounts and rotate them regularly; Password length increases string-to-key cost.
• Gradually harden Etype policy: measure TicketEncryptionType distribution first, detect RC4 dependencies, switch to AES in pilot scope, keep fallback ready.
• Purge unused and duplicate SPN records; A ticket cannot be generated for an unregistered SPN, and a duplicate SPN will cause authentication errors.
• Verification step: repeat the same workflow after the change and see that the TicketEncryptionType value for the target SPN in the 4769 records has changed to AES and Status remains 0x0.

Read the examples

30 49 a2 13 1b 11 4f 55 54 52 45 41 53 4f 4e 2e
45 58 41 4d 50 4c 45 a3 32 30 30 a0 03 02 01 02
a1 29 30 27 1b 08 4d 53 53 51 4c 53 76 63 1b 1b
64 62 30 31 2e 6f 75 74 72 65 61 73 6f 6e 2e 65
78 61 6d 70 6c 65 3a 31 34 33 33

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4769</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14337</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:02.5510000Z" />
    <EventRecordID>20714</EventRecordID>
    <Correlation />
    <Execution ProcessID="712" ThreadID="980" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan@OUTREASON.EXAMPLE</Data>
    <Data Name="TargetDomainName">OUTREASON.EXAMPLE</Data>
    <Data Name="ServiceName">svc_mssql</Data>
    <Data Name="ServiceSid">S-1-5-21-111111111-222222222-333333333-2604</Data>
    <Data Name="TicketOptions">0x40810000</Data>
    <Data Name="TicketEncryptionType">0x17</Data>
    <Data Name="IpAddress">::ffff:192.0.2.44</Data>
    <Data Name="IpPort">52190</Data>
    <Data Name="Status">0x0</Data>
    <Data Name="LogonGuid">{7b2e0a41-6c33-4d9a-8f11-2a90c5e7b401}</Data>
    <Data Name="TransmittedServices">-</Data>
  </EventData>
</Event>

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E02",
  "requestedSPN": "HTTP/app.example.test",
  "registeredAccount": "svc-A",
  "runningIdentity": "svc-B",
  "issuerResult": "ticket-issued",
  "acceptorResult": "key-mismatch-model",
  "secondHop": "not-attempted"
}

Two reality checks

Assumption: SPN is just an address that tells which server the client wants to go to; It has nothing to do with security.

In fact: The SPN names the owner of the key that protects the enc-part of the service ticket. KDC resolves the sname to an account in the servicePrincipalName attribute (RFC 4120 §5.2.2/§6.2) and encrypts the ticket with that account's long-term key under key usage 2 (§7.5.1). If the SPN is registered to a user account, this key is derived from a human-chosen password and the resulting ciphertext is available for offline testing (Kerberoasting). So where the SPN is registered is a direct security question.

Assumption: Saving the same SPN on two accounts provides redundancy and is harmless at worst.

In fact: The SPN must be unique in the forest; otherwise, authentication fails (Microsoft, Name Formats for Unique SPNs). Modern AD enforces this at write time: In Windows Server 2012 R2 and later, a write processed by a DC that attempts to add/modify (including restore, reanimation, rename) an SPN that already exists in the forest is blocked with ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (0x21C7), generating event 2974 in Directory Services; setspn.exe also checks for duplicates. This is why duplicate SPN writing is not routinely successful. However, duplicates can occur in legacy/edge cases: records created before enforcement, an older DC handling the write, or multi-master replication conflicts. If such a duplicate exists, KDC cannot determine exactly which account's key to use and errors resulting in KDC_ERR_PRINCIPAL_NOT_UNIQUE (0x8) or unverifiable tickets will occur. Duplicate SPN is not redundancy but a source of interruptions that are hard to diagnose; The solution is to keep the SPN in a single account.

Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.2.2 PrincipalName (name-type/name-string), §6.2 principal name types (NT-PRINCIPAL 1, NT-SRV-INST 2), §7.5.1 key usage 2 (ticket enc-part service key), §7.5.9 error codes KDC_ERR_S_PRINCIPAL_UNKNOWN 7 and KDC_ERR_PRINCIPAL_NOT_UNIQUE 8. §7.2 UDP/IP, TCP/IP, and default port 88.
• Microsoft · Name Formats for Unique SPNs
  SPN syntax <service class>/<host>:<port>/<service name>; required and optional components; the SPN must be unique in the forest or authentication fails; host-based and replicable service distinction.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Subcategory Audit Kerberos Service Ticket Operations; Task 14337; Version 0 Event XML and Field Descriptions (ServiceName, ServiceSid, TargetUserName, TicketEncryptionType, TicketOptions, Status); etype table 0x12 and 0x17.
• Microsoft · SPN and UPN uniqueness
  Windows Server 2012 R2 (and later) DCs block duplicate SPN/UPN writes (including restore/reanimation/rename); the block occurs only if the write is processed by a 2012 R2 DC; ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (0x21C7) and Directory Services event 2974; setspn.exe (Server 2008) duplicate check.
• Microsoft · Service Accounts in Windows Server
  Traditional service account vs gMSA password management; gMSA password is generated/managed by Windows, authorized hosts retrieve it, default rotation interval 30 days and configurable at creation.
• Microsoft · Domain member: Maximum machine account password age
  Policy controls maximum age/rollover behavior of computer account passwords; machine-account password lifecycle is policy-dependent.
• RFC 4120 — Kerberos V5
  §3.2.1–3.2.3 AP exchange
• gMSA overview
  Overview, managed password/KDS and platform requirements
• MS-SFU overview
  §1.3 Overview
• Microsoft Learn · KDC registry configuration
  KdcExtraLogLevel 0x01: unknown-SPN failure logging; separate protocol result and audit visibility.