We are all familiar with the windows login process, but do we really understand it? Or is just one of those things that you know how to do? Let’s review the process and see what we can learn.
Logon Process
We press CTRL + ALT + DELETE and enter our username and password. This sends a request to logon to either the SAM database or ADDS and responds with either success or failure.
Simple right? Sure we do it every day. That’s the simple part, knowing how to do it. The hard part is know how it’s done or the why it’s done.
Authentication
Authentication can mean many things, there is a variety of ways that we can authenticate or prove who we are to windows. This ranges from a simple logon (username and password) to more secure means like physical tokens, public key certificates, or even biometrics. Since we do not always work using resources only on the computer we logon to, authentication must be able to support environments that have resources on systems that use other operating systems as well as windows.
In your typical business environment, there will be a domain controller, file server, print server. Sometimes there are multiples of these and sometimes these can be on a single server.
Windows has its own default set of protocols that it uses for authentication, such as Kerberos, NTLM, TLS/SSL and digest. These are all part of the windows architecture. These protocols allow us to authenticate users, computers and services. This authentication allows us to access resources securely.
Microsoft tells us a little about the Kerberos method
“The Microsoft Windows Server operating systems implement the Kerberos version 5 authentication protocol and extensions for public key authentication. The Kerberos authentication client is implemented as a security support provider (SSP) and can be accessed through the Security Support Provider Interface (SSPI). Initial user authentication is integrated with the Winlogon single sign-on architecture. The Kerberos Key Distribution Center (KDC) is integrated with other Windows Server security services running on the domain controller. The KDC uses the domain’s Active Directory directory service database as its security account database. Active Directory is required for default Kerberos implementations.”
Makes sense right? Well why don’t we break it a down a bit more technical
Windows uses the Kerberos protocol every time you logon to a domain joined computer or access a network resource of any kind. Let’s look at what that actually means. Kerberos is kind of an abstract idea that we never directly interface with. It just works or it doesn’t.
Kerberos
It would not be a good idea to send your password in plain text across the network. The way this is dealt with is to use something called tickets. So when you logon the first thing that happens is your computer sends what we call an AS_REQ or authentication service request to the domain controller which is acting as the key distribution center. The username that you enter to logon is either the user principal name or the sam account name. The krbtgt service is used to send the AS_REQ to the KDC. Each message is stamped with the current time that gets encrypted with the hash of the user’s password. Now this is the part that will explain that age old problem of not being able to login if your local computer time is more than 5 minutes different than the domain controller. The time stamp encrypted in the AS_REQ message must be within 5 minutes or of the time on the domain controller or the message will be rejected.
The first thing that happens when the AS_REQ message is received is the KDC will try to decrypt the encrypted time stamp using the user’s password hash. If this fails then an error is returned to the client and no further action is taken. This is commonly referred to as the incorrect or bad password error.
If the decryption is successful, then the timestamp will be checked to see if it is within the 5 minute tolerance. This is process is known as pre-authentication. If you check the security logs on your domain controller you will see these show up as pre-authentication failures or successes.
Once this has been checked and passed a new message is returned by the KDC known as the AS_REP or authentication service reply. This message goes to the user with an embedded TGT or ticket granting ticket. This TGT will be cached by your computer along with the session key for the lifetime of the TGT which is normally about 10 hours.
The TGT is encrypted the KDC’s secret. This is stored in active directory as the password for the krbtgt user account. This user account exists in every active directory domain. This account is obviously critical in the operation of active directory. So don’t mess with it!
Hopefully you take away a little more understanding about the authentication process.
Happy Hunting 🙂
Randy Bordeaux | Tech Talks 