AD DS security is key for any environment as it is foundation of identity protection. Before look in to improvements of AD DS security in an environment, it is important to understand how Active Directory authentication works with Kerberos. In this post I am going to explain how AD authentication works behind the scene.
In infrastructure, there are different types of authentication protocols been used. Active Directory uses Kerberos version 5 as authentication protocol in order to provide authentication between server and client. Kerberos v5 became default authentication protocol for windows server from windows server 2003. It is an open standard and it provides interoperability with other systems which uses same standards.
Kerberos protocol is built to protect authentication between server and client in an open network where other systems also connected. The main concept behind authentication is, two parties agreed on a password (secret) and both use it to identify and verify their authenticity.
In above example, Dave and Server A have regular communications. They exchange confidential data between them more often. In order to protect this communication, they agreed on a common secret 1234 to use to verify their identities before exchange data. When Dave make initial communication, he passes his secret to server A and say “I’m Dave”. Server A checks the secret to see if it’s true. If its correct its identify him as Dave and allowed further communication.
Communication between Dave and Server A, happens in open network which means there are other connected systems. Sam is a user connected in same network where dave is in. He is aware about communication between Dave and Server A. He has interest about data exchange between them and like to get his hands on those. He starts to listen to traffic between these two hosts to find out the secret they use. Once he founds it, he starts to communicate to Server A and says he is Dave and also provides the secret 1234. From Server A side, it doesn’t see different between message from dave and sam now as both provides the correct secret.
Kerberos solved this challenge by using shared symmetric cryptographic key instead of the secrets. It uses same key to encryption and decryption. Kerberos name came from three headed strong dog in Greek mythology. As the three-headed dog, Kerberos protocol has three main components.
1) A Client
2) A Server
3) A trusted authority to issue secret keys
This trusted authority is called as Key Distribution Center (KDC). Before we look in to Kerberos in detail, better to understand how typical key exchange works.
if we revisit our scenario, now we have a KDC in place. Instead of communicating to server A direct, now Dave goes to KDC and says he needs to access server A. Now it needs a symmetric key to start communication with Server A. This key only should use by Dave and Server A. KDC accept the request and generates a key (Key D+S) and then distribute it to Dave and Server A. By the looks of it seems quite straight forward, but in server point of view there are few challenges. In order to accept connection from Dave, it need to know Key D+S, so it need to keep this key stored in Server A. we only considering about one connection in here. But if there are hundred connections, it need to store all the keys involves. This will cost resources for server A. However, actual Kerberos protocol operation is more efficient than this.
In Active Directory environment KDC is installed as part of the domain controller. KDC is responsible for two main functions.
1) Authentication Service (AS)
2) Ticket Granting Service (TGS)
In example, when Dave logs in to the system, it needs to prove KDC that he is exactly the same person that he claims to be. When he logins, it sends its user name to KDC along with “long-time key”. long-time key is generated based on Dave’s password. Kerberos client on Dave’s PC accept his password and generate cryptographic key. KDC also maintain a copy of this key in its database. Once KDC receives the request it checks its user name and long-term key with its records. If it’s all good, KDC response to Dave with a session key. This is called as Ticket Granting Ticket (TGT). TGT contain two things,
1) Copy of session key that KDC use to communicate with Dave. This is encrypted with KDC’s long-term key.
2) Copy of session key that Dave can use to communicate with KDC. This is encrypted with Dave’s long-term key so only Dave can decrypt it.
Once Dave receive this key, he can use its long-term key to decrypt the session key. After that, for all the future communication with KDC will be based on this session key. This session key is temporally and have its TTL (Time to Live) value.
This session key is saved in Dave’s computer volatile memory. Now it’s time to request access to Server A. Dave has to contact KDC again, but this time it uses the session key provided by KDC. This request included TGT, timestamp encrypted by the session key and service ID (the service which running on server A). Once KDC receives it, it uses its long-term key to decrypt TGT and retrieve the session key. then using session key, it decrypts the time stamp. If its change is less than 5 minutes it proves its came from Dave and it’s not the same request from previous time. Once KDC confirms as a legitimate request, it creates another ticket and this is called as service ticket. It contains two keys. One for Dave and one for Server A. both keys included requester’s name (Dave), recipient, time stamp, TTL value, a new session key (which will share between Dave and Server A). one key of this is encrypted using Dave’s long-term key. the other key is encrypted using Server A’s long-term key. at the end both together encrypted using session key between KDC and Dave. Finally ticket it ready and send over to Dave. Dave decrypt the ticket using session key. he also found “his” key and decrypt it using his long-term key. it revels the new session key which need to share between him and Server A. Then he creates a new request including Server A’s key retrieved from the service ticket, timestamp encrypted using the new session key created by KDC. Once Dave send it over to Server A, it decrypts its key using its long-term key and retrieve session key. Using session key, it can decrypt the timestamp to verify the authenticity of the request. As we can see, in this process it is not server A’s responsibility to keep track of the key use by client and its client’s responsibility to keep the relevant keys.
Let’s go ahead and recap what we learn about Kerberos authentication,
1) Dave sends user name and his long-term key to KDC (Domain Controller).
2) KDC, checks user name and long-term key with its database and verify identity. Then its generates TGT (Ticket Granting Ticket). It includes copy of session key which KDC use to communicate with Dave. This is encrypted with KDC’s long-term key. It also includes copy of session key Dave can use to communicate with KDC.
3) Response to Dave with TGT.
4) Dave decrypts his key using his long-term key and retrieve session key. His system creates new request including TGT, timestamp encrypted by the session key and service ID. Once request is generated, it sends to KDC.
5) KDC uses its long-term key to decrypt TGT and retrieve the session key. then session key can use to decrypt the timestamp. Then it creates a service ticket. This ticket includes two keys. One for server A and one for Dave. Dave’s key is encrypted using his long-term key and Server A’s key is encrypted using Server A’s long-term key. At the end both encrypted using session key used by KDC and Dave.
6) Sends Service Ticket to Dave.
7) Dave decrypt the ticket using session key and retrieve his key. Then he goes ahead and decrypt it to get new key which can use to establish connection with server A. At the end it creates another request including Server A’s key (Which created on step 5), timestamp which is encrypted by session key which Dave decrypted earlier on this step. Once everything ready, system send it to Server A.
8) Server A go ahead and decrypt his key using its long-term key and retrieve session key. then using it, server A can decrypt the time stamp to verify request’s authenticity. Once everything green, it allowed connection between Dave and Server A.
There are few other things which need to fulfil in order to complete above process.
• Connectivity – Server, Client and KDC need to have reliable connection between them to process requests and responses.
• DNS – Clients uses DNS to locate KDC and Servers. There for functioning DNS with correct records are required.
• Time Synchronization – As we can see, process uses timestamp to verify the authenticity of the requests. It only allows up to 5 minutes’ time difference. There for its must to have accurate time synchronization with PDC or other time source.
• Service Principle Names (SPN) – Clients uses SPN to locate services in AD environment. If there is no SPN for the services, clients and KDC cannot locate them when required. When setup services, make sure to setup SPNs as well.
This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.
Thank you for this detailed information on AD communication. I just need to know if you have any book which can explain all the communication details from client to all servers briefly?