What happens at the windows logon screen between the time you press enter after entering your credentials and ‘Loading Your Personal Settings’ message appears

It hardly takes a second for your password to be accepted at the logon screen but what goes on behind the scenes to log you in on to your workstation in a domain environment will take much more than a second to explain.

My primary area of expertise is Active Directory but if you have read my previous blogs then you would know that I haven’t written anything on my favourite subject till now. That’s because so much has been written on AD that there is nothing new which I can write about.  Moreover, I don’t like to like to write a blog just to update my blog site. In order to write something, I need a subject which is not discussed on the web as much as other stuff is. This is because I want to contribute to the IT Infrastructure community in general and the Windows folks in particular through my blog and writing on subjects which have been written about zillions of times by great authors would not contribute anything to our community. One of the examples could be ABE (Access Based Enumeration) there is not too much about ABE on the internet apart from the Microsoft website and that came as a motivation for me to write about ABE. But, I always wanted to write about AD and now I have found something related to AD, which does not have too much written about it. It’s Kerberos, the preferred authentication protocol in Active Directory environments. This also gives me the opportunity to explain the behind the scenes action during a logon process.

Kerberos replaces LM, NTLM and NTLMV2 which were used in the pre Windows 2000 era (and are still used in some cases, we will come to that later). Massachusetts Institute of Technology (MIT) developed Kerberos to protect network services provided by Project Athena; Project Athena was a joint project of MIT, Digital Equipment Corporation, and IBM (my current employer) to produce a campus-wide distributed computing environment for educational use. It was launched in 1983, and research and development ran until June 30, 1991, eight years after it began. As of 2010, Athena is still in production use at MIT. Project Athena was important in the early history of desktop and distributed computing. It created the X Window System, Kerberos, and Zephyr Notification Service. It influenced the development of thin computing, LDAP, Active Directory, and instant messaging.

The name Kerberos comes from Greek mythology; it is the three-headed dog that guarded the entrance to Hades (hell), according to Hindu mythology, Lord Yama (God of Death) has a dog named ‘sarvara’, which sounds similar to kerberos. Why was this name chosen, remains a mystery to me.

Now, let’s get to know this dog better, Kerberos sees users (which are usually the client) as UPNs (User Principal Names) and services as SPNs (Service Principal Names), Your AD logon name – the one that looks like an email address (e.g., username@bigfirm.com) – is your UPN, Kerberos “introduces” UPNs to SPNs by giving a UPN a “ticket” to the SPN’s service. Let’s try to understand the user logon process through an example.  Let’s call our user OM, OM comes to office in the morning and starts his workstation. At the login screen he enters his username and password. At this point, his workstation sends a pre-authenticator to the Authentication Service (AS) of his local KDC (Key Distribution Centre), the KDC is better known as the domain controller, or we should say KDC is one of the roles of a domain controller. The KDC has two components, the Authentication Service or AS and the Ticket Granting Service or TGS. The pre-authenticator contains the current date and time in YYYYMMDDHHMMSSZ format, the Z in the end denotes that the date and time is in universal (zulu) time. This info is encrypted with OM’s password. Upon receiving the pre-authenticator, the AS decrypts the pre-authenticator using OM’s password, which it already has. If the AS is unable to decrypt the pre-authenticator then it means that the user entered the wrong password as that doesn’t match with the user’s password in the domain controller and hence the user receives a message saying his/her password is wrong. If the AS is able to decrypt the pre-authenticator then it compares the date and time inside with the DC’s own date and time, if the difference is not more than 5 minutes (default value, but can be changed) then AS sends the user a TGT (Ticket Granting Ticket). This is the reason that all domain joined machines need to have a time which is not different from the DC’s time by more or less than five minutes. The TGT is valid for 10 hours (default value but can be changed), This TGT contains a temporary password for the user and that is encrypted by the password of the krbtgt user account’s password. Krbtgt account is created by default when the DC is first installed. The user does not need to decrypt the TGT and hence it doesn’t need to know the krbtgt user’s password. As you might have noticed that the user has still not logged on to his workstation, that’s because the authentication process is yet to be completed. The next step in this process starts when the user sends the newly acquired TGT to the TGS, TGS is as we discussed earlier the second component of KDC, TGS decrypts the TGT and that confirms that OM is indeed OM and not an impersonator and then assigns OM a Service Ticket (ST) to his workstation. The service tickets generally contain time start, total lifetime, security token etc. This service ticket is encrypted with the workstation’s computer account password in AD. OM presents this ST to his workstation upon which his workstation decrypts it, as it has it’s own password and then allows OM to login. At this point OM sees the “Loading Your Personal Settings” message, then his profile gets loaded/created and then he is ready to work on his workstation. Now, to better understand Kerberos, let’s take this example a bit further and see what happens when OM tries to access a file server. When the user tries to access any particular service, like the file server or print server, it needs to authenticate itself to that particular server or service. This authentication process starts by the user sending his/her TGT to the TGS and upon verifying it, the TGS assigns a service ticket for the file server to OM, this ST is again encrypted with the password of the computer account of file server. OM presents this ST to the file server, file server decrypts it and then allows OM to view the list of shared folders on that file server. Whether OM is able to enter any or all of those shares depends on whether OM has the required NTFS and share permissions to those shares. This emphasises the fact that Kerberos is used for authentication and not for authorization.

Now, that we have understood how Kerberos works, let’s get to know, why is it considered so cool and better than NTLM. There are several reasons; we will discuss the two most important ones, one of them being that if you are using Kerberos then the user’s actual password is sent over the network just once in a day (or 10 hours to be exact). For the rest of the day the user uses his Ticket Granting Ticket (TGT) to authenticate for the various services that it might need. Second, would be the advanced encryption techniques available for Kerberos. If you are using Windows Server 2008 or above you can opt to use AES (Advanced Encryption Standard) which is one of the best generally available encryption techniques and it hasn’t been hacked yet. For, older versions of Windows you can use RC4 HMAC which isn’t a bad encryption technology either. Microsoft had to opt for a comparatively lesser encryption technology for older versions of Windows because till the late nineties it was unlawful in the United States to export software which used encryption technology beyond a certain level. LM and NTLM were ridiculously easy to hack through replay/mirror attacks, NTLMV2 was much better and Kerberos is extremely difficult or even impossible to hack.

It’s time to look at the scenarios where Kerberos is NOT used for authentication. The first scenario would be when you use an IP address in a UNC path. In this case Kerberos is not used because Kerberos needs SPNs and SPNs need DNS names. The second would be trying to connect to a computer which is in a workgroup. The third would be trying to connect to a pre windows 2000 computer. The most interesting scenario is when the domain controller is inundated with logon requests, it starts to login users with the previous authentication protocols to avoid the extra work that it needs to do with using Kerberos. I think this is one of the contributing reasons why Microsoft recommends the maximum hardware resources usage for domain controllers to be at 30%. But, How would you know whether you have been logged in with Kerberos or something else?? There are several indicators. If you are not logged in with Kerberos then you wouldn’t be able to add machines to domain, you won’t get any group policies etc. but the simplest way to find that out would be to run the command klist. Klist allows us to see the tickets that we currently have. It comes by default with Windows 7, Windows Server 2008 and later and can be installed on the previous versions. It’s part of the Windows Server 2003 resource kit. If you are not logged in with Kerberos then there won’t be any tickets.

This was the story behind what all happens within the blink of an eye during the logon process. I hope you liked what I had to share with you as my first blog on my favourite subject – Active Directory.