{"id":227,"date":"2014-09-12T15:17:07","date_gmt":"2014-09-12T19:17:07","guid":{"rendered":"http:\/\/blog.metcorp.org\/?p=227"},"modified":"2018-04-06T21:52:25","modified_gmt":"2018-04-07T01:52:25","slug":"kerberos-active-directorys-secret-decoder-ring","status":"publish","type":"post","link":"https:\/\/adsecurity.org\/?p=227","title":{"rendered":"Kerberos, Active Directory\u2019s Secret Decoder Ring"},"content":{"rendered":"

Kerberos Overview<\/strong><\/p>\n

Kerberos <\/a>is a protocol with roots in MIT<\/a> named after the three-headed dog, Cerberus<\/a>. Named because there are 3 parties: the client, the resource server, and a 3rd party (the Key Distribution Center, KDC).<\/p>\n

Kerberos can be a difficult authentication protocol to describe, so I will attempt to simplify it as best as possible.<\/p>\n

Kerberos authentication leverages long-term asymmetric keys (public key) and short-term symmetric keys (session keys).<\/p>\n

Asymmetric key cryptography uses two mathematically connected keys where one key is used to encrypt and the other is used to decrypt data. This is most commonly used in Public Key encryption (PKI) where one of the keys is kept secret by the user or service (Private Key) and the other key is available to anyone who wants it (Public Key). In this manner a user can sign (encrypt a hash with the private key) data to ensure it originated from that user without modification (the receiver decrypts the hash with the public key). Also a person can use the user\u2019s public key to encrypt data so that only the user can decrypt it with the user\u2019s private key.<\/p>\n

Symmetric key cryptography uses one key to encrypt and the same to decrypt the data. This is also referred to as a shared secret.<\/p>\n

Since asymmetric key cryptography is more processor intensive, it is typically only used to encrypt session keys which use symmetric keys (shared secret).<\/p>\n

Active Directory implements Kerberos version 5 in two components: the Authentication service and the Ticket-granting service.<\/p>\n

The Authentication Service (AS) is the first contact the client has with Kerberos and is used to lookup the user\u2019s password and create the Ticket Granting Ticket (TGT). The AS also creates the session key the user will use for future communication with Kerberos.<\/p>\n

The Ticket Granting Ticket (TGT) is the Kerberos ticket for the Ticket Granting Service (runs on the KDC) and is encrypted using the KDC key (KRBTGT domain Kerberos account<\/a>), meaning that only a KDC can decrypt and read the ticket. While the user\u2019s ticket ,the TGT, is set to expire after 10 hours (AD default), it can be renewed as often as needed during the TGT renewable lifetime which is 7 days (AD default). Once the authenticating user has a TGT, it presents the TGT to the KDC to get a Service Ticket for the Ticket Granting Service (TGS) on the KDC. Most key Kerberos communication occurs over UDP port 88, though starting with Windows Vista & Windows Server 2008 now default to using TCP for Kerberos ticket requests.<\/p>\n

There is a myth in the Windows Kerberos world that if a workstation’s clock is skewed more than 5 minutes from that of the Domain Controller, Kerberos authentication wouldn’t work.<\/em>
\nTechnically, all clocks in the Kerberos world must be kept closely in-sync to prevent replay attacks. By default, Microsoft Active Directory has a tolerance of 5 minutes. Though in most cases, this doesn’t mater. When a client sends a Kerberos request to a DC, the DC will reply with a “KRB_ERROR – KRB_AP_ERR_SKEW (37)” and the Windows client will update its time for the Kerberos session with the DC and resend the request.<\/strong> Provided the clock skew between the client and DC is not more than the ticket lifetime (10 hours by default), the second request will be successful.<\/p>\n

Kerberized Internet Negotiation of Keys (KINK) RFC 4430<\/a> details how this works:<\/p>\n

If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW.\u00a0 The optional client’s time in the KRB-ERROR SHOULD be filled out.\u00a0 If the server protects the error by adding the Cksum field and returning the correct client’s time, the client SHOULD compute the difference (in seconds) between the two clocks based upon the client and server time contained in the KRB-ERROR message.\u00a0 The client SHOULD store this clock difference and use it to adjust its clock in subsequent messages.\u00a0<\/strong> If the error is not protected, the client MUST NOT use the difference to adjust subsequent messages, because doing so would allow an attacker to construct authenticators that can be used to mount replay attacks.<\/p><\/blockquote>\n

KB956627 also describes this behavior<\/a>.
\nConfused yet?
\nKeep reading, it gets easier\u2026<\/p>\n

Every service that is Kerberos enabled has an entry point called a Service Principal Name (SPN) and each Kerberos user has a User Principal Name (UPN). For example, a user named Joe User in the ADSECURITY.ORG Kerberos realm aka AD domain (the Kerberos realm is always all Caps) has a UPN of JoeUser@ADSecurity.org. If Joe User initiates a connection to the share path \\\\server1.ADSecurity.org\\Shared then Joe\u2019s workstation will lookup the computer server1.ADSecurity.org in Active Directory and read its SPN attribute (cifs\/server1.ADSecurity.org). The computer SPN is used to identify the application server in the Kerberos TGS ticket request. Furthermore, when Joe opens Outlook, his workstation performs similar actions looking up the Exchange server\u2019s SPN.
\nExchange 2010 has a number of registered SPNs; here are a few of them used as part of a client connection (using Outlook 2010):<\/p>\n