Let’s Retire NTLM (Vol 2) The Kerebos Connection

Alright. How's everyone doing? Good. So today we're talking about what is it? Oh, yeah. NTLM. Hi. I'm Steve Syfuhs. I'm a engineering manager within the Windows org. I run the authentication platform team. That means that I have the I guess, the job of killing NTLM. I'm the idiot that said, yeah. We can do it. Mariam is the person that comes to me and says, are you stupid? And so earlier today, Linda had talked about some of the things that you can do today or at least within the next month or two to kill NTLM within your environment, get close to killing NTLM in your environment. But there are limitations to what she had discussed, known limitations that we are trying to solve for you so that we can make things better and make it go away. So what we are going to talk about primarily is how that exists, what the plan is, what exists right now or will exist within the next little while, and the long term state of things. So with that, I'm gonna hand it off to Mariam. Perfect. Hi, everyone. Thank you all for being here. As Steve mentioned, we're gonna go through some of the things that Linda covered briefly in her presentation earlier today to kind of set the theme or the setting of why we're doing all this work, why NTLM needs to go away, and then we'll deep dive into two of the most common and unique scenarios where we see NTLM usage through our telemetry, which are the no line of sight to DC and the local KDC. So we'll do a deep dive on those, and then we'll end with, okay, now that we know all this stuff, what do we need to do given that these features are close to being out? We're continuing on with the Kill Bill theme. Fun fact, I had no idea what Kill Bill was until Linda mentioned that this is the theme we're using. That tells you anything about my age or my yeah. Or my taste in movies, that's fine. That's okay. But bear with me as we go through those the themes just to continue from the earlier presentation. Our promise or our goal by the end of today's session is, like I mentioned, just understanding why we're doing this work, why it's so important, pointing out what's changing with iCurb and local KDC given the scenarios they are addressing, and then what you can start doing today with those features to prepare your organization for NTLM disablement. For those of you who have attended Linda's session, this should be pretty simple and easy. Again, going on with the same kind of setup, we'll just do a quick quiz. Hopefully, gold stars for everyone, but let's just go through those really quick. First one, can classic Kerberos work when the client can't reach a DC? If you agree with that, Yuri, say yes or raise your hand. Yes or no? None. Good. Okay. Perfect. Soon though. That's gonna happen soon. Will iCurb repair a missing or duplicate SPN? Yes or no? Very good. No. Negotiate means Kerberos is going to be used. No. Good. That was a trick question. Great. And then connecting to a server by IP address can cause curb to fall back to NTLM? Perfect. And last but not least, NTLM provides mutual auth between client server. What's that? No. Correct. It cannot. Awesome. Well, I mean, it sounds like everyone already knows what we're gonna talk about. So Cool. We're done. That's it. No. Just kidding. Alright. So let's look at this is going to be a quick recap for those that haven't attended the earlier session, but we'll look at the top reasons that we know NTLM is being used. Major one is local accounts followed by IP address targets. Also no no line of sight to a domain controller, use cases of an unregistered SPN, and then hard coded NTLM. We won't spend time going through those because we've already covered them, but that's just a refresher. The two we'll talk about today, again, are the local accounts and the no line of sight to domain controller. So let's look at what those mean before we get into the technical details of them. When there's no line of sight to the domain controller, that means that the client was unable to reach a DC, and so it didn't get a Kerberos ticket, and authentication failed and fell back to NTLM. That's one very important scenario that we need to address as soon as possible in most common enterprise environments. The second gap or the second scenario is when a work group scenario is using local accounts, and then there's no local there's no KDC, and so there is no Kerberos tickets being issued, and, again, authentication falls back to NTLM. And so I'll pass it over to Steve to go through what those actually mean and how they work in the back end. Alrighty. Let's hit the button. Alright. IACurb and local KDC. Who knows what that is? Hopefully, one or two people have heard about what that is. IACurb initial and pass through authentication using Kerberos. If you're wondering what that means, it means someone from Microsoft came up with the name. Ultimately, it means we're proxying the thing. The idea is that your client may not have line of sight to a domain controller, which is a fundamental prerequisite for Kerberos to be able to say, I need a ticket to thing. Go talk to the domain controller. In IACurbs case, what we're doing is we're proxying it through the application you're talking to because if you can talk to the application that you care about, that probably has line of sight. The next thing is local KDC, is this idea that on every Windows machine, we have this SAM, the security account manager, whatever the hell it's called. It exists. It stores user accounts. It stores passwords or at least derivatives of passwords, and it allows you to authenticate to a machine directly. NTLM, when you're talking to a machine directly, talks to the SAM and it authenticates via the SAM. Local KDC fundamentally sits on top of the SAM, and it works the same way. The difference is instead of being NTLM, Kerberos. Pretty simple. So let's talk about how this works in the real world. With IA Curb, we have a remote user. They're, I don't know, at home or they're in a coffee shop or they're doing something highly unrealistic, but for the sake of a demo, it makes total sense. The idea is that it's connecting to a resource that needs domain authentication. Domain authentication, my laptop is going to sleep. I have a demo, which we'll show off in a bit. The idea is the application that you're talking to is Kerberos based, needs to authenticate via Kerberos. So naturally, it falls back to NTLM when you don't have line of sight to a domain controller. So what do we do? Well, if the application has a line of sight, we route all of the messages that are going to the KDC through the application that has line of sight. It is deceptively simple. It's literally just taking the transport, copying it over to what you are sending to the application, and away you go. It's pretty simple in theory. And if we look at that, we see this is pretty normal behavior. You have your client, it's trying to connect to a domain controller, Can't do it. So what does it do? Falls back to NTLM. In the cases where NTLM works, IACURB works, or at least in principle it does if it's domain controlled, blah blah blah. Doesn't necessarily mean that it will always work in every single case, but if it can do NTLM, it can do IACurb. So, when we're doing IACurb, it does exactly what I said. Instead of sending the messages directly to the DC, it takes them, bundles them up, handles them off to the target, and away you go. And then, of course, what happens if IA Curve fails? Well, you know, the previous session folks talked about resilience. What do we do about cases where, you know, you have this mission critical system? How do you keep it online? How do you keep it available? How do you keep it from getting hacked? In the authentication world, we call fallback, which means we go from the secure thing to the insecure thing, NTLM. That's bad. So we wanna kill NTLM so that doesn't happen. In this case, it will eventually fall back to NTLM. We will kill that at some point. Next, local KDC. You know, you have a device, it's not domain joined, or maybe it is domain joined and you have laps, you know. You have your local admin account that is local to the device. It's managed in Active Directory. But because the authority is the machine itself, it can't do Kerberos because there's no domain controller. No. Now we have that with local KDC. As I stated previously, we took KDC, which is literally the Windows Active Directory domain controller code, the the key distribution center. We picked it up. We dropped it on top of every single instance of Windows in the world running Windows 11 and server twenty twenty five and whatever the next version is, and it's just Kerberos code running. And so as a result, what happens is in the old world, it would fall back to NTLM because there's no authority. The new world allows us to use Kerberos because it's just talking to Kerberos, to a KDC, and it negotiates down to it actually negotiates I a curb. The idea behind that is when you are connecting to the machine, it says, hey, what protocols do you support? And it says, well, I support IACurb. Okay. Cool. Let's do IACurb. So we do IACurb to the remote machine. See if we can connect to the remote machine using IACurb, and then in this point in time, the way that IACurb works, if we fall back to our previous slides, it goes and finds a domain controller. In our case, the domain controller is built into Windows, into the local machine, so it just calls home and says, hey, I got a Kerberos request. Can you fulfill it? The answer is yes. Hey, we're done. We did IACurb local KDC with without going off box. Pretty cool. So where does this matter? Local accounts, single machine accounts. So if you have machines that are, say, signage or, you know, in the middle of the Indian Ocean under 10,000 feet of water, which by the way is a very real scenario, very strange to see running Active Directory, but it exists. You don't really want that because the time it takes to actually get from one machine to the other is like seven days. It's expensive. So, like, we have this ability, and you don't really want to do NTLM over that because, well, it's in the middle of the Indian Ocean and some, you know, passing freighter may go over it and steal it and attack it and do all sorts of weird things. So we wanna do Kerberos. We want NTLM to go away for for all those weird edge cases. And then the the usual work group environments. If you don't have a full enterprise setup, you have a small mom and pop business, or you have some some weird environment, you know, maybe it's a it's a dedicated secure environment. It's the tier zero environment, actually. Going back to the previous conversation, you have this tier zero, tier one, tier two thing. Well, if tier zero is hosting the hardware for the tier zero infrastructure, identity and all that, do you want to have a dedicated active directory environment for that? Meh. Maybe not. Maybe you have a work group environment. Maybe it's a clustered scenario. Maybe it's something that allows you to stay fairly agile without having to have a full Active Directory environment. Here, you can do Kerberos. You have the benefits of Kerberos, is stronger authentication mechanisms, whether that's passwords, smart cards, anything that's certificate based for the most part. You have crypto agility, which is as as time goes on, we're getting to more quant post quantum compliance. SHA two fifty six, SHA three eighty four, which are which are things that have just will not exist within TLM. And so there's lots of environments where this actually matters. As Miriam had pointed out, 30% give or take of NTLM usage is because of local accounts. This is where local KDC comes in in handy. So the trade off, of course, is, well, when don't we wanna use it? That's exactly what we show on the slide. You don't do this to replace domain authentication. Domain authentication is there for a reason. It centralizes authentication, identity, the ability to access things across a whole fleet of systems without having to sprawl identity and credentials and everything. And so you really do wanna keep doing that. And it also doesn't solve things like the complex forests or the external trust. I hate external trust. I want them to die. They need to go away. So I am actually going to switch to my machine to show off how this works because you know what? I said two years ago that we were killing NTLM and I never got a chance to demo it. This is the first time I've actually ever demoed it on stage. So we got that. I was told I wasn't allowed to put pictures of dogs and things in order to bump up my stats in the slide deck. So this is my dog, Bruce, named after Bruce Wayne, as you can tell. So what are we doing? Right. Exactly. The my other shirt, the you had me at Kerberos. I had I had that shirt somewhere at home, and I couldn't find it for my trip and I was really sad. Alright. So first things first, I am going to reconnect to this because I don't trust the demo gods. They like to make things terrible. The idea here is pretty simple. We have a network protocol. Network protocols are excruciatingly painful to watch on screen. So as a result, the demo that we are going to do is a little silly. So I got Wireshark. I'm restarting it. I'm saying just filter on Kerberos, whatever. And I'm gonna say, please go to I'm on machine a. I'm going to connect to machine b. On machine a, I have blocked the Kerberos protocol port 88. It's a very easy way to demo this. We can basically say, I know that I technically have line of sight to my DC, but if I block the network connection that says you can talk to the DC, that's the same works the same way. So I connect. Voila. There's nothing in this file or folder because it's a demo. Who cares? And then I dig into this and then and I'm not gonna go into the SMB protocol because it doesn't really matter. But the basic the basic principle is you connect to a server, the server says, hey, we need to do auth. Client says, okay, what can we do? And it negotiates back and forth. By default, in Windows, our preference is Kerberos. We really, really prefer Kerberos over most other things. But if we can't do Kerberos, which in the case where I have, where I disabled the networks the the port, I cannot actually talk to the domain controller and do Kerberos. That's a perfect case where it falls back to NTLM. And if the demo gods are truly in my favor today, what should have happened is it should have said, hey, what about IACurb? So, take a look at this and what did I do? IACurb proxy. Voila. Not actually very interesting. So, I went one step further. I did something horrible. I said, hey AI. Sorry. I'm getting a bit of feedback because it's echoing off my screen. And I'm gonna say, please AI, try and make the most offensive presentation you can come across. And the idea behind this, and I thought, well, if I if I have it recorded and I say, well, if I log it and I try and capture all of the information, whatever, I'm just gonna have it fake it. So, we're doing iacurb. Client talks to the resource server and says, can you do Kerberos? It says, yeah. So, go talk to a domain controller. Can't do that. Well, what about IACurb? Okay. Take this message, forward it through to the KDC. I'm gonna slow that down so we can actually see that in action. Client says, I wanna talk to the server. Tries to talk to the KDC, can't because it's blocked. So it says, okay, I'm taking those messages. Forwarding through the resource server to the d c. We got a service ticket back, and then once we have the service ticket, we're doing an a p rec back to the resource server. Voila. All done. That is not the offensive part. The offensive part is I made a pew pew map. Unfortunately, I forgot. This actually bings every time it talks to a machine, so it's going bing, bing, bing. Anyway, this is IACurb. It's a very deceptively simple protocol. In theory, in practice, it's actually kind of a pain to build, which is why it took us two years to get there. But in the meantime, I also want to show off one of the very cool and interesting things. One of the side effects of building out Kerberos in a iCurb environment with local KDC is troubleshooting and debugging is really quite complicated. So we introduced some more debug logs. I hope this is the most interesting and exciting thing you have seen in your lifetime because it's a debug log. But in actual fact, my expectation is this will be really really handy both from a diagnostics and troubleshooting perspective, as well as your incident response. What the hell just happened? Well, here you go. This is my debug logs. I'm an engineering person. I wrote the code to go do this. My team uses this regularly. The idea is that all of the internal logging that we used to expose only to us is now here. Enjoy. So that's iCurb. Anyway, if we can get back to the slide deck. Is that cool? Handy? Useful? So I just showed you in action with a really silly demo of what's actually happening. It's just it's messages going back and forth across the wire through an application. It's a proxy. And then, what does that mean for local KDC? Functionally, it's the same thing, except instead of going off to a remote DC on the far side, it's just talking to itself. It's an in memory thing. It says, hey, do you have a user by the name of Bob? Yes, I do. It's local to the account. Okay. Well, we'll do Kerberos against it. We're done. Pretty easy. So, how do you get it? That demo is using Windows Insiders right now. I turned nothing on. So all you gotta do, get insiders. What's the ring? The RS ring? It's the canary channel. Canary channel. Yeah. For client and server. Yep. Client and server. So that's a that's a server build. It's also in the client build. Any version from this point on will do that. In the IA curb case, you could get it for free. In the local KDC case, you have to turn it on right now just because we didn't want to surprise too many people by having it blow up on them when they were potentially blowing up on them. It doesn't blow up on them, but we just couldn't tell because it's the first time we're rolling it out. So I'll hand this back. Perfect. Alright. So we covered iCurb and local KDC. Let's look at what that means from a realistic perspective of, okay, we looked at all the scenarios where NTLM is being used. What are those mapped to in real life? No line of sight to a domain controller, that's supported by iCurb, and it it helps the the the area where it helps is, again, when there's no line of sight to a domain controller. Next one is the local account scenario, which is addressed by local KDC. Remote local accounts, that's the combination of iCurb and local KDC together. Domain or global name namespace or unknown SPN, that is one of our future one of our future areas that we are addressing. IP target, that's, as Linda had mentioned, requires work from the organizations or the customers to move away from IP addresses. But the other option is to use the try IPSPN, which is something anyone can do today. And then last, I believe, is the the duplicate or broken SPN, which is something that is being investigated as of today. And so the the key message here is that while there are all these scenarios that we are working on addressing and to be delivered by Microsoft and Windows, there are the scenarios where they would require customer work. And if if anyone missed Linda's session from earlier today, she goes through what are the rings and the phases that can be used to understand what you need to be doing to prepare for the disablement and just how how to make it in a least damaging approach possible. Yeah. I mean, we we've we've covered that quite a lot throughout the two presentations, but the last the the goal or just to sum up is Kerberos is obviously our destination. We want to move away from NTLM. The enhancements we're doing will help enable that, but there are the the areas that, again, still require configuration by organizations. It requires additional work by Microsoft, and those are all things that are currently being are being done in the works and will be available prior to us making the call of, okay, let's disable NTLM by default. And so our goal is not to break anyone. Our goal is to prepare customers as much as possible and prepare organizations in advance or ahead of of that decision or of that change being done in future server or future OSs. And then we break you. And then we break you. Alright. And then you might you might remember that from the earlier presentation, but just an outline or a view a timeline view of what all has happened and what is happening. The NTLM auditing, the enhanced auditing that was released late last year and then the back port to older OS versions that's coming soon. ICurb and local KDC is the hot topic of this year. We announced that this will be released in 2026 and we are working calendar year of '26, and we are working super hard to get that out as soon as possible. And now it being an insider is just one step closer to that. And then the last or the the final destination that we are working towards is that default disablement. We have not announced what version of Windows client or server that will happen on yet, but it is something that we are working towards through all the configure or all the features and the configuration changes that we are working on. Something that we just published this morning was the NTLM FAQs. If you just go on aka .ms backslash NTLM FAQ, this just got published this morning, you'll see a very detailed list of questions that we have heard or gotten from customers and people within Microsoft and all around. It will help you get it summarizes what all we talked about today, but also gives you more insight on what you can start doing and what are all the resources that are available for you to start working towards NTLM blocking in your environments. So highly suggest you check that out, and then those are some other useful links, which I believe that deck will be shared out. And so just keep an eye out on the on the blogs and the announcements that we make over the next few months. And if you don't know yet, ntlm@microsoft.com is how you can reach us. Sorry. What was that? What was the what was the address? Uh-oh. No. No. What was it? Ntlm@microsoft. Sorry. What was that? N t l m is dead at Microsoft. Oh, actually, we should register that one. Yeah. Ntlm@microsoft.com. Please please please reach out. We wanna absolutely hear the things that are causing you pain besides us, specifically. If it's some of our products, whether that's built into Windows, whether it's other first party things, different different products made by by Microsoft, or if it's third parties that are not listening to reason that they should switch away from NTLM to Kerberos or it doesn't even need to be Kerberos for that matter. I mean, we're in a modern world. We're in a hybrid world. That also means that, you know, using Entra as an as a as a replacement for NTLM is perfectly valid option if, you know, if you wanna switch to OAuth or OpenID or whatever whatever protocol is your flavor of choice. The only thing we want gone is NTLM. So we wanted to leave some as much time as possible for questions because we know that it was a ton of information between the two sessions. So, yeah, just opening it up for questions. I think there's one over here. Is it on? Hello? Hey. Steve, sorry. Six slides ago, you had a reg key, h key local machine system current control set, whatever. Yep. It was to disable curb. Disable IA curb. Why would anybody do that? What what what scenario involves that? So that's a really good question. The question, why would you want to disable I a curb? There are a handful of interesting and complex problems when you are working within a protocol that's twenty five years old, mainly that it's a pain in the ass. The problem itself is the SP NAGO protocol, which is the encapsulating negotiate protocol. When we when we say negotiate, what we're actually saying is we're well, we have a client and a server are trying to agree on a particular authentication protocol. And the way that that protocol works is you can one of the parties, whether it's the client or the server, you issue a message that says, I support these five different auth protocols. Whether that's Kerberos, whether that's NTLM, whether that's Digest, whether that's yeah. .Pkudu or nego e x t blah blah blah blah blah. The interesting behavior with negotiate is that when you fire off that first message from the client, it sends an optimistic token, and that's the idea that I'm going to put my best foot forward, and if I can, I'm gonna save one round trip because we're talking about a protocol designed in 1993 or whenever whenever it was. And what happens is if you can do Kerberos, we're going to take Kerberos message, we're going to fire it across or sorry, a Kerberos AP rack, we're going to fire it across to the remote machine, and the remote machine is going to either accept it and say, hey, we're doing Kerberos. Cool. Or it's gonna fire back a message saying, I can't do Kerberos. Let's do one of these other auth messages, auth types. So that's SP Nagel in a nutshell. The problem with that is if the client cannot do Kerberos, it falls back to IA curb. That's a good thing. We fire the message over to the far side, and the far side says, what the hell is IA curb? I don't know. And it fires a message back and saying, I wanna do something else. But if it can do IACurb, but then it fails IACurb for whatever reason, because one of those other Kerberos reasons, SPN not found. It's doing an IP address or something to that effect. It doesn't really matter what it is, but Kerberos could fail for a myriad of reasons. The oddity of SP Nago is that the minute it has chosen an authentication mechanism and it has sent the first message for that, not the beyond the optimistic, it it's done. It never falls back. And so if I send two messages, it says, can't do it. We're done. And the entire connection's dropped. And so there are two recourses. Either a, we disable I a curb so that never happens and it just falls back to NTLM no matter what, which is not ideal, or we have this other protocol called late fallback. That's an entirely different thing. But the thing is, in order for late fallback to work, we need to have it implemented on the far side. Whereas iacurb is actually implemented by MIT, Heimdall, and a couple other open source Kerberos. Sorry? I've not heard that one. Multiple multiple implementations of I a curve exist out in the wild where whereas this late fallback thing does not, and so there are cases where you just wanna turn it off. Alternatively, it could just be that you have something that is not supporting SP NAGO correctly, and when it receives the IA Curve message, it just dies. It happens. Interop is a pain in the ass. So we have the the registry key to disable IA Curve. So that's that's the reason why. Michael. Thanks. I wanted to ask about IA Curb, whether it's agnostic of the encapsulating protocols. So if I have SharePoint or ADCS, will they support IA curve out of the box, or is it just SMB and remote desktop protocol? Good question. The encapsulating protocol that we care about is Nago, is SP Nago. And so SP Nago lives within the GSS API, and the GSS API is a standard HTTP spec is a standard spec that is supported through HTTP, supported through most wire protocols like SMB, like RDP. And so the answer to the question wholly is as long as it supports negotiate, it can support IACURB. That's right. Yep. Thank you. I have one more question on notes. So to sum up this this talk, we are we are discussing migration from a protocol which was introduced in 1993 to a protocol which was first released in '28 '89. Yep. So so sorry for stating the obvious, but wouldn't it Why? Wouldn't it be wouldn't it be better to think about protocols which were introduced in two thousands or more recently, like OpenID Connect. You you mentioned OpenID Connect. Like, would it be possible to bake OpenID Connect directly to SMB, directly to RPC, to SP NEGO, to to negotiate, basically? Yeah. So why why Kerberos? Why not something else? Something, you know, born within the last twenty years. There's a few different reasons. The the most justifiable reason is that because Kerberos has the staying power. It's in every environment today. Meaning that if you have Windows, if you have Active Directory, you have Kerberos. If you have third parties, if you're running Samba, if you're running I'm forgetting all of our competitors, but if you're running any of these, it's it's a it's an open spec that everyone understands and communicates, and being able to speak the same language for the most part is a very powerful capability. The second part this is a three or four part answer. The second part is that Kerberos itself is relatively crypto agnostic. It doesn't really care about what algorithms you're using. It it negotiates. There's like three parts to the negotiate phase. You can pick what algorithms you want for your credential verification. You have what algorithms you want for your ticket encryption, for your session key negotiation. You have options to switch from symmetric algorithms, which are your password based off, or you can switch to PK in it, which is your certificate based off. All of those are built into the protocol itself. And so that has really powerful that has a really powerful edge to it. Third thing is authorization mechanisms are built into it directly within the ticket. We have the pack. Within the pack, we have group SIDS or, well, SIDS in general. And those SIDS, you can map to authorization decisions on targets, things like that. And then lastly, the alternative is, well, what other protocol do we go with? If we go with OpenID or OAuth, OAuth is an authorization protocol. It's not an authentication protocol. In order for that to work, we need to have OpenID. In order for OpenID, we need to have a TLS stack because you can't do secure OpenID on on in the clear. You need to have by by the side effect of that with TLS, you also have to have to have an HTTP stack because it's an HTTP protocol. One of the cornerstones of Kerberos, and MTLM for that matter, is that the core security properties of the protocol all come down to this idea that at the very end, you're you're given a session key that you can use for something, some proof that you are doing server authentication to whatever it is you're connecting to. And so you can do transport level encryption, signing, whatever whatever thing you wanna do with that key. Open ID Connect doesn't have that. It's just it's not a thing that exists. So that means you need to go up stack or down stack, whichever way you're looking at it, to TLS. Okay. Well, TLS. Well, how do I do TLS? Well, I need to have PKI. Oh, we're back to ADCS or some other CA. And then how do you deploy that? Active Directory has the advantage that you can pick it up, you can deploy it to a single server, and you can immediately join domain machines to the domain. Like, it's instantaneous. It's self contained. With OpenID Connect with OAuth, whatever protocol, SAML, WS Fed, if you're looking at ADFS, that all requires secondary applications. ADFS relies on Active Directory. That's a separate installation. How do I join the Active Directory ADFS the ADFS server that it's running on to the domain in the first place if it's doing OAuth to authenticate like, there are there's there's a sequence in order for that to happen. And so ultimately, it came down to, well, it's a bootstrapping problem. It's a security problem. It's a cryptographic problem. I hinted previously that PQC is going to be a big, big thing. It's a very important thing that we have coming through the Kerberos world in the next year or so. Two years. So having a foundation that we can build on is actually valuable. And ultimately, there's nothing inherently wrong with Kerberos. It's a pretty good protocol when you get down to the to the brass tacks of it. The failure modes of Kerberos are not really with the protocol itself. It's with with implementations that surround it. And so we wanna we wanted to focus on the core principles, what makes Kerberos a good protocol, and how do we use that for the next ten, twenty years. Cool. So I can't see hands. So There's two. One over there and a couple over here. ST? Are there any DNS resource record requirements for it to work for the local KDC? Good question. Is DNS required? Well, if we go back to what I was talking about earlier about with the with the network requirements for IACurb, I blocked port 88 to say, don't do Kerberos. That was for a full domain authentication. In the IA curb curb world, it is application it's dependent on the application you're talking to. The local KDC case, the open question is how do we get to the DC that we're talking to? Well, there is no open port 88. We're not opening port 88 on every single machine in the world. That would be something that we would do and regret. So what we do is we use IACurb to actually do that. And so what happens is because we can't find a DC by the name that you're you're for the domain that you're asking for, which is the name of the machine you're talking to, we then say, well, let's try IACURD. Maybe the far side can figure it out. The far side figures it out because it knows, oh, well, I have a local KC, so I'm just gonna go talk in memory. They're they're the same process. They're able to talk to one another on on the far side. So there's no DNS. There's no ports. There's no network. It is transport agnostic. All we care about is can an application route the message via negotiate, which it can do already because it can already do NTLM and Kerberos and all of those protocols. So no networking or DNS requirements. Steve, will there be any issues like if the local admin password is being rotated using PAM tools? For the local admin password being what? Being rotated using the PAM tool. Using the PAM tool? Yeah. Generally not. As long as it as long as the account itself lives in the local security store on the machine, which every local account does, it has for the last forever since n t four in the security accounts manager, It doesn't matter. Because in order for Kerberos to work, it needs the it it it well, it doesn't matter. The answer to the question is it's safe. It's fine. It will work. The reason it will work is because when you're creating the user account in that store, we actually go and generate all of the necessary Kerberos keys for it to work. We've actually been doing this since 2016 server 2016 so that when you take your server and you promote it to a DC, the first count that gets copied over is that local admin account. We wanted to make sure you had your AES keys there. So the short answer is if it's in the local account store on the local machine, it'll work. I constantly get the question. I'm back here. Oh. Oh. Yep. Boy, I really wanna get rid of on prem AD and go to Entra ID only. Is these technologies moving me towards that in any way or completely separate from that? Does this technology help you move away from on prem to Entra? Insofar as we may break some things on prem, maybe? In practice, no. That's orthogonal to that. There's nothing like, if you want to get rid of NTLM, the answer is you can absolutely move away from whatever is using NTLM to something that's cloud native. That is absolutely a very valid approach to solving this problem. We're looking at it from the perspective of what if that's not an option. But, yes, absolutely go do that. One one last question. Okay. The very I got it. I have a mic here. I can I can jump in if that's okay? If there's no I'm happy to answer questions after this as well. I just this is hopefully a quick one. It's application specific. Yep. Does I a curb do anything to change line of sight requirements for Azure files? Does I a curb change anything for Azure files? Insofar as Azure Files does not currently support IACurb, no. But any plans to change that that you can share? We have no plans at the moment. They are interested in it. They're also interested in the local KADC side of things, but that's a very greenfield long term thing. We haven't shipped the thing yet, so they can't use it yet, but they are very interested. I'm not going to say one way or another what they will implement because we don't know. It could. There are options there that could solve some of the problems for them. But ultimately, our answer there is we'll just use Azure AD Kerberos as as the authentication mechanism for it because you will always have line of sight to Entra or Entra ID Kerberos, I should say. Got it. Thanks. Okay. That was the last of the questions. You guys ready to kill NTLM?