# LDAP / Kerberos Ticket Decoder

> Decode Kerberos tickets and authentication messages, and the LDAP structures used around them.

- Page: https://decoder.tools/kerberos-ticket-decoder
- Category: Security, PKI & Crypto
- Status: live, runs in the browser
- Last reviewed: 2026-10-23

A Kerberos ticket decoder parses the ASN.1 structures of Kerberos v5 messages, such as a ticket, an AP-REQ from an `Authorization: Negotiate` header or a cached ticket file, and shows the fields that aren't encrypted: realm, service principal, encryption type and ticket flags.

## Example

An AP-REQ decodes to the service it targets and how strongly the ticket is encrypted:

```text
Kerberos AP-REQ

Ticket:
  Realm:   EXAMPLE.COM
  Service: HTTP/web.example.com
  Encryption: 18 — aes256-cts-hmac-sha1-96
```

An encryption type of 23 (rc4-hmac) is weak and enables Kerberoasting — worth flagging in a review.

## What you can and can't read

Kerberos (RFC 4120) messages are DER-encoded ASN.1. A **ticket** has a readable outer part and an encrypted inner part:

| Readable without keys | Encrypted with the service key |
|---|---|
| Realm (`EXAMPLE.COM`) | Client principal |
| Service principal name (`HTTP/web.example.com`) | Session key |
| Encryption type (`etype`) | Auth time, start, end and renew-until times |
| Key version number (`kvno`) | Authorization data (on Windows, the PAC with group SIDs) |

So without the service's keytab you can see **which service** a ticket is for and **how strongly** it's encrypted, but not who the user is or when the ticket expires.

On the web, browsers send Kerberos inside SPNEGO: `Authorization: Negotiate YII…`. The Base64 decodes to a GSS-API token wrapping an AP-REQ.

## How to use the Kerberos decoder

1. Paste a Base64 or hex Kerberos message — a ticket, an AP-REQ, or the token from an `Authorization: Negotiate` header.
2. Read the realm, service principal and encryption type. The client identity and session key are encrypted with the service key and can't be read.
3. A `Negotiate` token that wraps NTLM is detected and sent to the NTLM decoder instead.

On a host, `klist` lists your cached tickets and their encryption types:

```sh Command line
# List tickets in your cache, with encryption types
klist -e

# On Windows
klist
```

Wireshark dissects Kerberos traffic and, given a keytab, can decrypt ticket contents.

## Encryption types

| etype | Name | Status |
|---|---|---|
| 18 | aes256-cts-hmac-sha1-96 | Recommended |
| 17 | aes128-cts-hmac-sha1-96 | Acceptable |
| 23 | rc4-hmac | Weak. Enables Kerberoasting. Disable it |
| 3 | des-cbc-md5 | Broken. Disabled by default |

## FAQ

### What is Kerberoasting?

An attack where any domain user requests service tickets for accounts with SPNs, then cracks the RC4- or AES-encrypted part offline to recover the service account's password. Long random service account passwords and AES-only encryption defend against it.

### Why does a Negotiate header sometimes contain NTLM?

SPNEGO falls back to NTLM when Kerberos isn't possible, for example when connecting by IP address instead of hostname. A token starting with `TlRMTVNT` is NTLM. Use the [NTLM decoder](/ntlm-decoder).

### Where does LDAP fit in?

In Active Directory, LDAP stores the accounts and SPNs that Kerberos tickets are issued for, and LDAP binds are often authenticated with Kerberos (SASL/GSSAPI). Both protocols use ASN.1 BER encoding.