 Hey folks, welcome to Windows Server Engineering Summit. Today we're gonna talk about the evolution of Windows authentication. My name's Ned Pyle. I'm a Principal Program Manager in Windows Server. And the agenda for today is the future of NTLM, what's new about Kerberos and what our plans are. This is all around Windows Server 2025 and Windows vNext. So what is NTLM? It's a legacy of 25, 30 years ago of the 90s. It includes LM, NTLM, NTLM v2. Whenever I say NTLM here, I'm really referring to all of them. Generally speaking, people are using NTLM v2 these days, but it's just too much of a mouthful. It's a challenge response protocol where you have a server and the server says, who are you? And the client says, I'm me and here's a little bit of proof. And the server says, oh, okay, I'll let you in because we can agree that I know what your proof is and who you are. And you can do NTLM directly, like between two machines, or you can have it forwarded on from a target to say a domain controller. So if I've got my laptop, I'm talking to a SQL database running on Windows here, I'm doing NTLM directly with it potentially, or if I need some active directory credential, I'm also being forwarded by that SQL server onto AD and back to that server and then back to my client. So what's so bad about NTLM? It's a weak protocol. So we go back to that situation of the server challenging and that client is being forced to use a password and only a password and not a particularly strong set of architecture that goes along with that password. So an evil listener can say, hey, thanks for this challenge response. I'm gonna use that to go be you, for example, and not even understand what the password is. It also has very weak cryptography. So when the server says who goes there, the client is saying, it's me and my proof is extremely weak. Here's my MD for password encryption scheme. And then the evil person says, well, thanks for this password that I could probably break pretty fast. It also doesn't have any concept of mutual authentication. So the servers you're talking to are completely untrustworthy which means there are things like relay attacks and ability for impersonation to occur and there are bugs in NTLM. What's really wrong about all this? Take password length and the amount of time it might take to break that password. So if I sit there and pump 122 terahashes a second which nowadays is not a difficult proposition or even a particularly expensive proposition over the course of this time and this length of password, never mind the complexity, just the length. 12 character password, it takes quite a bit of time. 11 character password is still reasonably safe. 10, nine, eight, instantaneous on seven or fewer characters. I mean, these are very reasonable amounts of time where you'd be patient enough to go and get a password and then use it for evil. And so if it's so bad, why is NTLM still being used? One, it's very simple, it's very easy to deploy, it's very easy to code for. It is often therefore hard-coded into applications where they could use other protocols but they specifically hard-coded NTLM, either through ignorance or that simplicity piece. It can be used very easily by accident. For example, in an active directory environment, if I specify an IP address, there's no way to look up a service principal name and I will use NTLM and there's nothing you can do about it. Talk about how that's not actually true but generally speaking, you're gonna get NTLM just by using an IP and you didn't know, it was just an accident. Or it's required by the environment. You don't have domains, you don't have Kerberos, you're operating, say, in a work group and so when we try to negotiate, there's no other choice but NTLM. So when does that force us into NTLM? Unknown server. I don't have a way to figure out an active directory, for example, what a service principal name is. I'm using a local user account right now in the world of Windows today that means NTLM is the only option. I don't have line of sight to a domain controller. There's no way for me to contact a domain controller and use Kerberos or it's hard coded in the application. Those are the four main reasons and this is telemetry. It shifts around a little bit from week to week, these numbers aren't exactly precise but they could be a pretty good idea of what the story looks like overall. So that all seems pretty bad, right? Well, I'm here today to talk about what we can do about it. So what's first off better than NTLM, Kerberos? Kerberos is better and Kerberos is introduced to Windows a long time ago and Windows 2000 in active directory. It's been the primary protocol and since 2010, it's been the one that all Windows developers, all Windows applications, we've recommended that you use through the negotiate process. It is a ticket based system and which means that it's using bits of proof and keys and tickets to pass around information. There's no longer hashes, unsalted hashes for example. So if I take my laptop and I've got a domain controller and I've got something I wanna get to in this case a SQL server running on Windows, my laptop talks to domain controller and back to me to get proof of who I am and to get access to a ticket for me to go talk to that SQL server. I'm not being forwarded along. There's mutual authentication occurring here. It's a very safe and tried and true system. It scales extremely well and it's been sort of our gold standard now for 25 years and it's used throughout the industry. So what's good about Kerberos? It's got very strong crypto. That means crypto agility, the ability for us to swap out older, less safe crypto, cryptographic suites and swap in newer, more modern ones. So for example, in the last couple of years disabled using our C4 because it had no longer become safe to use. And that gives you the ability to be what post quantum computing resilient, right? So you could say as the cracking power of quantum computing increases or becomes generally available, our ability to swap out the crypto helps us negate that things effect. It is mutually authenticated. It isn't just passwords. So you can use smart cards, certificates, Windows Hello for Business, Fido, Fido 2, all those things can be used instead of just plain old, boring old fashioned passwords. It's extremely interoperable, extensible, IATF standardized, Kerberos really is the way to go. Oh, and it's delegatable, delegated. So I can set up things where Kerberos is done on my behalf safely by trusted devices, something which NTLM cannot do. So NTLM seems bad, Kerberos seems good. How do I get to the point of using Kerberos for everything? How do I as a running an organization get myself out of this NTM situation? And so we've provided a large number of new capabilities in Windows Vnext and in Windows Server 2025 to take care of that. So we're going to start phasing out NTLM and using Kerberos more and more through a number of things. One is called IATURB, one is local KDC, one is IP to SPNs, and one is making NTLM less likely to be used or instead have negotiate step in. And why would I, what would be the situations of this, the scenarios and when I would use each of these? So if I don't have line of sight to the KDC, to the Kerberos key distribution center on the main controller, I can use IATURB. If I'm using a work group, local authentication, I can use this new local KDC. If I'm using IP addresses for some legitimate reason, an application requires it, I can now add IP addresses into the SPNs. And if I'm using any sort of hard coded or unnecessary NTLM, there's some techniques we can use to identify those, fix or block that from occurring and move into the recommended negotiate way of doing security. And so let's go through these. So what's IATURB? This is all that you might not have heard of. It's initial and pass through authentication. The IA is sort of a weird acronym for all this initial and initial authentication, whatever. But it really is still just Kerberos V5, it's still GSSAPI. And you can think of IATURB, it is a security package in the existing negotiator, security package negotiator of Windows. And so you need an updated client and an updated target to use IATURB. You don't need an updated domain controller. Any old domain controller will do. And so Kerberos really doesn't change very much here in how it actually operates, but we are modifying some of the fundamental ways that ticket exchanges happen. And that lookups occur. So under the covers, you still get the standard Kerberos tickets, but they move in a slightly different way. And I'll actually show you a demo of this in a second. And what it does is it's forwarding Kerberos through the target to a domain controller. You don't need line of sight from the client to the domain controller anymore. As long as the target has line of sight and the client can see the target, you know, your SQL server, your file server, whatever, then that's good enough. So let's see how this would look. I've got my laptop. I've got a domain controller. I've got the thing I wanna get to a SQL server, right? So with normal Kerberos, I would send along a ASRAP and an ASRAP. I would do my first conversations with the domain controller back and forth to get a ticket granting service ticket for my target. Now, if that's blocked, like for example, my laptop is on the internet, there's no way I can get to that domain controller directly, right? That's blocked by firewall. But with iCurb now, I can talk to my target server, which is in an edge location, let's say, the DMZ. It can talk to the domain controller. I can't talk to the domain controller, but it can talk on my behalf. So when I send my AS request and I get my AS reply that passes through that server back to me on my laptop. And the same thing happens for my TGS request and reply. And then when I go to do my usual AP to that server, which I have live site to, that now works. And so you notice here how I didn't actually ever talk to the domain controller directly from my laptop. That's how iCurb works. Let's see this thing in a real demo here. So I'm gonna just map a drive here because I don't have SQL servers lying around, to this server using a domain credential, okay? And I have blocked at the firewall my ability to connect to that server. So I'm just mapping a drive. So what is that server? It's this .59 machine and this 101 machine is my domain controller. So here's 59, here's 101. Notice how the conversation is happening between my target server that I'm on right now, you saw, and the domain controller directly. It's not between the client and this domain controller. Otherwise I wouldn't see it in the wire chart capture, right? And if I look at the actual SMB connection, only then is it between me and the target. And so I've mapped my drive and it all worked with Kerberos, even though I couldn't get to the domain controller and I can see stuff, access data, see my little picture of Kerberos, isn't that cute? Then there's local KDC. That means local users and groups get Kerberos now. A KDC without a domain controller, a KDC without a domain. It's on top of the security account management database, the old database of the local authentication in Windows. And it still requires an IECURB enabled client, right? Because there's no service principal names, there's no DNS and this could be me in my living room talking to a laptop on the other end of the couch. But that means that no longer using NTLM for work groups, for local remote authentications with local users. And this is something we wanna make sure is open standards interoperable so that we can talk to other types of devices that aren't Windows in the future using this local KDC thing. Either they could be NAS devices, they could be appliances, they could be other operating systems. We wanna make sure this works for everybody so that no one's using NTLM. So how do I see this in action right here by my laptop? I'm talking to a Windows server. I have IECURB here to help me figure out like, oh, this isn't a domain, but this is local and I wanna use a local user account. And my entire ticket exchange happens just between those two machines. As if the Windows server SQL box was a domain controller, but it's not. It's just another server and a work group for me. This would even work between my laptop and another laptop, like in a complete consumer scenario with no setup, no nothing required. It just happens automatically. So let's see how automatic it is in my local KDC demo. So here I'm on a server and you can see I've got a local user called local admin. And I'm running this new Kerberos local key distribution center, local KDC service on here. That's all it takes. No other configuration is going to happen right now. I'm just gonna try and connect to it from my client. So I'm gonna map a drive over there to it. And you'll see as I map again, this is that same share I was using before. But this time I'm using a local user account, that local admin we just showed. And once I map that drive, notice that my entire conversation happens here directly with that machine. And my Kerberos conversation is happening at all, right? Because if this was the past, if this was the old days, this would all be NTLM because I'm in a work group using a local user. There is no Kerberos, right? With local KDC, there is. The next thing we can do is make sure that when we're using IP addresses, we intentionally set it up so that they can still use Kerberos as well, which does not happen by default, right? Right now a service principal name, inactive directory for Kerberos gives you a DNS, FQDN, a NetBIOS name, a service name, and no IP addresses are ever set. You can make your clients use IP for Kerberos. This has actually been around since Windows 10, but it's not something you might have heard about. So there's a registry value you set in your Kerberos clients. This value right here called try IP SPN, hence the name. And then you set SPN, you add the IP address on to whichever machines inactive directory you want to start using Kerberos with IPs. And that's all there is to it. That's the entire process. You figure out some machines, some applications that are using IPs, and there's nothing you can do about it because the real solution is not use IPs. And so you have got these IP addresses you've gotta use. You specify those with set SPN to actually have service principal names and you put this registry value onto all your systems and that's it. There's an article on this over at aka.ms for slash try IP SPN, it's not even that long. This steps on the screen here, effectively just about all the steps, it's pretty straightforward. And then the last thing, and this is the hardest thing, is switching to negotiate, to stop using NTLM intentionally when all of these things, even though these things are available, you are still basically hard coding NTLM or allowing NTLM to be chosen. So the ways to take care of this, one is to upgrade applications. Applications that require NTLM, there's nothing that can be done unless they're upgraded and told not to do it anymore. You can stop hard coding. If you're writing applications, you've got line of business applications. If your company is developing applications, your organization, stop hard coding NTLM there. You can also block NTLM. You can block NTLM in a few different ways, but one modern way, a new thing you can do in Vnext and Server 2025 is blocking it specifically out of negotiate. The first example of that is SMB, which is, you might've been wondering why me, Ned, the SMBPM is here talking about a Kerberos content, but I actually, I've worked on this Kerberos stuff quite a bit along with that team because we specifically added functionality together to make it so that apps and drivers in Windows can say like, yeah, we're gonna use a negotiate, but we're not gonna allow NTLM to happen, even so. And so what we did was we plumbed this value along with the Windows security team into the local security authority, LSA piece of Windows. And you can control it for SMB with PowerShell, Ker policy or the mapping tool. So for example, if I want, I could map a drive and say, don't ever use NTLM. I can also set a group policy that says, no matter what, when you do SMB, just use negotiate and no NTLM. And if only NTLM's there, then just don't connect, like that's just too bad. And I can also set it through just a global setting. So right here on this client configuration, on this machine, if I was to set to stable NTLM to true, for SMB, notice we're in the SMB client configuration PowerShell. That means that no matter what, if somebody tries to make me use NTLM, I get sent a strange email from somebody with a UNC path. And I was to click on that email as an unsuspecting user, because that strange email came from an evil person who was trying to get me to send that challenge response that we talked about up front. Remember the challenge response where my week MD4 password unsalted would be sent along, which they can then plug into some GPU array to break in two hours. With this way of doing things, my hash would never leave my box. NTLM would never be admitted, and there would be no concept of SMB being able to be told or forced or tricked into sending along NTLM password information or hashes for replays or anything. It's just not gonna happen anymore. And with this, you can do things like set exception. So, the first thing people say is, well, I've got some NTLM that I might need to use for SMB. I've got this old NAS box that only does NTLM. We're in the process of migrating off of it, but I can't right now. What do I do? You can still set exceptions in this particular setup with SMB to say, well, I won't do NTLM to anybody except this machine or this set of machines. And then you can specify that in group policy and in PowerShell, and that'll give you some wiggle room. Well, the goal of security isn't to like have an all or nothing zero sum of safe or unsafe, right? There's no such thing. There is a degrees, levels, defense in depth, and trying to remove as many easy and then progressively harder ways to compromise the system. And this is a big one right here. SMB's been abused for some years as a way for relay attacks and past the hash attacks and credential attacks, just because it was highly available and ubiquitous and constantly in use and very easy to get to because you needed SMB to copy files and open shares and pump data around. And there's also been, since Windows 7, if you really look back into some extremely old Ask DS articles from me from 12, 13, 14, 15 years ago, you'll see talking about how to block NTLM the old way. So you need to first think about the audit and analysis options. If your plans to go through and start hunting down this hard-coded NTLM or use of NTLM in your environment, you've got some tools. One, we have several policies, security policies, where you can audit incoming NTLM traffic and you can audit NTLM auth in the domain. That way you can see who's doing NTLM. Start just running that on all your machines, all your servers, even on your clients and definitely your main controllers and figure out where is NTLM coming from and start building up an inventory of things which are accidentally using NTLM versus intentionally or perhaps inexplicably using NTLM, the need investigation. And you can also use network captures, process monitor and some new options here that I can't talk about yet that are coming into the auditing space of Windows to further identify who is emitting NTLM. So you can go back and see if they must. And then you get into the option of blocking. So all those things we did there that allowed NTLM to be converted into something where it's gonna use Kerberos instead, you still wanna be able to block NTLM so it does not accidentally emitted or used for evil. So you can restrict NTLM inbound, NTLM in the domain and outgoing NTLM to remote servers with these policies, which go back, like I said, to Windows 7, every version of Windows that you're running, hopefully, can do this already today. And like I showed with SMB and that new way of doing things, you can also set exceptions. So you can restrict certain remote servers for specific servers and exceptions in this domain to allow NTLM, just in case you've got scenarios where hard-coded NAS box, you can't get out of that NAS box, it's got too much data on it, it's gonna be a while before it can be replaced. And you still wanna be able to connect because you've got a business to run, you've got an organization to keep going. But you've minimized your footprint. Your down to just a handful of machines using NTLM and the rest, because they don't need to, aren't. And that means we're talking about Kerberos for all, Kerberos for everyone, the ability to live in a world of negotiate where Kerberos is the primary and the first thing picked and there's nothing else picked. Meaning that NTLM is being deprecated. What does that mean to be deprecated? That means that you're only gonna be able to get security bug fixes. There's not gonna be any improvements, work, anything done to make NTLM better in some possible way because we think what's better is Kerberos than negotiate. It's not gone. NTLM is not gone in Windows Server 2025 or Windows V Max. Deprecate does not mean remove. Deprecate just means no longer being worked on and it's going to leave at some point. NTLM still works, NTLM is still supported. If you call and say I'm having some problem, I can't authenticate, I'm using NTLM, no one's gonna hang up on you. You still get to use NTLM for any necessary usage. But it marks the beginning of a campaign. That campaign is for us to, like here, inform, let you know what's going on, let you know what's coming in the next version of Windows and that the NTLM is not long for this world and then start to reduce your usage over the next few years, reduce and reduce and reduce down to what's necessary and then eventually end that usage either through our technologies like adding iCurb and local KDC, your things like removing hard coding from your apps or upgrading things until the point where you no longer have any NTLM. This might seem like it's insurmountable, right? I can tell you as somebody who worked on the SMB1 campaign and drove that for eight years here, I started at 45% SMB1 usage in telemetry. I would see about half of all SMB traffic with SMB1 and eight years later, it's now about 0.25%, almost entirely eradicated. It is very possible to do this. You just gotta bear down and we're gonna bear down with you. And that roadmap looks a little bit like this. So obviously here's what's coming, iCurb, local KDC. This NTLM to negotiation sort of options like SMB has done. But NTLM is still enabled. It's still enabled out of the box. You're in market OSs. We ship this and start figuring out how things have looked and things. We will start talking about what about back porting? What about bringing some of these options backwards into older OSs? We need your feedback and as much as you possibly can give us to justify that work, to give us examples and to help us come up with the resources to make that happen. And then at some future major release, NTLM will be disabled by default, but still available. And that at some major release after that, NTLM will be disabled and leave the machine. And it'll become available as a feature on demand, something that you can download, but the binaries won't be there and you won't have NTLM existing in Windows out of the box. And I don't have timelines on this. I don't have dates, obviously. This is gonna take us years. You're gonna be along for this ride with us. For anything NTLM related or you want to report issues, ask questions, send feedback, point out some vendor, anything you wanna do that says, like I have something about NTLM, just email ntlm at microsoft.com and it'll come directly to the engineering team. We will see this stuff and we'll be able to tell what's, hear what you're saying, hear what you're thinking, know what's going on with you. Perhaps give you advice. Perhaps you'll be able to influence future NTLM deprecation. Thanks so much for your time on this. I know this is a lot to think about. You might be watching this presentation a few times. This is going to be a long journey and we're very excited for you to come along on it with us. Thanks so much. Enjoy the rest of Windows Server Engineering Summit.