 Welcome to Ops108, Windows Authentication Internals in a Hybrid World. Come and join Oren and I and a very special guest. Let's go. Today, we have Stephen Sifers, senior developer and he's going to be talking to us about authentication internals in a hybrid world. Steve, take it away. Thanks Oren. Thanks Tonya. Like I said, I'm Steve Sifers. I'm a developer on the Hybrid Identity Team at Microsoft. We focus on bridging the gap between what lives in on-prem and active directory and Windows as well as what lives in the cloud in Azure Active Directory. One of the common occurrences that we're seeing these days is that customers are rightfully living in both the on-prem world and the cloud world, where you have resources that have been in on-prem for five, 10, 20 years, active directory has been around for 20 years, so a lot of companies have resources that go back that far. But at the same time, they're also moving towards a more modern world where you have resources in the cloud in Azure Active Directory or in third parties like Amazon or Salesforce or services like that. And the ability to transition from on-prem and the cloud can be particularly difficult in some cases. And so we have built a lot of technology into Windows, into Azure to make this a lot smoother, make it a lot easier for customers. And one of the core critical pieces of that is authentication. When you log into Windows, we wanna make sure that you have the ability to access all of your resources in an incredibly easy to use manner. And so how do we take a look at exactly what's happening? So this presentation is very much high level as well as very deep dive. Some of these things that we're talking about go all the way down into the internal. Those are all sort of the philosophical and architectural reasons for why things work this way. So I think everyone's seen this probably a million times. How many times have you logged into Windows? I do it dozen times a day, seven days a week, 360 days out of a year, and then multiply that by ten years. Some have been doing this for 15s or 20. Everyone knows what the Windows login screen is. But have you ever actually looked at it and said, well, how does this work? What's going on under the covers? I type in this password, or I use Windows Hello, or I use a smart card. How many people have smart cards, or even FIDO if you have a FIDO device? What's happening under the covers? All I know is I type this thing in and I suddenly I'm on my desktop. And if we do that, it's this really quick thing. All of this technology has been built to get to the desktop as quick as possible. And as well as that gets your access to all of these resources. What's going on? So in order to answer that question, we kind of have to look at the scope of what kind of log-ons are there. Well, there's the credentials that we use if we're using smart cards. You have a little chip on that or FIDO. You can't see it, but I have my Windows Hello camera that I use to log in every day. Or you have your password. But that's actually secondary to how you log in. Because those credentials are only as good as the authority that drives your ability to log in. And there's a couple of different types. What I mean by authority is when you type your password in, that has to be compared against something. What is that something? So back in the old days, and we're talking back in the early Windows days of the early 90s, late 80s, there was no concept of this domain. There was no concept of the cloud or the internet. And machines didn't talk to one another. So when you logged in, you were just doing this locally. There was no central location to authenticate yourself. And we refer to that as the work group. And that is when you type in your password, it's the local machine validating your password and full stop. That's all it's doing. And then over the years, more recently, Windows 8 timeframe, we introduced this idea that you can log in with your personal accounts, your Microsoft accounts, or back in the day, your Windows Live account. And that relied on Microsoft services in the cloud to authenticate you. And that's for your personal stuff. And it's a one-to-one relationship of, this is my machine, I log into my machine, and that's it. And then, of course, you have domain join, which I think the majority of our enterprise users are familiar with. There's millions upon millions and millions of machines that are domain joined. You use them every day to get your work done. And this has been around for 20 years, where your machine requires authentication against Active Directory, a back-end service that uses Kerberos and NTLM to verify who you are. And, of course, Azure AD join, which is this idea of, instead of relying on your on-premises domain join services for Active Directory, you're actually using Azure to authenticate yourself in a similar way. I'll go into detail about how that works a little later. And then, of course, this thing called hybrid domain join, which is this way of authenticating against on-prem Active Directory, as well as Azure Active Directory for things like single sign-up. And I'll explain what that distinction is in a bit. If we go back, you'll remember we have this lock screen. It has to be rendered to somehow. We have our images. We have our password. We have some sign-in options. And if I want to, I can switch between different things. Well, these things are called credential providers. And these credential providers, well, they provide credentials. I mean, that sounds kind of redundant. But the idea is that they take the input from your keyboard or from your camera or from your smart card. And all they do, they don't do anything extra. All they do is they take those credentials and they hand them off to some other service. When you're logging in, what happens is you have this process called WinLogOn. And WinLogOn is that whole screen that you see. It's the background. It's the credential providers. It's the thing that actually drives all of the experience that you see. It manages all of the different log-on sessions. It does quite a bit. And then there's this thing log-on UI. It's the process that actually renders the content so that you see the credential providers. And then you have a list of credential providers. And the credential providers themselves are very scoped in what they do. There are, I think, two dozen or so credential providers in Windows. And they run the gamut of allowing you to type in your password or change your password. Doing smart card, doing Windows Hello for biometrics, for face or for fingerprint, or for your Windows Hello pin. Seems like FIDL log-on, your Microsoft account log-on. And all they're doing is they're just rendering that particular piece of information so that you can type in your password or use whatever credential you have and then pass them on to another service. And the way that works, you type in your password, hands it off to log-on UI. Log-on UI passes it off to WinLog-on. And WinLog-on passes it off to this thing called LSAS, L-S-A-S-S, Local Security Authority Service. And the interesting thing about LSA is it is the thing that drives the entire security of your Windows machine. So when you're logging in, when you're accessing resources through single sign-on, everything is passing through LSA. And in this particular case, LSA actually exposes a particular function to WinLog-on called LSA Log-on User. And this is over a communications channel called RPC. And RPC is just a way for different processes to communicate to each other. And technically, there's actually another part of RPC called LPC, which is for processes on the same machine, because RPC can actually be used across the machine. To create a problem, you get your password, your password gets handed off to log-on UI, to WinLog-on, and then it gets to LSA. And so you move into the LSA, the Local Security Authority. So you have your password in LSA, and LSA doesn't really know what to do with your password. And that's kind of the interesting thing, because LSA itself, it's a process in Windows, but LSA itself is not actually all that smart. It doesn't do anything. What LSA does is it hosts a service, a collection of services that do different things. In this case, one of them is allowing you to log-on. Another thing is auditing. So your Windows auditing system or secret management. So when you're protecting your asymmetric keys, those live in a separate service within LSA. But one of these services is authentication. And the way that works in Windows is through this idea of called auth packages. And an auth package sort of represents a mechanism for proving you are who you say you are using different types of protocols. And some of those protocols you might have heard of, Kerberos or NTLM or OAuth. These auth packages are there to set up there to say that for a particular application or for a particular type of credential, I can convert that into something that the rest of the world understands or a specific piece of the world understands. And so when WinLog-on passes your password to LSA, and LSA looks up an auth package, one of the interesting things is, it doesn't know what to pick, right? LSA isn't really aware of how log-ons are supposed to happen. It defers that to the auth packages. So LSA doesn't know what package to pick. It's not intelligent to the point where it can arbitrarily pick a package and say, here you go, take this credential and go do something with it. What actually is required is we need the credential provider to tell us what it's doing. So I've typed in my password. And that credential provider says, okay, I have your password. And by the way, I want you to use a special package. And that special package in this case is negotiated. And I'll talk about the negotiators in a second. But if we want to go cheat, we can actually look at some of the samples. Windows has historically provided a whole bunch of samples for all of these different systems. And one of these is the credential provider sample. So if you want to go create your own credential provider, you can. But what we can actually look at is we actually know for a fact that it's using negotiator as a source, it's saying. Go use the negotiator package. So the credential provider is told LSA, hey, here's your password. And by the way, go use negotiator. And then from there, negotiate kicks in. And what you're doing in negotiate is you're calling a specific function, the LSA logon user function. And under the covers it gets routed to, there's a whole bunch of routing that goes on. But at a conceptually high level, we're saying we want to log this user on, tune the machine, we're giving you a credential. And go do that. And so in the Windows logon case, where you're at your lock screen or you're just booted, what we're actually doing is we're doing what's called a cached logon. In some other cases, we call it a fast logon in comparison to a slow logon. And I'll explain what that is in a second. But the idea is that negotiate is this way of going through all of the other off packages in the system to figure out who can validate and use these credentials to get you to the desktop. So the way that negotiate does that is it has a list of packages that have already been listed in the system. So it's sort of this interesting relationship between the list of off packages that are in LSA and then the specific off packages that expose a thing to negotiate that says, hey, I can do negotiate. I can be part of your subset of packages that do this negotiated logon. And so some of the examples, nego EX negotiate extender, that's a special package that is used for a single sign-on for accessing specific protocols that doesn't actually play a role here, but it just happens to be the first one that gets listed. And then of course we have Kerberos and NTLM. Now, this is a specific order of preference there. I'm assuming it's no longer configurable, but I was just wondering, is there something that always gets checked first? So they're always try to go to Kerberos, before going to NTLM. So that's actually a really good question because there is a specific order to it and the order will surprise a lot of people. And before I go through this order, I'd like to put the caveat out there that this is sort of an internal implementation detail that customers should not rely on. There's no reason for you to look at this and say, I fully expect that this is always going to be the behavior from here on out. It may change tomorrow, but this is the current state of things. But so the ordering is actually very important here and I'll show you why for a moment. So the order that I have here, negative EX Kerberos and NTLM, this is the order. It hits negative EX and it says, can you do a cash vlog on it? Negative EX says no, and it hits Kerberos and Kerberos says, no, I can't do a cash vlog on it. Now I'll explain that in a second. And then it hits NTLM and it says, can you do a cash vlog on it? NTLM says, I can. And so what happens is you've typed in your password, it's gone all the way through to NTLM and NTLM has checked its cash. Now this cash is not a list of passwords that for all you different users. It's not a single sign on cash. It's an authentication cash that allows you to log on when your machine is not connected to the network. It doesn't have a line of sight to a domain controller. The net log on cash is there to get you to the desktop as quickly as possible. And so NTLM is the only one that does a cash vlog on. And the NTLM cash, the way it works is you pass the password all the way through down into the net log on cash. And the cash has that password thousands of times, tens of thousands of times. And it does a comparison against what it's stored in the cash file to say that do these passwords match. The reason that we do it so many times is that, so you cannot take that hash if you happen to get into a Windows system, you're able, if you're able to steal that cash file, you're not able to take that hash and reverse it back into a password. It's an incredibly difficult thing to do because we've hashed it thousands and thousands of times. And so, we do that comparison, we've hashed it, we look at it and say does the password you typed in match the password that we've seen previously? If it does, we take you to your desktop. If we don't, we'll do something else. And so you logged in, you've done the hash, the hashing, you've compared it, and it returns this response all the way back up to LSA. LSA passes it to when logged on and it gets you to your desktop. So, another question there. You mentioned that with Kerberos, password caching was disabled. So, one of the things we're obviously recommending to a lot of people is that they disable NTLM on their networks when they can get to that point. Does that mean that if you disable NTLM, password caching just goes away and you don't have that option? No, no, so when we say disabling NTLM, what we're practically saying is that we're disabling NTLM, the single sign-on protocol, not NTLM, the authentication subsystem in Windows. And to alleviate any concerns, the NTLM subsystem in Windows is different from the NTLM protocol. There are significant differences in how they're implemented. The NTLM protocol has specific requirements that it must meet in order to interoperate with the rest of the world, whereas the internal don't. And so, we can modify the internals of the subsystem without affecting the protocol. So, when we're saying disable the NTLM protocol, we're not saying disable the cache, we're just saying don't allow you to use NTLM out on the network. Thanks. Yeah. And Steve, some of those things that you've been mentioning, especially that the executables and the processes seem really familiar. Has this process changed very much at all since we first introduced Active Directory? Or is this feeling much that the way that the authentication processes has been? So, this part of the step has not really changed in forever. So, there are some differences over the years. Negotiate used to not exist and it just used to be NTLM back in the pre-Active Directory days. But fundamentally, this is kind of how it worked for the last 20 years since Active Directory was introduced. However, and I'm going back to the first step, this process has changed. So, this process changed in Windows Vista timeframe. So, prior to Windows XP, Windows 2000, Windows 2003, we had this thing called the GINA, the G-I-N-A, which was the log-on screen. It was an EXE that ran that had the username and password. And it was completely unmodifiable by third parties. If you wanted to make a custom credential prompt, you actually had to build your entire UI for that. That means the log-on box, the text boxes, all of those things, and that turned out to be dangerous in one case because you're having to write the entire log-on framework for that to work, which not great. To the UI uniform and your customers might look at it and say, well, what's that? That doesn't look like Windows. What are you doing? And so, the credential providers were introduced and the credential provider is not the entire screen. It's literally the text box and the image and the button and some of the links. That's all it is. So, you can control just a little bit of that, but you do have control on the back end of what happens in the tunnel. So, we've just done a cached log-on, right? We've checked your password, we've hashed it, we've done it thousands of times, and we've just told LSA, yep, yep, you're good. That's your password. So, what do we do? Well, LSA passes that information back to WinLogOn. WinLogOn says, yeah, okay, that's your password, that's good. So, it doesn't create your desktop. So, creating your desktop is a very complicated process because there's a whole lot of moving parts. It has to load your profile, which involves loading the registry, loading all of the information about your user, where are your files stored? Is this data stored on a file share? What's all of those different things? Are you roaming profile? Or are you a new one? Is this the first time we've ever seen you? That sort of thing. And then it goes off to username. Username's the process that runs your script. So, when you're, if you have a log-on script in Active Directory, username's the thing that executes. That sort of sets everything up. And then it starts Explorer. And if anyone's not familiar with Explorer, it's your start menu. It's your shell. It's the thing that creates the icons on your desktop and allows you to run processes and things. If we go back to that login process, type in my password, and I'm being very repetitive here to sort of show that you're getting to the desktop super quickly. And we haven't touched the network at all, right? You've typed in your password, you've hit enter. It's notified all of the things. And suddenly you're at the desktop. That seems counter to this idea that we are a domain join system. We're an Azure AD join system. We're this thing that relies on a remote authentication service, like Active Directory or Azure Active Directory to argue it, you know, what's going on there? Well, it turns out that you've gotten to the desktop. And in the background, we're now doing something. So that was called the fast log on. We've taken your password, we've gotten to your desktop and you can go do whatever you need to do. But in the background, LSA is now doing something else. While LSA is doing your log on, it's actually created a background thread. And that background thread is just something that allows you to use your desktop without having to wait on anything that's happening in this processing step. And so this background thread is kicked off and it asks negotiate, hey, I'm doing LSA log on user again. Can you log me on? And it's going to pass the credentials to it. And in this case, what it's doing is saying, who supports online log on? And that means who can go touch the network, go contact the networking and give me all of the things that I need from a remote source. And in this case, it goes through the same list. It goes to negative X, it goes to Kerberos, it goes to NTON. Negative X can't do it in this case. And then Kerberos says, oh, I can. I know Kerberos, I can do Kerberos. I can communicate with the domain controller. I'm configured for that. And so it goes and communicates with the domain control. It does the Kerberos protocol. I'll explain what that is in a second. And so Kerberos contacts the domain controller using the credentials that you just typed in or your smart card or your religious flow, communicates with the domain controller and the domain controller says, I know who that user is. Here's the information for it. And then it's done. So how does Kerberos work? Well, that's kind of a fun and very complicated process. We're at our lock screen. I'm gonna type in the password. And remember, fast log on. Get into the desktop immediately. And you'll notice that a whole bunch of other stuff happened in the background. This whole request actually happened after you got to the desktop. Or in between logging in and getting into the desktop, it happened. If you're on a large network, like for instance at Microsoft, when I log into my machine, this whole process can actually take a few seconds. And you work from one second up to 15 seconds while it's doing a whole bunch of things, accessing a bunch of different service principles and things like that. So we don't wanna wait for this to happen to get to the desktop. And so this is kicked off in the background. And the Kerberos protocol, the protocol itself is, it has its history going back to the early 80s. But what we're looking at today really was sort of invented in around the 2000 timeframe. Microsoft, when they released Windows 2000, first released Kerberos as the authentication mechanism for Windows instead of NTLM. And so what came with it were a few extensions to it and some critical modifications to how the protocol works so that you can have a more secure and more useful authentication process. And the way that this protocol works is in two stages. The first thing that you do is you authenticate yourself as the user. Hi, I'm Steve. Here's my password. Please give me this thing back. Give me an okay. And the way that that works is kind of cool. The first stage of this protocol is called the ASREC, the authentication service request. And the first stage is you communicating with the domain controller to say that this is my password, please verify it. The interesting thing about how that exchange works is you're never sending your password to the remote machine. Believe it or not, what you're actually doing is you're relying on the cryptographic properties of your password to be able to authenticate yourself. And so when Windows goes and communicates with the domain controller, what it's actually saying is it's, in a sense it's actually making a collect call to the domain controller. And it's saying, hi, I'm Steve. Please give me my ticket granting ticket. I'll explain what that is in a second. But what it's saying is I don't have proof of anything. Just please give me the ticket. And the main controller can do one of two things. You can say, sure, here you go. Or it can say, no, I need you to prove it. I need you to go out of your way to prove it. And so in this case, Windows has said, it's made a collect call. It said, I want to authenticate myself. Please give me a ticket granting ticket. And the KBC, the domain controller, the key distribution center, with all different names for the same basic thing, your active directory server has said, no, I'm not going to do that. I need you to prove you are who you say you are. And the reason that we do it this way is a side effect of the way that the program's protocol works. Now, I said that the authentication process doesn't send your password over the wire. It doesn't. What it does is your client encrypts your password. It hashes it, does a whole bunch of cryptographic operations against it to generate a key. And then the server, your active directors are your domain controller, does the same thing. It has that key in its database. And what's happening is if both the client and the server have the same key, have the same value of the same key, they can communicate with each other over a secure channel. And that's how you get your secure TGT back. When I make a collect call and I say, please give me a TGT, the domain controller says, sure, here you go, here's your TGT. It is encrypted to what I think your password is. But in this case, your domain controller is saying, no, I'm not gonna allow you to make a collect call. I need you to effectively put coins into the phone. And what's happening here is a special thing called pre-authentication. It's this idea that when I'm making that call to the domain controller, I am providing additional information that proves that I am holding the password right then and there. And that's just taking your password, hashing it, and then encrypting your current timestamp. It says it is now four 10 on a Friday afternoon, January 22nd, and it fires it off to the domain controller and the domain controller looks at that and says, yeah, that's the current time. So I think I have a pretty good idea of it being you. And so that's what's going on here. It's saying collect call, no, okay, here's additional information. You can see the different sizes. There's some additional information. If we look at the message itself, we can actually see that and it's called the timestamp. And it's just encrypted data. You're not gonna be able to decrypt it. It's binary opaque data and that means nothing to anyone looking at it. But the QDC says, the domain controller says, okay, that's the right timestamp. Here you go, here's your ticket granting ticket. And what we have is this thing called your KRB TGT, your ticket granting ticket. And this is like your ticket to a carnival. I've paid money, I've gotten my ticket and then I use this ticket to show evidence that I am allowed into other things. When I wanna go on a ride, I show them the ticket. I say, please, please let me ride this thing. And we use the KRB TGT to get you a single sign-on to all of these other services. But that doesn't actually help your login. The TGT is just there to say, yeah, domain controller trusted that was your password, but it doesn't actually allow you to get any authorization information. And that's the critical piece here because the authorization information is what tells you what groups you remember. So when you log into your machine and I want to access certain folders, your certain files on my local machine, your group membership and your access control that can actually compare and say, yeah, I'm allowed to do that. But the TGT itself is encrypted to something that the machine doesn't understand. It's the overall is encrypted to your password when it's handed back to you. But once it's decrypted with your password and you're looking at it, you can't do anything with it. You can't look at the contents of it. It's encrypted with a key that only domain controller has. So how does that work? Well, I've gotten the TGT back and now I actually want to do something called a ticket granting request. And what we're doing here is we're saying, here's my TGT, I want access to this other thing, whatever that happens to be. It could be a file share or it could be your email or it could be a website or something. It doesn't matter what it is. It's just something that has a name. Please give me a ticket to it. But during the Windows log on, it's actually your local machine name. What we're saying is domain controller, I'm trying to log into this machine, will you give me a ticket to this machine? And we can take a look at that when we look at the request body. We can look at the service name and it's host slash desktop dash, blah, blah, blah, blah, blah and in my particular domain. And the reason for that is because when we go back to that TGT, we can't see the contents of it, but if we ask for a ticket to ourselves, we can, we're allowed to get access to the authorization information in that ticket. And so the domain controller responds and says, yep, I can do that, here's your ticket and your ticket is for this machine. And so Windows, once you've logged in, you've hit your desktop, you've taken your password, you've authenticated the domain controller. The domain controller has given you your TGT. Your TGT has been used to request a service ticket to your local machine. What happens there is your machine, when it was joined to the network, has a password, it's your machine account password and both your local machine and Active Directory both know what this password is and when Active Directory created the service ticket to your machine, that service ticket is encrypted to that password. So Windows has received this ticket, it's able to decrypt that ticket with that password and within that ticket is all of this information about you, it's your username, it's your group memberships, it's the profile path that's different flags about who you are, it can include claims information, a whole bunch of different things to describe who you are and what you're allowed to access. And then at that point in time, Windows uses that information to create your NT token and that NT token is your identity represented in Windows to access, to be identified by applications when they want to connect to other services using protocols like Kerberos or NTLM or other things. The point of Kerberos here in this case is Active Directory is proving to the local machine that one, it's the authority, so the local machine trusts Active Directory that what it receives is true and so when you type in your domain credentials, those domain credentials are authoritatively validated by Active Directory and that's what gets you to your desktop and it also gets you a single sign-on. So remember how I said you have your TGT from the original log-on step to get the service ticket to your machine. Those creds are kept in memory, I'm sorry, the TGT is kept in memory so that when you want access to other resources, you get whack-wack files here or you open a website to share a point or something within your network or you're accessing your email with exchange or anything that requires Kerberos, it uses that same TGT to get you access to it. So your creds in a domain join machine gets you to your desktop through the authoritative log-on or it allows you to use it for SSO and that's how it's worked for the last 20 years or so. So when we introduced Windows 10, we introduced this idea of hybrid log-on and this hybrid log-on is domain join plus clack and so you use your domain creds to authenticate against Active Directory to get you to the desktop as well as get you to SSO to your on-prem resources but then it also used the same credentials to authenticate against Azure Active Directory so that you have single sign-on to all of these other resources. So if you're using Office 365 or you are using Teams or if you're using a third-party application that uses Azure AD for single sign-on, all of this flows through Windows so that you can have the single sign-on experience. You open the browser and suddenly you can access all of these resources without having to type your password in again. That's pretty cool. And so if we go back, Herbarose has your password, it's done the TGT thing, it's done the service ticket thing. Well, how does it get that Azure Active Directory? What does AAD do? Well, Herbarose itself is not particularly aware of Azure Active Directory, it doesn't know what it is. It doesn't actually even know what Active Directory is for them and all it knows is it does Kerberos. So the Kerberos authentication package does this thing called the transfer of credentials and it's this special way of saying to other authentication packages, hey, I just did a log-on, I just received these credentials. Can any of you do anything else with these credentials? And that's how single sign-on works between authentication packages. One package says to the other, hey, I have these credentials, can you use them? Well, in that case, transfer credentials goes through all of the other auth packages and says, can you use them? And so who supports this process? You know, it goes through a couple. You know, there's multiple authentication packages for different, for myriad of reasons within Windows. One of them is the Cloud AP package, the cloud authentication package. And this is the thing that communicates with the cloud. And that is both your Microsoft account and Azure AD. It's the thing that gets you to cloud single sign-on. And Cloud AP itself is not aware of any particular protocol, but it does have this plugin model that says that, you know, I understand Microsoft accounts and I understand Azure Active Directory. And in this case, because it's domain joined, it's hybrid joined even, MSA is out of the picture, but it understands AAD. So it gets the credentials, hands it all the way through the auth packages to cloud AP and to AAD. And then the AAD plugin goes off and communicates with Azure AD using a protocol OA. And so why don't we take a look at what OAuth is? In order to communicate with Azure Active Directory, Windows is going to do OAuth. And OAuth is just an open standards protocol. It's HTTP based. It's very common on the internet today. And Azure Active Directory exposes it for both internal and third party applications. And so it's a no-brainer that we use it for logging into Windows. So I'm going to do that again. I'm going to log into Windows. And I'm using a tool called Fiddler to capture this information. But you'll notice there's nothing actually happening. And this is nothing. This is just, I think it's just checking for Windows update. But there's nothing going on. So how did OAuth happen? Well, I mean, the fact of the matter is the logon process for this OAuth protocol in Windows actually tries very hard not to go out to the internet to communicate. So it does something very similar to our cached logon flow where it says, do I have information already present on the machine to be able to log this user on? Well, in this case, we're not logging the user on. We're doing single sign-on. So if I want to go and get access to Office or SharePoint, Exchange, whatever, it needs to communicate with Azure Active Directory to get those tokens. But during logon, it actually doesn't need to do anything, which is kind of cool because it did it way long ago when I first logged in the very first time and things were just kind of stored there until I need to actually get a ticket. And so I'm going to cheat. And you can see that periodically, Windows will refresh this. So we don't want things to go stale. So every logon, we don't go check. Like we do with Kerberos, but with OAuth, we only do it every few hours because we know that your token's gonna be good. And if you don't have a token, we'll go and get it. But if we take a look at it, there's not a whole lot going on that we can actually look at, but it's just straight OAuth, the information in there. What's happening is we're doing what's called a PRT refresh. It's your primary refresh token, which is kind of analogous to your ticket granting ticket. When I want to be able to access other services for single sign-on, I exchange this PRT for this other token. And what's going on here is we're just refreshing it. We're saying, well, I have this stale one, I want to get a new one. And this happens every few hours instead of every single time you log in. And that's all there is for OAuth. When you log into Windows in a domain join system, it doesn't do OAuth. When you extend the system to support single sign-on for Azure AD through hybrid AD join, then you get access to this OAuth protocol and it'll authenticate to Azure AD. I talked previously about the different kinds of credentials that you can use. I've been using a password for all of these demos because it's very easy to show how it flows all the way through the system. But Windows supports multiple types of credentials, obviously passwords. It supports Windows Hello. For Windows Hello, that's things like facial biometrics where it takes a template of your face and it uses that to compare against the local copy as well as fingerprint, which works fundamentally the same way. It takes a scan of your fingerprint and it compares against it locally. But the cool thing is that it actually stays local. And I'll explain that in a second. We also have FIDO, which this is just one representation of it. But the idea is that you can plug it in, you can tap the button, you type in a pin and you have a secure authenticated credential that you can use wherever you want if you have one machine or if you have a hundred machines that you need to log into. And then of course there's smart card, which kind of works the same way but different implementation. And the way that you use these credentials is sort of dependent on the type of authority that you have for this machine. If it's a work group machine, you basically have password and Windows Hello. And Windows Hello on a work group machine is not fundamentally how it works with the main joiner Azure AT, but it still uses the biometrics with the pin. And then you have your Microsoft account, which is very similar. It uses your password and it uses Windows Hello, but the authority is Microsoft Windows Live Services and then domain join, which supports password, Windows Hello, FIDO and smart card. And then Azure Active Directory join, which supports password, Windows Hello and FIDO. And so the way that Windows Hello works when we're looking at the list of credential types, Windows Hello is a way of protecting your credentials so that they are localized to a single machine. What do I mean by that? Well, if I use my password on my machine, I can also use that password on another machine. And the downside to that is if I can use this password on another machine, so can someone else. So if someone steals my password, they can go use it elsewhere. And that's kind of dangerous because these days you have lots and lots of breaches through third parties that leak your credentials and people have a tendency of reusing those credentials. I do. I don't like to, but I do. Everyone reuses credentials, uses. Everyone reuses passwords from time to time. It's just human nature. Passwords are difficult. They're complicated. They're annoying. Password rules are even worse. So we reuse them. Windows Hello does away with that by relying on biometrics or PINs to unlock credentials that are stored only on your machine. So when I get up in the morning and I log into my machine, I use Windows Hello to unlock. What's happening is I've woken up the machine, my camera pops up and the camera takes a picture of my face. And that picture is sent to the authentication subsystem and it says, I have this picture of this person. Do we have this person on record? And the way that comparison works is fairly complicated. It's doing some fairly complicated analysis of whether or not I am actually physically there versus whether or not I am a real person. Also make sure that I'm alive so that under seriously, under conditions of duress, people aren't trying to scan my face without my consent. And what's happening is that scan is, that comparison is done against the local copy and that copy produces some specific data and that data is passed to your machine's TPM, the trusted platform module, which is a cryptographic module stored on your motherboard, which stores keys. And between the TPM and this information coming from the sensor, it computes a special key. And that special key is used to decrypt another key that's stored on your machine. So if we take the TPM out or if we take the camera out or if I am indisposed, the thing that's stored on your disk is not usable. You can't do anything with it because you need all of these different pieces to compute a specific key to decrypt this other key. And this other key is the thing that unlocks your machine and it's this key that authenticates you to Active Directory or Azure Active Directory. And so the value there is that this key only lives on this one machine. When I go to another machine, there's another key. And if I go to another machine, there's another key. And so unlike a password, you can't just pick it up and move it to another machine and have it just work. You actually have to physically register. You have to be present in order to scan. If you're using your fingerprint, you actually have to physically touch it, that sort of thing. And so the risk of breaches of passwords completely goes out the window because you're not using your password anymore and you can't take it from one machine to the other, which is pretty cool. And that's a really important point, Steve. And I think I almost feel like this is a myth busting session because I know that when Microsoft first announced this and people are getting used to being underlogged and with the camera, there is maybe a perception that we have this big database somewhere with everybody's photos in it and we're doing facial recognition against some giant database. So it's amazingly here, all the internals behind us. No, no, no. This is all happening locally on your machine and only on your machine. Correct. So we do not in any way shape or form take your biometric data, whether it's your face, your fingerprint and send it to Active Directory or Azure Active Directory. It all stays local to your machine. It stays, and even more so, we've actually recently introduced this technology called Enhanced Sign-On, which actually limits the places where the biometric information goes. There's this whole, I will include a link for this technology, but the idea is that we're relying on another technology called virtualization-based security, which is an entirely different presentation, which we should totally give sometime in the future. But it's this idea that all of this biometric information is processed in an entirely separate virtual machine on your local machine. So your regular Windows OS, all of the programs running on it can't actually touch that data. And so we're making it even harder to get access to this biometric data, which is pretty cool. But also, that's why when we talk about Windows Hello, we do include the concept of a PIN. And we, a lot of people like to say that, well, PIN, it's just like a password. You know, I still got to type it onto a keyboard. It's only eight characters. Well, part of that's true. Yes, you got to use your keyboard. Yes, it kind of serves like a password, and you can make complexity rules. So it's harder for people to guess. But at the same time, it doesn't have the same security characteristics of the password, because the PIN I use on one machine is not the same PIN that I can use on another machine. I log in with PIN A on machine A, I log in with PIN B on machine B. So the risk of using a PIN is completely different than the risk of using a password. That's not to say that there aren't risks if you're in an environment where people can look over your shoulder and see you typing in, and they have unfettered access to your machine. Yeah, that can be a problem. On the other hand, if you're using biometrics, if you're using your fingerprint, or if you're using your face, they can't feel that. It's a lot more difficult to bypass, which brings us to FIDO. One of the drawbacks to Windows alone is that it's originally designed to be one user, one machine. This is my machine. This is the machine that I use every single day. And if I can help it, no one else touches it. So Windows follow is perfect for me because I log in every single day, and it only has my account on it, and it's an incredibly fast process. I get to the desktop really quick. But what happens if I'm in an environment where I need to get access to multiple machines? I'm on a shop floor or I'm in a shared workspace or I'm hot desking, something like that, where I don't necessarily log into these machines every single day regularly. Well, if I'm logging in with Windows Hello, that means I have to go through a onboarding registration process. That's how it scans your face and just use your fingerprint. It records your pin. And that can be a relatively lengthy process every time you wanna sign in. And that's not great for a lot of users. So we added Fido, which is fundamentally a more portable version of Windows Hello. And what I mean by that is we have extracted all of the technology that you use to log into Windows Hello, the biometrics, the pin, the internal authentication mechanisms and built it in such a way that you can use third-party hardware keys to log in. Fido itself is a industry standard where it's not a Microsoft-only technology. But it is natively built into Windows so that if I need to move from machine to machine to machine, I can log in with a single key. So I plug the key in, I tap it, I enter my pin and I can get access to the desktop really, really quickly. But the implications of that are that means that the credential used can be stored directly on this device. So it's not like I'm typing in a password and that password is verified against Active Directory or Azure Active Directory. It is, I type in my pin or I tap the button and actually there are different manufacturers where if you have something like this, they have a fingerprint scanner on there that when you tap it, it'll verify your biometrics of your fingerprint before it'll unlock the key. And that's what it does. It unlocks a key that can then be used to authenticate yourself to an authoritative service. And in Windows, we rely on Azure Active Directory for that. So how does that work? So we're back to LSA. Remember, everything revolves around LSA because it's the security authority. It's the thing that dictates whether or not you're allowed to do anything from a security perspective. So I've plugged it in. There's a FIDO credential provider. I've tapped the button. It's gone through all of the things and it's sent this information to LSA to say, hey, we're doing a FIDO log on. What can you do about it? And again, LSA doesn't really know what a FIDO log on is. So it needs to ask the auth packages and the auth packages go through its own process. One of the first things it does is this happens on every log on, but it only applies to FIDO. What happens early on is it says, can you do this thing called a pre log on circuit? And what that basically means is, before you actually log on to the machine, do this other thing. And it's a way of preempting the authentication process. And then Cloud AP says, oh, yeah, I can. I know what this pre log on circuit is. And oh, by the way, that's a FIDO credential. I know what that is. I can do something with that. So Cloud AP does the authentication dance with Azure AD using the FIDO credential. It does this back and forth thing. And then it passes this information all the way back up to the negotiate. It goes, you know, this whole exchange process of I have this result from Azure AD, please hand it to negotiate. And the reason that we do it that way is because Active Directory itself does not understand FIDO. But we want you to be able to log on two windows on a domain joined machine with FIDO. So how do we do that? Well, we use this pre log on circuit to say, can Azure AD actually fulfill this log on for us with and then have Azure AD provide this additional information? So what's actually going on under the covers is Azure AD means something called the read only domain controller ticket granting ticket. It's an awful name. It's very complicated. But the short description of it is it's kind of like your regular TGT, but it's very narrow in scope about what it can do. It doesn't have the same access as a regular TGT. It doesn't have any of your group membership. All it's doing is saying this other authority is trying to prove to Active Directory that your users, whoever you say you are and Active Directory can either decide, do I want to trust that or not? And so Azure AD is returning this RODC, this read only domain controller ticket granting ticket to cloud AP so that it can be passed up to the negotiate package and that information gets passed through the normal process. And eventually it gets to the Kerberos. We're doing this online log on thing. Kerberos needs to go talk to the domain controller again, but like I said, Active Directory doesn't understand FIDO. So it has to rely on this RODC ticket granting ticket coming from Azure AD to log you on. And so Kerberos hands this information to the domain controller and the domain controller says, I do trust this. I know who this user is. I trust Azure Active Directory. So I'm going to mint a TGT on behalf of this user and return it back to the Kerberos stack. And then NTLM is ignored. The value here is that we can use stronger authentication credentials with your existing on-prem Active Directory infrastructure with just a few configuration tweaks. And all of that's well and good and that's how domain joined and hybrid domain join log on works. But we have this other thing and this other thing is called Azure AD join. And the idea behind it is that instead of going to your domain controller to authenticate you, we're first going to Azure AD instead. And the way that that works is fundamentally the same process. So if I lock my machine, I'm at a lock screen. There's my credential providers, my password field. And I log in. It's done the same thing. It's checked the cache. It's verified that that password is still good. You've gotten to your desktop. And now unlike domain join, instead of doing Kerberos, we're now doing, oh, but remember the implementation is that we don't need to do all on every single log on anymore because we've cashed this information. And so when you log into Azure AD, it doesn't do anything to communicate with the cloud anymore until you actually need to access the resource. So offline log on is incredibly fast. There's no requirement for getting authorization to information from Azure AD. All of that information is present at the time of accessing a resource. So if I were to go to open my mail or open up Office or SharePoint or a third party, all of this happens way later on, regardless of whether or not I've logged in now or an hour ago, log on itself doesn't do anything until I need to hit a single sign-on resource. But what about when I need to access on-prem resources? So this is sort of, we've flipped this process. Prior to Azure AD join, we had Active Directory as your authority. So that means we had to do Kerberos and that got us to the desktop and got our Kerberos single sign-on. Azure AD flips that and it says that Azure AD credentials are the thing that gets you to the desktop. And then once we've logged in, we use those credentials and actually communicate with domain control so that we can then do single sign-on for Kerberos. So I'm on an Azure AD joined machine and you'll trust me that the name actually represents the real instance type. And when I've typed in my password, I've just done OAuth, which in this case isn't doing anything. But the critical point is we're not doing Kerberos to get a device token to the local machine to get our authorization information. However, we open up Wireshark. We're using Wireshark as a way to show the traffic. When I log in, we do see Kerberos, which is kind of an interesting situation. So with Azure AD joined, I can access cloud resources and I can access on-prem resources. But the value is that the machine itself is not to be enjoyed. It doesn't have a workstation account. It doesn't have that password. It's not registered in active directory and it's all managed from Intune through Azure AD. And so the value there is that it's a lot less to manage, it's a lot more lightweight, but at the same time, you also get the benefit of having single sign-on to your cloud resources and your on-prem resources without a whole lot of effort. Anyway, so that brings us to some questions that I asked the community to, I'm giving this talk on hybrid identity and what do people want to ask about this process because we're doing this in sort of an asynchronous manner? And so one of the first questions that came up is actually a really good one is, well, we have this on-premises active directory environment. Do we need to keep it? How long do we need to keep it? Should we keep it? That sort of thing. And the answer to that question is sort of dependent on a lot of different factors and that the short answer is it depends. There's no single answer. And more importantly, this is not something that we can answer for you. You kind of have to make these distinctions yourself. And so some of the questions you need to be asking yourself are, are you in a place where you can migrate your management processes to a MDM service? Like Intune, there's also third parties. There's AirWatch and other vendors out there that support this natively. Are you ready to move to something like that? That's your first question. The second question is, what are the applications that you're using within your environment? Do you have an inventory of them? For that inventory, are they running protocols that are not available in Azure AD or NTLM? Or secondary processes like SQL that still require secondary services that are on on-premises like SQL Server Reliant and Kerberos and things like that to log on? One of the things that I remind people of when they say, how soon can we get rid of our domain controllers is that we still have Wins server in 2019. And we said that we were getting rid of that in 2000. So, you know, your domain controllers. And Steve, I'd love to do a blog question or an article with you about this particular question. Cause I know that it's one that comes up quite a bit. I think it's also a sign of the fact that our customers, we say this one term, but our customers are so varied. So, while we think of the complexities involved for our larger enterprise customers that have had AD with such a history and a lot of application dependencies, we've also got smaller like SMB customers that are only five staffs maybe and that's their entire business. And we've got new businesses that are starting up that have only ever been cloud native that have never had an on-prem server. And so that it depends is not only it depends on the complexity of your environment, but our customers really are that different night and date and different ends of the scale about their size, their requirements, their complexities. And I think that definitely feeds into why it's, it depends on the answer. Yeah. And the, I think the takeaway is that, is that we are not in charge here. It is your environment. You own it, you manage it, you run it. You tell us, we're happy to help you. We're happy to do everything we can to make this an easier process for you. If this is a process that you want to go down because that's the other piece. Sometimes customers are hesitant to move to the cloud, whether that's in a hybrid or pure cloud. Sometimes they have reasons for staying on-prem and they're totally valid reasons. So if you have more specific questions around how do I migrate application A to the cloud or how do I skip this process or how do I get rid of this process in my environment? These are questions that we can help you with. And so question two, FIDO. We're back to this thing, MFA and FIDO. How do we apply this to normal logins for AD as opposed to applications that are web-based or more modern based authentication protocols? And the answer goes back to hybrid. Now, when you are logging into Windows with a FIDO key, you can absolutely authenticate against an on-premises Active Directory environment. There is a dependency on Azure AD to make that work because on-prem Active Directory doesn't understand the FIDO protocol. But once you've logged in using your FIDO key and you've done that exchange with the domain controller, it's still pure on-prem. You're still doing Kerberos, you're still doing NTLM. And any of the applications that have historically relied on Kerberos and NTLM get the benefit of FIDO. Now, one of the things that I didn't mention is that for the MFA component, FIDO itself is naturally an MFA credential because it genuinely supports multiple factors for authenticating you. I plug it in and I tap the button. That's a single authentication factor. It can prompt for a PIN. So I have physical plus PIN, something I have, something I know. Or instead of PIN, you can do biometrics. Like I said, there are hardware companies out there that have biometric keys that you can use for that. And so fundamentally, it is already a multi-factor key. However, was that Windows Hello is also a multi-factor authentication credential as well because it is also something that you have which is your physical machine. It is a physical piece of hardware. It's a laptop or if it's your desktop that you have that physical piece plus whatever the authenticating factors which is your biometrics or your PIN, you can't authenticate with either. You have to have both. And so you definitely get multi-factor authentication out of that as well. And if you are looking to do Windows Hello, you don't require Azure AD. You do, you can deploy a on-premises only deployment or you can deploy a hybrid deployment of it or you can do cloud only of Windows Hello. And there are different flavors of Windows Hello for deployment types. And there's a whole bunch of different ways that you can make it work which is a great way of introducing multi-factor off in a way that customers love because it's so incredibly easy to use. And one of my favorite questions is when will we finally get rid of passwords once and for all? This is another, it depends answer. And the reality of it is that we probably won't get rid of them entirely. The reason for that is because passwords do play a very useful role in authenticating users for a couple of different reasons. In the first case, they are potentially very easy to use because you hand someone a piece of paper and says, here's your password, type it in, and you're done. The least common denominator for between users and computers is something that the user knows in their head which is a password or something that they've been given that they can type in. And so there is some utility in keeping passwords around for certain scenarios. But the crux of it is really more about when can we get rid of passwords as the primary authentication mechanism? So when I log into my machine every day, do I have to use a password? And when I'm logging into Azure AD to get access to my email or I'm on my phone and I need to be able to get access to my SharePoint app or anything like that, I'm still using a password, at least password plus MFA on my phone to approve it. And one of the advantages of getting mostly rid of passwords is that we could dramatically increase the complexity requirements on passwords because people aren't using them on a regular basis. Oh, absolutely, yeah. As soon as you take it out of the primary purpose, you can do all sorts of things to make passwords actually secure to use. Because there are secure ways you can use passwords. They are just counter to user experience and the ability for users to actually remember them. And so, we have a whole process for how do we get rid of passwords? And it's a multi-prong process. We need to make sure that all of our services and all of our applications at the very least understand other types of credentials. And Windows is doing a phenomenal job of making it easier to use other credentials through our credential provider technology, through the LSA stack, all of that. We're making it a lot easier for these credentials to be used in place of passwords. And so, that's the first one. And then getting customers to the point where they can actually regularly use these other technologies in place of passwords is another way. And then eventually we get to the point where we are at a place where all of our directories just don't contain passwords at all. They just don't exist. So there's no way for you to use a password unless you're in very specific situation. It's really interesting to balance that human impact. I've had conversations with people where there's even a hesitation about rolling out MFA if an MFA is going to rely on using a phone, whether it's preferably for the Windows Authenticator app and the ejection comes up of, but we don't provide a phone for our staff and our staff aren't willing to use their personal phone to do what's perceived as a business function. So it is really interesting when you start to get into that balance between what technically we can do and how you break through that user acceptance and some of those business challenges surrounding what is a better security practice. And actually those go hand in hand quite a bit. The technical things that we build are primarily driven by the things that customers are willing to do. One of the things, so one of the questions I get asked somewhat regularly is, why can I not log into Windows with my mobile authenticator? And the answer is, first of all, because for exactly as you said, customers are not necessarily willing to provide a phone in the first place. This is my phone, why should I let the company manage it? Why do I have to install it as that sort of thing? And those are valid reasons, but some of the others are also more about the experience of it. Well, if I'm in a remote location and I need to log into Windows and I don't have cell service to be able to communicate with a cloud authentication provider, well, I'm stuck, right? So we have to balance the willingness of customers to be able to use the technology as well as the experience of, will this work if it doesn't work? The experience of, will this work in all of their situations? Anyway, that's my presentation. Thank you very much. I hope you enjoyed it. If you have any questions, feel free to reach out to me. We'll be providing some links to resources as well as copies of this slide deck and whatnot. Thank you. Absolutely, thank you so much, Steve, for your time. It's just mind blowing to see how far we've come and how quick the process is considering how much it's actually doing under the hood. And I think it's maybe broken a few perceptions about what happens in that process, in that timeframe. What do you think, Oren? This was exactly the sort of content that I absolutely wanted for this event. So thank you very much, Steve. You've actually gone deep and it's exactly what I think our audience wants. And I think there's a lot of people out there in the internet land who are actually gonna sit there and go, yes, this is exactly what I needed to know because no one's telling us this sort of thing enough about how this works under the covers. And it's not just a matter of having this mystery box that we don't know how it works. So thank you very much for sort of explaining that. And I learned, again, just understanding that the way to get Fido with ADs to use hybrid, that's something that I wasn't fully cognizant of. Yeah, and the unfortunate thing with these presentations is you kind of, you start calling it a thread and suddenly you go down a particular hole and you can spend hours, hours and hours and hours looking at a particular piece of this. And I would love to be able to give a presentation on just the Fido component because there's some really cool things that we do there that maybe a hundred people in the world would find incredibly interesting where it and everyone else would look at that and say, well, that's cool. I like the fact that I can use Fido to log into Active Directory, but I don't really care about how this ROTC thing works. Well, I'm gonna make a note of that because we might actually call on you to do that presentation at a future event as well as your virtualization-based security idea. So, you know, never say never. Absolutely, absolutely. And if you enjoy the presentation today, if you wanna come and chat more about all the things that Steve mentioned, come and join us at aka.msfordslashops108-chat where you can come and join our Discord chat channel. And if you'd like to find more information on this session and all the other sessions in our IT ops talks or through hybrid events, come and see us at aka.msfordslashITopstalks for all of the sessions in this event. Once again, Steve, thank you very much. We know that it takes a fair amount of preparation, put something like this together and appreciate your time today. Well, thanks for having me, I had a lot of fun. Awesome, fantastic. Thank you very much.