So I'm given this talk together with Andrea Schneider, and it's really part of the
surprise.
We gave this initial version of this talk a year ago at the same dev room, and at that
point it wasn't really even fully defined what goes well, and the whole thing was running
on the local forest bound to the 120,000, or something, addresses it's effectively a
working progress, and what we show now is where we are.
First, let's start who we are, actually.
Yeah, I'm a free APA, core developer, I'm working on various aspects of authentication and
identities in some sense, that long time ago, and occasionally I contribute to MIT
developers, so Greg likes to rewrite my code, so that's inspiring.
Yeah, my name is Andreas Schneider.
I'm one of the demo maintainers at Red Hat.
I'm a core team member since 2010, and also an MIT cover of Contributor and Greg
always rewrites my pictures.
Yeah, it's not really like alcohol, it's an animus, but no an animus to rewrite and code is nice.
Somebody looks at your code, that's always nice.
What we are talking about here is what we call internally local KDC, but the propanean
would be this local authentication part.
Yeah, so what is this talk about, so let's do a quick overview.
So it's about the local KDC, which is an MIT cover of Keith's distribution center,
short for KDC.
It's only accessible local B over a UNIX domain socket and only runs on demand, which means it is
socket activated.
Yeah, why do we want to have local KDC?
We originally wanted to solve a problem that there are so many different methods to authenticate
in a real world, but when you try to log into the system and a special standalone system,
unless you specifically crafted a bunch of modules, which are not really crafted together.
Yeah, use passports, and we don't want to use passports.
And in fact, inspired by the work on the decentralized guidance management and the public
governments requiring non-passport authentication more and more.
We started thinking, okay, how we can make this not just for the big governments, but
basically for every single machine.
And many applications, they already kind of support carabers and many applications that people use
also on the local machines, they also support carabers.
So we thought, okay, let's reuse what we already worked on for more than 20 years as a community
and let's reuse that it's better tested, why not to use it?
Yeah, but before we continue, let's look at a demo we recorded.
So this demo is fully automated.
It's a test that runs in potman containers.
And what it does right now is trying to log into the machine over a cessage, obviously,
with the password, because we only have the password, right?
But as a part of it, it simply trains a corporate ticket from the KDC running behind this
thing on the Unix domain.
And it's really running on the Unix domain.
So you can see if you request another service ticket from this machine.
But we can use this ticket to access other applications.
For example, SSD provides a palm module that allows you to authenticate
over a palm using existing carabers ticket.
So here we configured it to talk to Sudhu.
And it asks us to enter a password, but really it's not entering password
just entering enter.
There is a box somewhere in this deck.
And we really use the carabers ticket.
Now we use this carabers ticket to talk to the Samba server running on the same machine.
We just authenticate with carabers, Samba client uses this bunch of parameters to say
that really use carabers, really use the existing carabers credential cache and so on.
So we talk there, we pick up all these tickets and it all works.
You can also check inside the ODD events, which I configured specifically for this,
that the authentication was pervert.
So next step is let's talk to a different machine.
So in this setup we have two standalone machines, mine and Andreas.
And here I'm talking to the Andreas.
We both have the same user with the same password.
So I'm using his account to talk to his machine.
But I authenticate with carabers, not with NTL, as this happens today.
Because I cannot really talk to his KDC.
His KDC running on his machine over unix the main socket.
It's inaccessible.
Except over the special proxy protocol, which runs over Samba protocol.
And you can see we use that proxy protocol.
I occur in the authentication event in the log.
And here we are.
The demo is done.
So.
Fulker is ready to ask a question.
That ask it for the real password on my machine, talking to his machine.
But using carabers' negotiation within Samba communication.
We come to that.
The question that Fulker ask it is that is this S&B client running on my machine.
Talking to Andreas machine.
Here I ask it for the password, not use it.
I already obtained locally.
I will answer when we come to the slide that has this.
In this one, in the test where we communicated to the remote Samba server,
I did not press enter.
I enter it actual password.
Yes.
So this is full replacement of anti-LM authentication.
But it still remains the same like you enter password.
And carabers exchange happens within Samba protocol.
But it is exchange not with my KDC.
It's exchange with the other KDC.
Okay.
We need to step out and look at the past.
Yeah.
Let's try to get a little bigger picture.
Especially about post-exercise accounts.
First we talk about local post-exercise accounts.
They are normally defined in it is the past we do.
And our password based.
Services like OMSH for example, make use of that through the PAM stack.
And OMSH also improve the experience using SSH keys.
For security reasons and also for simplicity.
All of that works very well for home users.
But it doesn't work well for really large enterprises.
Yeah.
And large enterprises they basically have this concept of centralized identity management.
There is some source replicated.
There are multiple domain controllers that solve this.
There are clients that have mutual authentication to the domain controllers.
They know how to authenticate these domain controllers.
And domain controllers know how to authenticate them.
And then they can both ask for identities.
And also delegate authentication if needed to the domain controls.
That's why it's mutual authentication is required.
And there are two big examples of it is the Active Directory.
And free IPA and Samba Active Directory implementation is one of the premier things we use in the open source world for that.
Yeah.
So normally you want central authentication because users lock in into different services during the day.
And for authenticating with all the services you interact.
You want to make use of single sign on.
And normally are at the moment for most of for the biggest systems.
CSSAPI or Kerberos is used for system level authentication.
And if you have web apps, this is off replaced with OS 2 in the meantime.
There are also web applications which allow you to do several authentication.
So both exits out there.
Yeah.
And the real use cases you log into this single system.
You don't usually expect this particular system system account to be useful for when you, for example,
logging in with your browser to hear, I don't know, mail provider web mail application all into your
MasterDone account.
And so on to do nice work that you do on social media and everywhere else.
But if you try to log into the other system, at least on the web, you have this single sign on.
So if they authenticate against the same identity provider, they cannot list used that fact as a session for longer time.
So can we improve this by reusing the centralized approach also for standalone system for, at least for the applications running on this machine.
So I show with an example with this demo that we used to do.
What should do is a palm authentication, palm authorization and palm session.
And effectively somebody verifies your credentials in palm.
Then should do verifies whether you allow it to do certain things.
But palm first, if you're not getting into palm, you're not getting into the city.
And same happens with all the other applications.
If they use palm, they kind of transparently use this step.
This is nice thing, if we put something underneath, maybe we just reusing.
Yeah, let's take a look at NTLM.
NTLM stands for Nutella Knowledge Elon Manager.
And it is Microsoft's challenge response authentication protocols.
That's why it is crap.
Yeah, NTLM is actually a family of protocols.
It's not a single one.
And it has like 30 years of history.
I don't remember the exact date when they announced it.
But it's probably around 1992, 1993.
So at least the revisions that I saw were 93 years.
We are officially at about the same age as Samba, which was not created to solve until in problems.
Right?
For replicate.
And obviously this is not just authentication mechanism.
It's a tool for hacking into your environment, which is hopefully used by all hackers around the world,
and that's no wonder why everyone wants to get rid of NTLM.
Yeah, so why is NTLM still in use?
So NTLM doesn't require local network communication or connection to a domain controller.
And NTLM is one of the only protocols supported when using local accounts on Windows.
And NTLM works even if you don't know the target server.
And often also NTLM is the fallback if Kerberos doesn't work.
And if you have active directory environments, then it is really often the case that Kerberos doesn't work,
because the NS isn't working. Someone did not set it up correctly.
And then it falls back to NTLM and nobody notices until the domain controller CPU goes up.
And then they are wondering why is this needing so much CPU and then they figure out the NSS program?
Yeah, so we effectively got the full circle in almost like 30 years, because Microsoft say stop using NTLM.
They really have been saying, and then in like 23, they finally announced that they want to get rid of NTLM and replace it by Kerberos, even for the local authentication.
The problem is that people so long associated Kerberos with active directory domain controllers required that it created a perception challenge on one.
And but on the other end, we have all the tools for not requiring domain controller being visible to the actual client being accessible over an network.
Actually, almost 30 years ago.
Yeah, let's go next one.
And that's the thing we are keeping talking about, the I occur.
So replacing NTLM is hard, but finally Microsoft found a solution to that, which is I occur and a local KDC.
But they are still not implemented in the current Windows Server 2,000 25 version as of today and also not in Windows 11.
They said it will be available, but it was postponed probably during issues they have.
And you would think I occur because actually something new, but it isn't.
Yeah, so that's why I'm keeping saying about almost 30 years is that the I occur if the mechanism to proxy over application your initial Kerberos communication was designed in 1997.
It was a visionary thing or maybe just normal line of thought at that point, but it wasn't used for long time until maybe like 2007, right?
And the idea is like if the client only has access to a server and for Kerberos you have a triangle, you have to client has to talk to a KDC proof.
It's existence to KDC, get the session, key, a ticket and then present with that ticket acquire the ticket to a service and then present that service ticket to a service.
So the service can verify so it's basically almost a triangle to communicate there, but if the client is not seeing KDC, how it can talk.
And the answer was well, you have a server server always have access to the KDC, talk to the server so that server encapsulates this traffic and just serves as a proxy towards the KDC.
And this was implemented in MIT Kerberos.
The spec was like lingering because nobody really used it except, well, Apple.
And Apple stopped using it at some point and then Microsoft rediscovered it again.
This formal spec came from people from Microsoft made a full circle came back from people from Microsoft updates in them and now rely on it.
And we did some work with MIT Kerberos. This work is now merged, all this update of I occur implementation and hopefully we'll be in the next release.
It's not yet out, so it's all in the Gitmaster.
For Heimdahl, there is no I occur support implemented yet, but Apple's implementation of Kerberos is based on Heimdahl?
Yeah, so this is one thing that Apple uses Heimdahl, but they need to talk to network, they need to handle certificates, they need to do all this stuff and they do this through
microes system white services. So there are some integration that pulls out into Swift and to all these things and it's not abstractable from microes code.
So it's not in the upstream Heimdahl.
So the question is if Heimdahl will ever get it or if someone is interested from the developers to work on that or someone else is contributing it, but we are not aware of that till now.
And Apple actually did use I occur to solve their own problems, so they had this concept of back to my Mac where if you're somewhere in the world, you can use a service provided by Apple to talk back to your own system.
So Mac OS uses I occur in an external service to allow the authentication back to your own machine, but that service was retired some years ago.
But not all of that got removed. You can still find a local KDC on your on on Mac machines and you can also set it up and make use of it. So there is also I occur implemented and it is still working.
I tried to use it. It didn't work also because the actual specification that the implement is now incompatible with the latest updates that Microsoft did. So it wouldn't be a compatible and less Apple and Heimdahl community spend time to fix that. I hope it will be fixed because the fixes relatively small.
Yeah, let's go back to the Linux KDC what we are working on. So the Linux version. And the local KDC is a cabros KDC. We use MIT cabros. It can be simulated or you can use the KDC also and bind it to local host. We did that last year and presented it here.
But since then we were working on it and improving it. So it's not that nice to run a local host and listen to all these interfaces. It's much nicer and better to run on demand over your next image.
So access to the local KDC is a direct for a service like SSSD, somebody and SSH server they can directly talk to the KDC over your next domain socket or it is possible for clients to use I occur to talk to a service like Sambar and then proxy everything through which is going down to your local KDC over your next domain socket.
Yeah, why we are talking about Sambar here is because Microsoft currently considers only exposing this over SMB protocol for Windows machines as well. So we anyway have to do this compatibility.
But it means we start with Sambar. If the other services want to be extended this way then the real thing is that not much work needs to be done.
So for example if your application server already support GSA and this is GSA API not just role purpose goals because I occur with extension over GSA PI purpose mechanism there.
So if it's already there it's just one additional or it's specifying the type of mechanism and MIT carbors will do everything else automatically. That's how we extended Sambar.
You don't need really to do more than there. But if services use role purpose they cannot really communicate over I occur they don't really have a way to parse the payload that comes over GSA API.
And if they do this they then can use local KDC. So this is for example how SSD works. SSD uses role purpose in many places.
It just able to talk to the local KDC over a unique domain socket but it's not able to accept well it doesn't talk to the network it doesn't expose itself over a network.
But it wouldn't be able to do that but SSH server theoretically could be such a proxy but I wouldn't choose to do that.
Right. So the project which provides all these bits is called local KDC obviously it's currently living in my work space or in my personal project.
And it configures a separate KDC in it's own directory worker or local KDC.
We have a simple script called local KDC set up you just run it once and everything is prepared.
We have also a local KDCK admin command right now because you need to add a user for your system.
It's an early prototype so we will improve things in future but this is currently the way so you run the K admin and add one user which you want to use.
It relies on third-monger for PK in it's certificates that's part of the setup it's automatically creating those.
And if you want to try and out test play around with it there is a copper repository which you can enable on your fedora machine and then install the local KDC run the setup.
There is also a sama with iacrups support so you can run an SMB server and play around with iacrups too.
Let's look at future work.
Yeah there's a future work is actually quite extensive but it's all bits and pieces and so on.
When we started doing this local KDC automation so how to use setup and how you pick up the users and so on it's relatively trivial but we want to avoid duplicates and code across multiple applications.
So one of the things there is that we need to kind of talk to Kerberus database but we also want to add some things that are common across different Kerberus databases like iPA implement its own privileged access certificate.
So we need to know about seeds as a CD needs to know about seeds.
The passwordless part of the authentication that we use in iPA behind KDC needs to get some additional information reach attributes that can be populated through what Leonard was talking earlier today.
And so the other thing that we found was this if you have typical Windows machine it has a machine credential machine account but then there is a lot of service principles that aliasing to that machine account.
You don't want to maintain bunch of Kerberus principles with exact same keys you want to have aliases support and we have that in the LDAP databases we don't have in the local database so we work with MIT Kerberus on the expansion of the KDB drivers to support the aliases.
Then in Semba we have iAcurps support and progress we have a prototype which is working and the Kremlin client also started to look into this.
And Kernell site is the one where we have problems they have mixed use of jss API and roll Kerberus in the safe suits and that that one needs to be rewritten completely using pure jss API.
And for doing that we need to understand use cases where the use roll Kerberus replace them and find out solutions.
Yeah, then we would like to integrate with the user database from system d there was a talk from Leonard earlier we weren't here you can watch the video.
Because we do not want that you have to create all the users who are able to connect to but that local users are already in the kd local kdc and available and you can just authenticate with it.
For this we will extend or write a new kdb driver which has then boiling support to talk to the user database in plants everything in in the kdb driver.
And this way we can also expose some of the specific data or also free IPA like the security identity fires.
Or we can generate packs for these systems.
Yes, and finally possibly so we have a bunch of possibilities method in 3a.
And those methods actually work as a mechanism that is called over unix domain so it could be behind the Kerberus kdc.
So we can simply transfer it over and get the same methods work and if they can pick up the data not from all that but from user database that system d provides.
So that's where we are and that's how again hopefully not over in general.