WEBVTT 00:00.000 --> 00:17.000 So I'm given this talk together with Andrea Schneider, and it's really part of the 00:17.000 --> 00:19.000 surprise. 00:19.000 --> 00:25.320 We gave this initial version of this talk a year ago at the same dev room, and at that 00:25.320 --> 00:33.080 point it wasn't really even fully defined what goes well, and the whole thing was running 00:33.080 --> 00:42.680 on the local forest bound to the 120,000, or something, addresses it's effectively a 00:42.680 --> 00:48.320 working progress, and what we show now is where we are. 00:48.320 --> 00:55.320 First, let's start who we are, actually. 00:55.320 --> 01:05.680 Yeah, I'm a free APA, core developer, I'm working on various aspects of authentication and 01:05.680 --> 01:17.360 identities in some sense, that long time ago, and occasionally I contribute to MIT 01:17.360 --> 01:24.360 developers, so Greg likes to rewrite my code, so that's inspiring. 01:24.360 --> 01:27.360 Yeah, my name is Andreas Schneider. 01:27.360 --> 01:29.360 I'm one of the demo maintainers at Red Hat. 01:29.360 --> 01:36.360 I'm a core team member since 2010, and also an MIT cover of Contributor and Greg 01:36.360 --> 01:40.360 always rewrites my pictures. 01:40.360 --> 01:46.360 Yeah, it's not really like alcohol, it's an animus, but no an animus to rewrite and code is nice. 01:46.360 --> 01:50.360 Somebody looks at your code, that's always nice. 01:50.360 --> 02:00.360 What we are talking about here is what we call internally local KDC, but the propanean 02:00.360 --> 02:05.360 would be this local authentication part. 02:05.360 --> 02:12.360 Yeah, so what is this talk about, so let's do a quick overview. 02:12.360 --> 02:19.360 So it's about the local KDC, which is an MIT cover of Keith's distribution center, 02:19.360 --> 02:22.360 short for KDC. 02:22.360 --> 02:29.360 It's only accessible local B over a UNIX domain socket and only runs on demand, which means it is 02:29.360 --> 02:32.360 socket activated. 02:32.360 --> 02:36.360 Yeah, why do we want to have local KDC? 02:36.360 --> 02:44.360 We originally wanted to solve a problem that there are so many different methods to authenticate 02:44.360 --> 02:50.360 in a real world, but when you try to log into the system and a special standalone system, 02:50.360 --> 02:58.360 unless you specifically crafted a bunch of modules, which are not really crafted together. 02:59.360 --> 03:03.360 Yeah, use passports, and we don't want to use passports. 03:03.360 --> 03:11.360 And in fact, inspired by the work on the decentralized guidance management and the public 03:11.360 --> 03:16.360 governments requiring non-passport authentication more and more. 03:16.360 --> 03:22.360 We started thinking, okay, how we can make this not just for the big governments, but 03:22.360 --> 03:25.360 basically for every single machine. 03:25.360 --> 03:33.360 And many applications, they already kind of support carabers and many applications that people use 03:33.360 --> 03:36.360 also on the local machines, they also support carabers. 03:36.360 --> 03:43.360 So we thought, okay, let's reuse what we already worked on for more than 20 years as a community 03:43.360 --> 03:49.360 and let's reuse that it's better tested, why not to use it? 03:49.360 --> 03:57.360 Yeah, but before we continue, let's look at a demo we recorded. 03:57.360 --> 04:01.360 So this demo is fully automated. 04:01.360 --> 04:05.360 It's a test that runs in potman containers. 04:05.360 --> 04:11.360 And what it does right now is trying to log into the machine over a cessage, obviously, 04:11.360 --> 04:14.360 with the password, because we only have the password, right? 04:14.360 --> 04:22.360 But as a part of it, it simply trains a corporate ticket from the KDC running behind this 04:22.360 --> 04:25.360 thing on the Unix domain. 04:25.360 --> 04:28.360 And it's really running on the Unix domain. 04:28.360 --> 04:33.360 So you can see if you request another service ticket from this machine. 04:33.360 --> 04:36.360 But we can use this ticket to access other applications. 04:36.360 --> 04:43.360 For example, SSD provides a palm module that allows you to authenticate 04:43.360 --> 04:46.360 over a palm using existing carabers ticket. 04:46.360 --> 04:49.360 So here we configured it to talk to Sudhu. 04:49.360 --> 04:55.360 And it asks us to enter a password, but really it's not entering password 04:55.360 --> 04:57.360 just entering enter. 04:57.360 --> 05:00.360 There is a box somewhere in this deck. 05:00.360 --> 05:03.360 And we really use the carabers ticket. 05:03.360 --> 05:10.360 Now we use this carabers ticket to talk to the Samba server running on the same machine. 05:10.360 --> 05:17.360 We just authenticate with carabers, Samba client uses this bunch of parameters to say 05:17.360 --> 05:23.360 that really use carabers, really use the existing carabers credential cache and so on. 05:23.360 --> 05:28.360 So we talk there, we pick up all these tickets and it all works. 05:28.360 --> 05:35.360 You can also check inside the ODD events, which I configured specifically for this, 05:35.360 --> 05:38.360 that the authentication was pervert. 05:38.360 --> 05:43.360 So next step is let's talk to a different machine. 05:43.360 --> 05:48.360 So in this setup we have two standalone machines, mine and Andreas. 05:48.360 --> 05:50.360 And here I'm talking to the Andreas. 05:50.360 --> 05:53.360 We both have the same user with the same password. 05:53.360 --> 05:57.360 So I'm using his account to talk to his machine. 05:57.360 --> 06:04.360 But I authenticate with carabers, not with NTL, as this happens today. 06:04.360 --> 06:08.360 Because I cannot really talk to his KDC. 06:08.360 --> 06:12.360 His KDC running on his machine over unix the main socket. 06:12.360 --> 06:14.360 It's inaccessible. 06:14.360 --> 06:20.360 Except over the special proxy protocol, which runs over Samba protocol. 06:21.360 --> 06:24.360 And you can see we use that proxy protocol. 06:24.360 --> 06:29.360 I occur in the authentication event in the log. 06:29.360 --> 06:30.360 And here we are. 06:30.360 --> 06:32.360 The demo is done. 06:32.360 --> 06:34.360 So. 06:34.360 --> 06:37.360 Fulker is ready to ask a question. 06:43.360 --> 06:48.360 That ask it for the real password on my machine, talking to his machine. 06:48.360 --> 06:55.360 But using carabers' negotiation within Samba communication. 06:55.360 --> 07:00.360 We come to that. 07:00.360 --> 07:06.360 The question that Fulker ask it is that is this S&B client running on my machine. 07:06.360 --> 07:09.360 Talking to Andreas machine. 07:09.360 --> 07:12.360 Here I ask it for the password, not use it. 07:12.360 --> 07:16.360 I already obtained locally. 07:16.360 --> 07:24.360 I will answer when we come to the slide that has this. 07:24.360 --> 07:31.360 In this one, in the test where we communicated to the remote Samba server, 07:31.360 --> 07:34.360 I did not press enter. 07:34.360 --> 07:36.360 I enter it actual password. 07:36.360 --> 07:37.360 Yes. 07:37.360 --> 07:42.360 So this is full replacement of anti-LM authentication. 07:42.360 --> 07:48.360 But it still remains the same like you enter password. 07:48.360 --> 07:53.360 And carabers exchange happens within Samba protocol. 07:53.360 --> 07:56.360 But it is exchange not with my KDC. 07:56.360 --> 07:58.360 It's exchange with the other KDC. 07:58.360 --> 07:59.360 Okay. 07:59.360 --> 08:04.360 We need to step out and look at the past. 08:04.360 --> 08:05.360 Yeah. 08:05.360 --> 08:08.360 Let's try to get a little bigger picture. 08:08.360 --> 08:10.360 Especially about post-exercise accounts. 08:10.360 --> 08:13.360 First we talk about local post-exercise accounts. 08:13.360 --> 08:17.360 They are normally defined in it is the past we do. 08:17.360 --> 08:19.360 And our password based. 08:19.360 --> 08:24.360 Services like OMSH for example, make use of that through the PAM stack. 08:24.360 --> 08:33.360 And OMSH also improve the experience using SSH keys. 08:33.360 --> 08:37.360 For security reasons and also for simplicity. 08:37.360 --> 08:40.360 All of that works very well for home users. 08:40.360 --> 08:45.360 But it doesn't work well for really large enterprises. 08:45.360 --> 08:47.360 Yeah. 08:47.360 --> 08:54.360 And large enterprises they basically have this concept of centralized identity management. 08:54.360 --> 08:56.360 There is some source replicated. 08:56.360 --> 09:00.360 There are multiple domain controllers that solve this. 09:00.360 --> 09:06.360 There are clients that have mutual authentication to the domain controllers. 09:06.360 --> 09:11.360 They know how to authenticate these domain controllers. 09:11.360 --> 09:14.360 And domain controllers know how to authenticate them. 09:14.360 --> 09:19.360 And then they can both ask for identities. 09:19.360 --> 09:24.360 And also delegate authentication if needed to the domain controls. 09:24.360 --> 09:27.360 That's why it's mutual authentication is required. 09:27.360 --> 09:32.360 And there are two big examples of it is the Active Directory. 09:32.360 --> 09:46.360 And free IPA and Samba Active Directory implementation is one of the premier things we use in the open source world for that. 09:46.360 --> 09:48.360 Yeah. 09:48.360 --> 09:56.360 So normally you want central authentication because users lock in into different services during the day. 09:56.360 --> 10:02.360 And for authenticating with all the services you interact. 10:02.360 --> 10:06.360 You want to make use of single sign on. 10:06.360 --> 10:11.360 And normally are at the moment for most of for the biggest systems. 10:11.360 --> 10:17.360 CSSAPI or Kerberos is used for system level authentication. 10:17.360 --> 10:22.360 And if you have web apps, this is off replaced with OS 2 in the meantime. 10:22.360 --> 10:27.360 There are also web applications which allow you to do several authentication. 10:27.360 --> 10:32.360 So both exits out there. 10:32.360 --> 10:33.360 Yeah. 10:33.360 --> 10:39.360 And the real use cases you log into this single system. 10:39.360 --> 10:48.360 You don't usually expect this particular system system account to be useful for when you, for example, 10:48.360 --> 10:58.360 logging in with your browser to hear, I don't know, mail provider web mail application all into your 10:58.360 --> 11:01.360 MasterDone account. 11:01.360 --> 11:07.360 And so on to do nice work that you do on social media and everywhere else. 11:07.360 --> 11:15.360 But if you try to log into the other system, at least on the web, you have this single sign on. 11:15.360 --> 11:24.360 So if they authenticate against the same identity provider, they cannot list used that fact as a session for longer time. 11:24.360 --> 11:35.360 So can we improve this by reusing the centralized approach also for standalone system for, at least for the applications running on this machine. 11:35.360 --> 11:40.360 So I show with an example with this demo that we used to do. 11:40.360 --> 11:47.360 What should do is a palm authentication, palm authorization and palm session. 11:47.360 --> 11:52.360 And effectively somebody verifies your credentials in palm. 11:52.360 --> 11:56.360 Then should do verifies whether you allow it to do certain things. 11:56.360 --> 12:01.360 But palm first, if you're not getting into palm, you're not getting into the city. 12:01.360 --> 12:04.360 And same happens with all the other applications. 12:04.360 --> 12:07.360 If they use palm, they kind of transparently use this step. 12:07.360 --> 12:14.360 This is nice thing, if we put something underneath, maybe we just reusing. 12:14.360 --> 12:19.360 Yeah, let's take a look at NTLM. 12:19.360 --> 12:23.360 NTLM stands for Nutella Knowledge Elon Manager. 12:23.360 --> 12:27.360 And it is Microsoft's challenge response authentication protocols. 12:27.360 --> 12:33.360 That's why it is crap. 12:33.360 --> 12:36.360 Yeah, NTLM is actually a family of protocols. 12:36.360 --> 12:38.360 It's not a single one. 12:38.360 --> 12:42.360 And it has like 30 years of history. 12:42.360 --> 12:46.360 I don't remember the exact date when they announced it. 12:46.360 --> 12:51.360 But it's probably around 1992, 1993. 12:51.360 --> 12:56.360 So at least the revisions that I saw were 93 years. 12:56.360 --> 13:03.360 We are officially at about the same age as Samba, which was not created to solve until in problems. 13:03.360 --> 13:04.360 Right? 13:04.360 --> 13:07.360 For replicate. 13:07.360 --> 13:12.360 And obviously this is not just authentication mechanism. 13:12.360 --> 13:20.360 It's a tool for hacking into your environment, which is hopefully used by all hackers around the world, 13:21.360 --> 13:31.360 and that's no wonder why everyone wants to get rid of NTLM. 13:31.360 --> 13:36.360 Yeah, so why is NTLM still in use? 13:36.360 --> 13:45.360 So NTLM doesn't require local network communication or connection to a domain controller. 13:45.360 --> 13:54.360 And NTLM is one of the only protocols supported when using local accounts on Windows. 13:54.360 --> 13:58.360 And NTLM works even if you don't know the target server. 13:58.360 --> 14:04.360 And often also NTLM is the fallback if Kerberos doesn't work. 14:04.360 --> 14:13.360 And if you have active directory environments, then it is really often the case that Kerberos doesn't work, 14:13.360 --> 14:17.360 because the NS isn't working. Someone did not set it up correctly. 14:17.360 --> 14:27.360 And then it falls back to NTLM and nobody notices until the domain controller CPU goes up. 14:27.360 --> 14:36.360 And then they are wondering why is this needing so much CPU and then they figure out the NSS program? 14:36.360 --> 14:44.360 Yeah, so we effectively got the full circle in almost like 30 years, because Microsoft say stop using NTLM. 14:44.360 --> 14:58.360 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. 14:58.360 --> 15:12.360 The problem is that people so long associated Kerberos with active directory domain controllers required that it created a perception challenge on one. 15:12.360 --> 15:25.360 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. 15:25.360 --> 15:30.360 Actually, almost 30 years ago. 15:30.360 --> 15:34.360 Yeah, let's go next one. 15:34.360 --> 15:44.360 And that's the thing we are keeping talking about, the I occur. 15:44.360 --> 15:54.360 So replacing NTLM is hard, but finally Microsoft found a solution to that, which is I occur and a local KDC. 15:54.360 --> 16:04.360 But they are still not implemented in the current Windows Server 2,000 25 version as of today and also not in Windows 11. 16:04.360 --> 16:12.360 They said it will be available, but it was postponed probably during issues they have. 16:12.360 --> 16:19.360 And you would think I occur because actually something new, but it isn't. 16:19.360 --> 16:37.360 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. 16:37.360 --> 16:52.360 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? 16:52.360 --> 17:04.360 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. 17:04.360 --> 17:19.360 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. 17:19.360 --> 17:31.360 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. 17:31.360 --> 17:48.360 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. 17:48.360 --> 17:52.360 And this was implemented in MIT Kerberos. 17:52.360 --> 18:02.360 The spec was like lingering because nobody really used it except, well, Apple. 18:02.360 --> 18:10.360 And Apple stopped using it at some point and then Microsoft rediscovered it again. 18:10.360 --> 18:21.360 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. 18:21.360 --> 18:34.360 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. 18:34.360 --> 18:42.360 It's not yet out, so it's all in the Gitmaster. 18:42.360 --> 18:53.360 For Heimdahl, there is no I occur support implemented yet, but Apple's implementation of Kerberos is based on Heimdahl? 18:53.360 --> 19:07.360 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 19:07.360 --> 19:20.360 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. 19:20.360 --> 19:23.360 So it's not in the upstream Heimdahl. 19:23.360 --> 19:38.360 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. 19:38.360 --> 19:58.360 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. 19:58.360 --> 20:22.360 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. 20:22.360 --> 20:47.360 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. 20:47.360 --> 21:13.360 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. 21:13.360 --> 21:39.360 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. 21:39.360 --> 22:00.360 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. 22:01.360 --> 22:27.360 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. 22:27.360 --> 22:42.360 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. 22:42.360 --> 22:57.360 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. 22:57.360 --> 23:15.360 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. 23:15.360 --> 23:31.360 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. 23:31.360 --> 23:52.360 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. 23:52.360 --> 24:05.360 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. 24:05.360 --> 24:16.360 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. 24:16.360 --> 24:27.360 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. 24:27.360 --> 24:48.360 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. 24:48.360 --> 24:56.360 And it configures a separate KDC in it's own directory worker or local KDC. 24:56.360 --> 25:04.360 We have a simple script called local KDC set up you just run it once and everything is prepared. 25:04.360 --> 25:13.360 We have also a local KDCK admin command right now because you need to add a user for your system. 25:13.360 --> 25:27.360 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. 25:27.360 --> 25:36.360 It relies on third-monger for PK in it's certificates that's part of the setup it's automatically creating those. 25:36.360 --> 25:50.360 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. 25:50.360 --> 26:03.360 There is also a sama with iacrups support so you can run an SMB server and play around with iacrups too. 26:03.360 --> 26:06.360 Let's look at future work. 26:06.360 --> 26:14.360 Yeah there's a future work is actually quite extensive but it's all bits and pieces and so on. 26:14.360 --> 26:30.360 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. 26:30.360 --> 26:53.360 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. 26:53.360 --> 27:03.360 So we need to know about seeds as a CD needs to know about seeds. 27:03.360 --> 27:21.360 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. 27:21.360 --> 27:39.360 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. 27:39.360 --> 28:04.360 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. 28:05.360 --> 28:17.360 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. 28:18.360 --> 28:33.360 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. 28:33.360 --> 28:41.360 And for doing that we need to understand use cases where the use roll Kerberus replace them and find out solutions. 28:41.360 --> 28:51.360 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. 28:52.360 --> 29:07.360 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. 29:07.360 --> 29:18.360 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. 29:18.360 --> 29:30.360 And this way we can also expose some of the specific data or also free IPA like the security identity fires. 29:31.360 --> 29:37.360 Or we can generate packs for these systems. 29:37.360 --> 29:43.360 Yes, and finally possibly so we have a bunch of possibilities method in 3a. 29:43.360 --> 29:52.360 And those methods actually work as a mechanism that is called over unix domain so it could be behind the Kerberus kdc. 29:52.360 --> 30:05.360 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. 30:05.360 --> 30:11.360 So that's where we are and that's how again hopefully not over in general.