Kerberos clarification?

Robbo777 · March 2016

Hi, so i have been reading up on kerberos and am wondering if my understanding is correct on how it work? Along with one or 2 questions at the end.

So basically, you have a Key Distribution Centre, a file server which hosts the services and a client/user.

1. The user will attempt to logon

2. The information such as personal information and time stamps are encrypted using the users personal password as a key, the username and name are not encrypted though

3. The username is checked on the domain controller and if a username match is found then the DC will attempt to decrypt the info using the users password as a key on the DC side

4. If it works, the DC will issue a Ticket Granting Ticket which is encrypted using the DC password as a key and given back to the client

5. Then the user wants to access something on a file server that has a ceertain service on it

6. So they send back the TGT to the DC and it decrypts it using the DC password for the syymetrical key

7. This validates the user and the DC can then issue the client with a ticket for the specific service that the client wants to access, this is called a TGS and is encrypted using the file server password as a key

8. When the user wants to access the file server, it creates a copy of the TGS ticket and sends it to the file server, the file server will then see if it can decrypt the ticket using their password as a key for it

9. If successful then the client will be allowed access to the server

So, now i have 2 questions regarding this.

1. When the client or DC create encrypted info using the password as keys, what algorithm is being used? SHA, MD5?

2. I've read that AES can be implemented as a part of the encryption somewhere, but where and how? Is it used to encrypt the ticket info being exchanged between everyone so it would appear to be like this:

(encrypted using (ticket information encrypted using password as key) AES )

3. What type of encryption is used with NTLM? Is it a CHAP style hash authentication? I couldn't find much on it online

4. What actually goes into the secure channel when a DC sets one up with a client or other DC also? I haven't found much on what encryption is used for this procedure.

Am i right in saying all of this?

NetworkNewb · March 2016

I thought thought this video made it pretty straight forward when I was looking to learn more about it.

https://m.youtube.com/watch?v=kp5d8Yv3-0c

OctalDump · March 2016

I'm not going to answer your questions, because I will likely make a mistake unless I look up the details, which I can't at the moment.

However, SHA and MD5 are hashing algorithms, so would not be 'encryption'. Encryption is always decryptable (is that a word), whereas hashes are not. Or put another way, encryption has a one to one correlation with plain text, whereas hashing has a one to many. Hashing loses information, encryption doesn't.

Now to complicate things, hashing and encryption are often used together.

With regards to authentication, if I hash my secret along with some other public known data (eg the time) or a challenge from the authenticator, then the authenticator can apply the same hash to the secret and the other data. This means that the secret itself does not need to be sent at all, not even encrypted. The challenge or time stamp data is added to prevent replay attacks, since the hash will change whenever the challenge or timestamp changes.

Using passwords to generate hashes to use as encryption keys is a common trick. Since the hash can be a fixed length, and encryption algorithms like nice long keys. Your 13 letter password becomes a 128bit hash, which can then be used as a 128bit key (or else transformed to be the right length for the encryption algorithm).

Kerberos is quite clever stuff. Tricky even. My understanding is that the secret (password) is never transmitted. The password is used to generate a hash, and the hash is used as an encryption key [presumably this is where AES comes into play]. The user and the AS (I think this might not technically be always the case, but anyway) both know the password, and both know how to hash the password to make the encryption key. This allows the user to ask for a TGS (ticket granting server session key)) and a Ticket Granting Ticket. The user basically says "Hey, I'm John Smith, can I have a TGT", and the server says "Sure, I'll send it encrypted to you, and if you really are John Smith, you'll be able to decrypt it", and the AS asks the KDC for a TGT on behalf of the user (the exchange following similar lines as the client AS exchange), encrypts it all using the key generated from the user secret, and sends to the user, who decrypts using the key generated from the secret they entered.

Then the user can use the TGT to ask the Ticket Granting Server for the ticket to ask a Service Server (great name?) for access.

The thing is that each connection is using a different key, generated for this interaction. So there's no need for authentication details to be shared amongst all the servers, each server only needs to know how to talk to its partner.

LM used a hashing algorithm based on DES (which is an encryption algorithm, so is confusing, but it's MS so whatever). The NT part used also MD4 (a hashing algorithm). Somehow their powers are combined (I'm really rusty on this). NTLMv2 used MD5, and uses challenges along with the shared secret (password). This is probably at least partially wrong. But the idea is that NTLM was deeply flawed, NTLMv2 addresses some of those flaws with a better hashing algorithm and the use of challenges.

NTLM is basically deprecated in domain infrastructures in favour of Kerberos based AD.

I'm not sure what you mean when you say "secure channel".

Robbo777 · March 2016

Sounds like basically my understanding of Kerberos to except for one detail. The TGT is encrypted using a hash of the domain controllers password as a key, according to CBT nuggets anyway (in the link above on the second post in this thread actually).

I just meant the "secure channel" that is set up with the domain controller and another user on the network whenever they logon.

I suppose the main thing i want to try and grasp now then is how Kerberos is used in Active Directory, or where is it used? Is it used for when a user logs on?

WHERE do i activate the feature in group policy to use kerberos?? I'm still not sure

Kerberos clarification?

Comments