Event ID 4769: Decode a Kerberos Service Ticket Request, Free in Your Browser

Kerberos sign-in runs in two exchanges. First the client obtains a ticket-granting ticket (TGT), which event 4768 records.

Then, each time the client needs a specific service, such as a file share, a database or a web application, it asks the KDC for a service ticket. RFC 4120 calls this the ticket-granting service exchange.

The client presents its TGT and a fresh authenticator that proves it holds the TGT’s session key.

The KDC answers with a KRB_TGS_REP (a ticket for the service and a new session key) or a KRB_ERROR (RFC 4120, section 3.3, read 2026-10-11).

Event 4769 is the domain controller’s record of that request, whether it succeeded or failed.

A typical workday shows one 4768 at sign-in, then many 4769 events as the user reaches shares and applications.

• Not an acceptance. A 4769 means the domain controller issued a ticket, or refused to. It does not mean the service accepted the user.
• The service decides. The target computer records its decision as a logon event such as 4624.
• One log per controller. Each domain controller logs only the requests it answered, so search each one.
• Full flow. The Kerberos explainer covers the full ticket flow.

Microsoft’s page documents two layouts. A mixed environment logs both, so this section covers both.

• Old event. Version 0, the one Windows has logged for years.
• Updated event. After the January 14, 2025 cumulative update, Windows Server 2016 and later log it, with the added fields marked “New”.

Account Name and Account Domain

Account Name is the user that requested the ticket, in the form user@DOMAIN. A computer account has a $ before the @.

Microsoft notes that this is a normalized name built from the SAM account name and the domain, not the account’s UserPrincipalName attribute. The field can be empty in some cases.

Account Domain is the Kerberos realm. It can appear as the NetBIOS name, the lowercase domain name or the uppercase domain name, so do not filter on a single spelling.

Service Name and Service ID

Service Name is “the name of the account or computer for which the service ticket was requested”. The wording matters: the target can be one of two kinds of account.

Service ID is the SID of that account, and shows NULL SID in failure events.

• Monitor pairs. If an account should never request tickets for a particular computer or service account, monitor for 4769 events that pair that Account Name with that Service ID (Microsoft’s monitoring notes).
• Service not found. Check the SPN with the SPN checker.

Logon GUID

The Logon GUID links this event, which is on a domain controller, to events on the computer the ticket was issued for. Microsoft names three:

• 4624: an account was successfully logged on.
• 4648: a logon was attempted using explicit credentials.
• 4964: special groups assigned to a new logon.

Search the target computer for the same GUID to see what the service did with the ticket.

Microsoft adds that the GUID may not be captured, in which case it shows as all zeros, {00000000-0000-0000-0000-000000000000}. The failure example in Microsoft’s RC4 article shows it that way. All zeros means “not recorded”, not “no logon”.

Client Address and Client Port

Client Address is the source of the request, in one of three formats:

• a plain IPv4 or IPv6 address;
• an IPv4 address written as ::ffff:IPv4_address (a notation, not a different machine);
• ::1 for localhost.

Client Port is 0 for local requests.

Microsoft’s monitoring notes give three checks:

• Track addresses outside your internal ranges.
• For accounts that should be used only from known addresses, alert when the address is not on the list.
• Treat ::1 as a local request, meaning the account first logged on to the domain controller itself. Alert on it for any account outside your list of accounts allowed to log on to domain controllers.

Microsoft also says to examine any 4769 with a client port above 0 and below 1024, because a well-known port was used for an outbound connection.

Ticket Options

Ticket Options is a set of ticket flags as a hexadecimal number, with bits numbered from the left as in the RFCs. Microsoft lists three common values:

• 0x40810010: Forwardable, Renewable, Canonicalize, Renewable-ok
• 0x40810000: Forwardable, Renewable, Canonicalize
• 0x60810010: Forwardable, Forwarded, Renewable, Canonicalize, Renewable-ok

The flags record what the client asked for. They are mainly useful when two requests from the same account look different.

Transited Services

Microsoft says this field “contains list of SPNs which were requested if constrained Kerberos delegation was used”. A dash means no delegation was involved.

The fields added by the 2025 update

The updated event adds four groups of fields, marked “New” on Microsoft’s page.

MSDS-SupportedEncryptionTypes is often shortened to “msds-SET”. Microsoft explains where its value comes from:

• Computer accounts get it automatically from the computer’s encryption policy.
• Domain controllers, read-only domain controllers and trusts support AES by default.
• For user accounts, gMSAs and other accounts with no value set, the domain controller uses the DefaultDomainSupportedEncType policy.

Microsoft’s RC4 article adds that this is a processed value (Microsoft Learn, read 2026-10-11):

• Windows Server 2022 and earlier. It always shows DES and RC4, for compatibility with older domain controllers.
• Windows Server 2025 and later. It shows only AES-SHA1 and stronger.
• Available Keys. It shows RC4 whether or not RC4 is used.

0x0 means the ticket was issued. Any other value is a failure, and the Ticket Encryption Type then shows 0xFFFFFFFF.

Microsoft adds that some errors are logged only when the KdcExtraLogLevel registry value on the domain controller has the right flags:

• 0x01 audits errors for service names (SPNs) that were not found;
• 0x10 logs encryption type and bad-option errors.

If you expect a 0x7 and never see one, check that value first.

0x20: expired tickets are normal noise

Microsoft’s event description says “you’ll typically see many Failure events with Failure Code 0x20, which simply means that a service ticket has expired. These are informational messages and have little to no security relevance.”

• Cause. The shorter the “Maximum lifetime for user ticket” setting, the more often it appears.
• Fix. None. Ticket renewal is automatic, so no action is needed.
• Check. Filter out 0x20 first, then read what remains.

0x25: clock skew

Microsoft says 0x25 is logged when a client sends a timestamp that differs from the server’s by more than the number of minutes in the Kerberos policy setting “Maximum tolerance for computer clock synchronization”.

• Cause. The client and server clocks differ by more than the policy allows.
• Fix. Time synchronization, not the account.
• Check. The clocks on the client, the target server and the domain controller.

0x7 and 0x1B: the service name is the problem

Both codes point at the SPN.

• 0x7. The requested name is not in Active Directory, which is what a typo, a wrong alias or a missing SPN produces.
• 0x1B. Microsoft’s code for “valid for user-to-user only”; Microsoft says it occurs because the service is missing an SPN.
• Check. Copy the Service Name from the event and check that exact string in the SPN checker.

0x12 and 0x6: the account or the name

• 0x12. The account behind the request is disabled, expired or locked out.
• 0x6. The user name does not exist at all.
• Note. Microsoft’s 4768 page notes that several 0x6 failures in a short time can indicate account enumeration. That note is about the sign-in event, and this page does not apply it to 4769.