{
	"id": "7b48861f-25a0-442f-8f1e-a72bedbbac27",
	"created_at": "2026-04-06T00:22:38.398785Z",
	"updated_at": "2026-04-10T03:20:19.069712Z",
	"deleted_at": null,
	"sha1_hash": "17d5b291196b4a7c284c99418defca444a9c9bce",
	"title": "Kerberos, Active Directory’s Secret Decoder Ring",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 106096,
	"plain_text": "Kerberos, Active Directory’s Secret Decoder Ring\r\nBy Sean Metcalf\r\nPublished: 2014-09-12 · Archived: 2026-04-05 13:00:53 UTC\r\nKerberos Overview\r\nKerberos is a protocol with roots in MIT named after the three-headed dog, Cerberus. Named because there are 3\r\nparties: the client, the resource server, and a 3rd party (the Key Distribution Center, KDC).\r\nKerberos can be a difficult authentication protocol to describe, so I will attempt to simplify it as best as possible.\r\nKerberos authentication leverages long-term asymmetric keys (public key) and short-term symmetric keys\r\n(session keys).\r\nAsymmetric key cryptography uses two mathematically connected keys where one key is used to encrypt and the\r\nother is used to decrypt data. This is most commonly used in Public Key encryption (PKI) where one of the keys\r\nis kept secret by the user or service (Private Key) and the other key is available to anyone who wants it (Public\r\nKey). In this manner a user can sign (encrypt a hash with the private key) data to ensure it originated from that\r\nuser without modification (the receiver decrypts the hash with the public key). Also a person can use the user’s\r\npublic key to encrypt data so that only the user can decrypt it with the user’s private key.\r\nSymmetric key cryptography uses one key to encrypt and the same to decrypt the data. This is also referred to as a\r\nshared secret.\r\nSince asymmetric key cryptography is more processor intensive, it is typically only used to encrypt session keys\r\nwhich use symmetric keys (shared secret).\r\nActive Directory implements Kerberos version 5 in two components: the Authentication service and the Ticket-granting service.\r\nThe Authentication Service (AS) is the first contact the client has with Kerberos and is used to lookup the user’s\r\npassword and create the Ticket Granting Ticket (TGT). The AS also creates the session key the user will use for\r\nfuture communication with Kerberos.\r\nThe Ticket Granting Ticket (TGT) is the Kerberos ticket for the Ticket Granting Service (runs on the KDC) and is\r\nencrypted using the KDC key (KRBTGT domain Kerberos account), meaning that only a KDC can decrypt and\r\nread the ticket. While the user’s ticket ,the TGT, is set to expire after 10 hours (AD default), it can be renewed as\r\noften as needed during the TGT renewable lifetime which is 7 days (AD default). Once the authenticating user has\r\na TGT, it presents the TGT to the KDC to get a Service Ticket for the Ticket Granting Service (TGS) on the KDC.\r\nMost key Kerberos communication occurs over UDP port 88, though starting with Windows Vista \u0026 Windows\r\nServer 2008 now default to using TCP for Kerberos ticket requests.\r\nhttps://adsecurity.org/?p=227\r\nPage 1 of 10\n\nThere is a myth in the Windows Kerberos world that if a workstation’s clock is skewed more than 5 minutes from\r\nthat of the Domain Controller, Kerberos authentication wouldn’t work.\r\nTechnically, all clocks in the Kerberos world must be kept closely in-sync to prevent replay attacks. By default,\r\nMicrosoft Active Directory has a tolerance of 5 minutes. Though in most cases, this doesn’t mater. When a\r\nclient sends a Kerberos request to a DC, the DC will reply with a “KRB_ERROR – KRB_AP_ERR_SKEW\r\n(37)” and the Windows client will update its time for the Kerberos session with the DC and resend the\r\nrequest. Provided the clock skew between the client and DC is not more than the ticket lifetime (10 hours by\r\ndefault), the second request will be successful.\r\nKerberized Internet Negotiation of Keys (KINK) RFC 4430 details how this works:\r\nIf the server clock and the client clock are off by more than the policy-determined clock skew limit\r\n(usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW.  The optional client’s time in\r\nthe KRB-ERROR SHOULD be filled out.  If the server protects the error by adding the Cksum\r\nfield and returning the correct client’s time, the client SHOULD compute the difference (in\r\nseconds) between the two clocks based upon the client and server time contained in the KRB-ERROR message.  The client SHOULD store this clock difference and use it to adjust its clock in\r\nsubsequent messages.  If the error is not protected, the client MUST NOT use the difference to adjust\r\nsubsequent messages, because doing so would allow an attacker to construct authenticators that can be\r\nused to mount replay attacks.\r\nKB956627 also describes this behavior.\r\nConfused yet?\r\nKeep reading, it gets easier…\r\nEvery service that is Kerberos enabled has an entry point called a Service Principal Name (SPN) and each\r\nKerberos user has a User Principal Name (UPN). For example, a user named Joe User in the ADSECURITY.ORG\r\nKerberos realm aka AD domain (the Kerberos realm is always all Caps) has a UPN of JoeUser@ADSecurity.org.\r\nIf Joe User initiates a connection to the share path \\\\server1.ADSecurity.org\\Shared then Joe’s workstation will\r\nlookup the computer server1.ADSecurity.org in Active Directory and read its SPN attribute\r\n(cifs/server1.ADSecurity.org). The computer SPN is used to identify the application server in the Kerberos TGS\r\nticket request. Furthermore, when Joe opens Outlook, his workstation performs similar actions looking up the\r\nExchange server’s SPN.\r\nExchange 2010 has a number of registered SPNs; here are a few of them used as part of a client connection (using\r\nOutlook 2010):\r\nexchangeMDB\r\nexchangeRFR\r\nexchangeAB\r\nHTTP\r\nKERBEROS METAPHOR\r\nAs mentioned earlier, Kerberos has 3 components, the client, the server, and the KDC (trusted 3rd party). The\r\nprocess is similar to when you travel to a foreign country.\r\nhttps://adsecurity.org/?p=227\r\nPage 2 of 10\n\n1. You visit the local passport office with a birth certificate\r\n(get the Ticket Granting Ticket ticket from the KDC)\r\n2. You request an entrance Visa for your passport in order to enter the country\r\n(get the Ticket Granting Service ticket from the KDC – ok, so you would get the Visa from the country’s\r\nembassy, but you still need the passport and something authoritative the country’s immigration guard will\r\naccept).\r\n3. You travel to the country with the passport and the country’s entrance Visa\r\n(present authoritative documentation to gain access to the resource server).\r\nKERBEROS TICKET PROCESS OVERVIEW\r\nTicket Granting Ticket (aka logon ticket)\r\n1. Joe User logs on with his Active Directory user name and password to a domain-joined computer (usually a\r\nworkstation). The computer takes the user’s password and runs a one way function (OWF) creating a hash of the\r\npassword (typically the NTLM hash). Hashing the password is like taking a steak and running it through a meat\r\ngrinder. The ground beef that is the result can never be reassembled back into the same steak we started with.\r\nThis is used to  handle all Kerberos requests for the user (as well as other authentication methods such as NTLM).\r\n2. Kerberos authentication is initiated by sending a timestamp (PREAUTH data) encrypted with the user’s\r\npassword-based encryption key (password NTLM hash).\r\n3. The user account (JoeUser@adsecurity.org) requests a Kerberos service ticket (TGT) with PREAUTH data\r\n(Kerberos Authentication Service Request or AS-REQ).\r\n4. The Domain Controller’s Kerberos service (KDC) receives the authentication request, validates the data, and\r\nreplies with a TGT (Kerberos AS-REP). The TGT has a Privileged Attribute Certificate (PAC) which contains all\r\nthe security groups in which the user is a member. The TGT is encrypted and signed by the KDC service account\r\n(KRBTGT) and only the domain KRBTGT account can read the data in the TGT.\r\nAt this point, the user has a valid TGT which contains the users group membership and is used to prove the user is\r\nwho they claim to be in further conversations with a Domain Controller (KDC). The TGT is sent to the Domain\r\nController every time a resource ticket is requested.\r\nTicket Granting Service ticket (aka resource access ticket)\r\n5. When the user wants to access an AD resource (a file share for example), the user’s TGT from step 4 is\r\npresented to a Domain Controller (KDC) as proof of identity with a request for a resource ticket to a specific\r\nresource (Service Principal Name). The DC determines if the TGT is valid by checking the TGT’s signature and if\r\nvalid, generates a resource access ticket (TGS) signed/encrypted with the KRBTGT account and a part encrypted\r\nwith the Kerberos service account’s session key which the destination service uses to validate the TGS.\r\nNote: The DC doesn’t validate the user has the appropriate access to the service, it only validates the TGT and\r\nbuilds a TGS based on the TGT information.\r\n6. The resource service ticket (TGS) is sent to the user by the Domain Controller and is used for authentication to\r\nthe resource. At this point, all communication has been between the user’s computer and the Domain Controller\r\nhttps://adsecurity.org/?p=227\r\nPage 3 of 10\n\n(KDC).\r\n7. The user’s computer sends the user’s resource service ticket (TGS) to the service on the resource computer. If\r\nthe destination service is a file share, the TGS is presented to the CIFS service for access.\r\n8. The destination service (CIFS in this example) validates the TGS by ensuring it can decrypt the TGS\r\ncomponent encrypted with the service’s session key. The service may send the TGS to a DC (KDC) to validate the\r\nPAC to ensure the user’s group membership presented is accurate. The service reviews the user’s group\r\nmembership to determine what level of access, if any, the user has to the resource.\r\nTHE DETAILED PROCESS\r\nHere’s my example scenario to explain what occurs when a user logs on and opens Outlook to view his Exchange\r\nemail. The bold text is the simple overview version while the detail follows.\r\n1. A user logs onto the domain ADSecurity.org on the workstation ADSecurityPC.\r\n2. The user requests authentication by sending a timestamp encrypted with the users password\r\nencryption key.\r\nThe workstation creates an encryption key derived from the user’s password (the user’s password is hashed\r\nusing a one way function such as MD5 = (A) key) to encrypt a timestamp (date/time) as an authenticator\r\n(pre-authentication is required by AD in its default configuration, so the client must send an authenticator) .\r\nThe authenticator is simply a method the client uses to prove to the KDC that the user is who he claims to\r\nbe (since only the user \u0026 the KDC knows his password) and protects against replay attacks. This\r\ninformation is sent to the KDC in an AS-REQ (Authentication Service Request) packet. This request\r\nincludes the client supported encryption algorithms.Keys used:\r\n(A)User’s password derived key\r\nPacket Data:\r\nUser account (user@ADSecurity.org) requests Kerberos service ticket (TGT) with PREAUTH\r\ndataKRB5: Kerberos AS-REQ\r\n1 Forwardable: FORWARDABLE tickets are allowed/requested\r\n1 Renewable: This ticket is RENEWABLE\r\n1 Canonicalize: This is a request for a CANONICALIZED ticket\r\n1 Renewable OK: We accept RENEWED ticketsClient Name (Principal): admin\r\nRealm: ADSECURITY.ORG\r\nhttps://adsecurity.org/?p=227\r\nPage 4 of 10\n\nService: krbtgt/ADSecurity.org\r\ntill: 2037-09-12 02:48:05 (UTC)\r\nrtime: 2037-09-12 02:48:05 (UTC)\r\nNonce: 1976014234\r\nPrincipal Name: user\r\nHostAddress: METCORPORGDC02\u003c20\u003e\r\nPAC_Request: True\r\nEncryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac rc4-hmac-exp rc4-hmac-old-exp des-cbc-md5KRB5: Kerberos AS-REP\r\nClient Name (Principal): user\r\nTkt-vno: 5\r\n3. The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a\r\nTGT.\r\nThe KDC receives the AS-REQ, decrypts the authenticator (encrypted with key (A)), and validates the\r\ntimestamp is within the time skew limits set by the domain (5 minutes by default). If the KDC is satisfied\r\nthe request is a valid user request, the KDC responds with an AS-REP packet which includes the TGT. The\r\nTGT can only be decrypted by a KDC (using the (B) key) and is used to authenticate the user to the\r\nKerberos server so it doesn’t have to look up the user’s password (long-term key) again. The KDC also\r\nincludes a session key ((C)key) for use in future communication with the KC.Keys used:\r\n(B) Kerberos account’s password derived key\r\n(C)User’s Kerberos service (KDC) session key NOTE: The TGT is encrypted with the KRBTGT account\r\npassword so only a valid Kerberos server can decrypt it. In an environment with RODCs, each RODC has\r\nits own krbtgt account with a unique password. This means that if a user presents a TGT received from a\r\nRODC to a writable DC, the DC dumps the TGT and generates a new one.\r\nPacket Data:\r\nThe KDC replies with the TGT and session key\r\nKRB5: Kerberos AS-REP\r\nClient Name (Principal): User\r\nTicket (Tkt-vno): 5\r\nhttps://adsecurity.org/?p=227\r\nPage 5 of 10\n\nRealm: ADSECURITY.ORG\r\nServer Name: krbtgt/ADSecurity.org\r\nenc-part aes256-cts-hmac-sha1-96\r\n[Encrypted Key]\r\nenc-part rc4-hmac\r\n[Encrypted Key]\r\n4. The user opens Outlook which locates the user’s mailbox server and requests a TGS ticket for access.\r\nThe workstation locates the Exchange mailbox server containing the user’s mailbox\r\n(MetcorpEXMB02.ADSecurity.org) and reads the ServicePrincipalName attribute on the computer account\r\nin AD (ExchangeMDB/ADSecurityEXMB02.ADSecurity.org – there are a bunch, so I will just use this one\r\nfor the example).\r\nThe client then sends a TGS-REQ to the KDC requesting a TGS for access to the Exchange service running\r\non the MetcorpEXMB02 Exchange server. The TGS request includes the target server SPN, the user’s TGT\r\n(encrypted with the (B) key), and an authenticator (encrypted with the (C)key).Keys used:\r\n(B) Kerberos account’s password derived key\r\n(C)User’s Kerberos service (KDC) session key\r\nPacket Data:\r\nUser account requests service ticket (TGS) for MetcorpEXMB02 Exchange service access\r\nKRB5: Kerberos TGS-REQ\r\n1 Forwardable: FORWARDABLE tickets are allowed/requested\r\n1 Renewable: This ticket is RENEWABLE\r\n1 Canonicalize: This is a request for a CANONICALIZED ticket\r\nRealm: ADSECURITY.ORG\r\nServer Name: ExchangeMDB/MetcorpEXMB02.ADSecurity.org\r\ntill: 2037-09-12 02:48:05 (UTC)\r\nNonce: 1976014234\r\nhttps://adsecurity.org/?p=227\r\nPage 6 of 10\n\nEncryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac rc4-hmac-exp rc4-hmac-old-exp des-cbc-md5KRB5: Kerberos AS-REP\r\n5. The KDC validates the TGS request and replies with the TGS.\r\nThe KDC replies with a TGS-REP packet to the client which includes 2 session tickets (TGS) (2?). One of\r\nthe session tickets is encrypted with the user’s (KDC) session key ((C) key) and the second one is\r\nencrypted with the target server’s (KDC) session key ((D) key). The second TGS also includes the user’s\r\ngroup membership \u0026 associated SIDs which provides the server information used to determine\r\nauthorization and help the server determine: Is the user allowed to access the server’s resource?\r\nBoth session tickets include a new session key ((E)key) for exclusive use in communication between the\r\nExchange server and the user.Keys used:\r\n(C) User’s Kerberos service (KDC) session key\r\n(D) Server’s Kerberos service (KDC) session key\r\n(E)User-Exchange service session key\r\nPacket Data:\r\nThe KDC replies with the service ticket (TGS) for MetcorpEXMB02 Exchange service access\r\nKRB5: Kerberos TGS-REP\r\nClient Name (Principal): User\r\nTicket (Tkt-vno): 5\r\nRealm: ADSECURITY.ORG\r\nServer Name: krbtgt/ADSecurity.org\r\nenc-part aes256-cts-hmac-sha1-96\r\n[Encrypted Key]\r\nenc-part rc4-hmac\r\n[Encrypted Key]\r\n6. The client authenticates to the Exchange server with the session ticket.\r\nThe client sends the target server (MetcorpEXMB02.ADSecurity.org) an AP-REQ packet containing the\r\nTGS it received from the KDC encrypted with the server’s session key ((D) key) and an authenticator\r\nencrypted with the user-Exchange server session key ((E) key) . This lets the Exchange server know that\r\nthe user was authenticated to the Kerberos domain (realm) and that the TGS is valid (assuming the\r\nExchange server is able to decrypt it). The client also sends the server an authenticator (timestamp)\r\nhttps://adsecurity.org/?p=227\r\nPage 7 of 10\n\nencrypted with the session key ((E)key) it received from the KDC in Step 5. The Exchange server decrypts\r\nthe TGS, extracts the user’s group information, extracts the session key, and uses the session key to decrypt\r\nthe authenticator. This provides the server enough information to make an authorization decision. If the\r\nuser is authorized to connect to the server, it sends a reply.Keys used:\r\n(C) User’s Kerberos service (KDC) session key\r\n(D) Server’s Kerberos service (KDC) session key\r\n(E) User-Exchange service session key\r\n7. The Exchange server replies that authorization to the service is granted.\r\nThe Exchange server sends the client an AP-REP packet which includes its own authenticator encrypted\r\nwith the user-Exchange service session key ((E) key). This assumes the client requested mutual\r\nauthentication which is the default configuration.Keys used:\r\n(E)User-Exchange service session key\r\nNote:\r\nThis is a simplified explanation of Kerberos and doesn’t cover everything involved in this process.\r\nKerberos Key Storage Locatons\r\nWorkstation Keys:\r\nUser Key\r\nTicket-Granting Ticket\r\nTicket-Granting Service Session Key\r\nService Ticket\r\nSession Key\r\nDomain Controller:\r\nUser Key\r\nTicket-Granting Service Key\r\nService Key\r\nServer:\r\nService Key\r\nSession Key\r\nTICKETING\r\nThere are different “tickets” that are used to authenticate a client to a server’s resource. The client can be a user or\r\na computer.\r\nThe Ticket Granting Ticket (TGT) is the first ticket given to the requester (user or computer.\r\nThe TGT is comprised of the following fields:\r\nTicket Version Number\r\nhttps://adsecurity.org/?p=227\r\nPage 8 of 10\n\nRealm: The AD domain name in CAPITAL LETTERS\r\nServer Name: The KDC\r\nFlags: Kerberos Flag options\r\nKey\r\nClient Realm: The client’s AD domain name in CAPITAL LETTERS\r\nClient Name: The user name\r\nTransited: If the user is in a different domain than the resource, Kerberos tickets have transited.\r\nAuthentication\r\nTime\r\nStart Time\r\nEnd Time\r\nRenew Till\r\nClient Address\r\nAuthorization Data\r\nTicket Flags:\r\nFORWARDABLE\r\nFORWARDED\r\nPROXIABLE\r\nPROXY\r\nMAY-POSTDATE\r\nPOSTDATED\r\nINVALID\r\nRENEWABLE\r\nINITIAL\r\nPRE-AUTHENT\r\nHW-AUTHENT\r\nSupported Encryption Algorithms \u0026 Key Lengths:\r\nAES                       128\r\nAES128-CTS-HMAC-SHA1-96 (0x08)\r\nAES                       256\r\nAES256-CTS-HMAC-SHA1-96 (0x10)\r\nRC4-HMAC           128\r\nRC4-HMAC  (0x04)\r\nDES-CBC-CRC       56\r\nDES-CBC-CRC  (0x01)\r\nDES-CBC-MD5      56\r\nDES-CBC-MD5  (0x02)\r\nDEFAULT AD KERBEROS POLICY SETTINGS\r\nhttps://adsecurity.org/?p=227\r\nPage 9 of 10\n\nEnforce user logon restrictions: Enabled\r\nMaximum lifetime for service ticket: 600 minutes (10 hours)\r\nMaximum lifetime for user ticket: 600 minutes (10 hours)\r\nMaximum lifetime for user ticket renewal : 7 days\r\nMaximum tolerance for computer clock synchronization: 5 minutes\r\nReferences:\r\nKerberos Explained\r\nKerberos for the Busy Admin\r\n[MS-PAC]: Privilege Attribute Certificate Data Structure\r\nThe Kerberos Protocol (Wikipedia)\r\nMicrosoft Kerberos Protocol (MSDN)\r\nWhat is Kerberos Authentication\r\nKerberos Authentication Technical Reference\r\nHow the Kerberos Version 5 Authentication Protocol Works\r\nMicrosoft’s Kerberos Extensions – RFC 3244: “Microsoft Windows 2000 Kerberos Change Password and\r\nSet Password Protocols”\r\nKerberos Technical Supplement for Windows\r\n(Visited 37,288 times, 3 visits today)\r\nSource: https://adsecurity.org/?p=227\r\nhttps://adsecurity.org/?p=227\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://adsecurity.org/?p=227"
	],
	"report_names": [
		"?p=227"
	],
	"threat_actors": [],
	"ts_created_at": 1775434958,
	"ts_updated_at": 1775791219,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/17d5b291196b4a7c284c99418defca444a9c9bce.pdf",
		"text": "https://archive.orkl.eu/17d5b291196b4a7c284c99418defca444a9c9bce.txt",
		"img": "https://archive.orkl.eu/17d5b291196b4a7c284c99418defca444a9c9bce.jpg"
	}
}