Deep dive: Logging on to Windows

Logging on to your computer is certainly faster than it used to be, yet there are a bunch of technical steps that happen in the background. At our ITOps Talk: All things hybrid event, senior developer Steve Syfuhs took us through the details, including access to cloud resources. 
This article explains the process to just log on to Windows with an on-premises Active Directory Domain, including the fact that your password isn't sent through to the Active Directory Domain Controller server!

The goal of the Windows logon process

When you sit down at your computer, your aim is to get to your desktop as fast as possible, so you can start working. But we also need to validate that you've entered a correct username and password to prove you are allowed to use that device. Then, you might want access to resources on your local network, like a file share or printer. So the Windows logon process needs to take your credentials, pass them to another service to validate them, then load your desktop, in as short a time as possible. Sounds simple? Let's look at the complexity.

The Windows logon process in detail

Step 1 of the Windows logon process with winlogon.exe, logonUI.exe and lsass.exe

The Windows Logon Application handles the logon process, with LogonUI.exe displaying the correct logon box onscreen, relevant to the authentication providers that are available (for example, on this device can you choose a password, Windows Hello, a PIN number or a FIDO key?).

Enter your password into the logon user interface, and winlogon.exe passes it off to the local security authority subsystem service (lsass.exe). Lsass drives the entire security of your computer as you access resources.

The Local security authority exposes a function called LsalogonUser to winlogon over LPC (a remote procedure call protocol for processes running on the same machine).

The Windows Local Security Authority process

Lsass handles Authentication (Auth) Packages and in the Windows logon process it calls the Negotiate Auth Package. You can see that in the source code that Microsoft provides as a sample to people who want to make their own credential provider for Windows.

Windows logon process NegotiateAuthPackage

We're using a cached logon here, checking if there's a match with the last successful password we entered on this machine, so we're not waiting for a response for the domain controller over the network. Negotiate asks the credential providers (for example NegoEx, Kerberos and NTLM) if they support cached logins, and NTLM says yes!

Now NTLM checks it's  netlogon authentication cache, but none of this process is in plain text. The password you entered is hashed tens if thousands of times and is compared against the hashed passwords stored in the local cache. This hashing is important - if anyone was to get access to the cache, we don't want them to be able to unhash the password back to a plain text value.

If the provided password hash has a match in the cache, then we can go and load the desktop! NTLM returns a positive to lsass which passes that approval to winlogon.

Loading the user profile and desktop

Then winlogon handles another bunch of processes to load your user profile, desktop, run userinit to process any login scripts etc and finally starts explorer.exe which you see as your desktop UI.

OK, now we've authenticated quickly, but only locally, and we're now seeing the desktop and can start working. Lsass is not finished yet though!  

Domain controller authentication with Kerberos

The local security authority, having created a background thread, asks Negotiate for a credential provider that supports online logon and gets a yes from Kerberos. This protocol is used to communicate with your domain controller running Active Directory. Even here, we're not sending the entered password to the domain controller, we're having a little two-way conversation similar to placing a collect phone call.  

We send an AS_REQ authentication service request to authenticate as a user:

Windows: Hi, I'm Steve, please give me a ticket granting ticket!

Domain Controller: No, prove that you are Steve.

W: OK here's a hash of my current password that also included the current time stamp.

DC: OK if I also use the current timestamp that matches the hash I have of your password. Here's your Kerberos ticket granting ticket (krbtgt). Think of it like your theme park pass that says I trust you've paid your entry free and you can now show it to all the different rides and you'll be able to go on them.

This is a successful authentication that we match a valid user & password in Active Directory!

Windows: Hey, here's my tgt, can I access this local machine host?

DC: Sure! Here's a ticket granting access to the local machine. 

W: Cool! I'll hold that in memory for accessing any other network resources on my local network.

Windows can decrypt that ticket, using your password, to gain access to a bunch of information inside the ticket - like your userprofile path, group membership etc. It also creates an NT token, which is your identity represented in Windows for applications etc to use.

Conclusion

The next time it feels like your logon is a little slow, remember all the things it's doing in the background! In a future blog post, we'll go through Steve's explanation of this process in hybrid environments, where Azure Active Directory also comes into play.

To watch the full video, visit OPS108 Windows authentication internals in a hybrid world 

Special thanks to Steve Syfuhs for sharing his expertise with us! 

Learn more

• Credentials Processes in Windows Authentication
• Active Directory Domain Services Overview
• Windows Authentication in a Hybrid World