WEBVTT 00:00.000 --> 00:11.200 Hello everybody, welcome to the building, cross-domain truss between Freythe and Plyman 00:11.200 --> 00:12.200 Stalk. 00:12.200 --> 00:17.760 We have the pleasure to have Alexander Bokovoi for Cisco Trevino, please enjoy the ride. 00:17.760 --> 00:27.640 Thank you everyone, this is the last talk of the day, and I hope I will provide something 00:27.640 --> 00:34.400 that you can enjoy with, and then enjoy the end of the first one. 00:34.400 --> 00:46.960 So this talk is about a progress we made over the last year in making IPA trust IP. 00:46.960 --> 00:56.480 So that you can have split of your infrastructure into smaller blogs, and then users 00:56.480 --> 01:04.560 are in one blog, and then systems separated in another, and another, and another, and then 01:04.560 --> 01:14.680 use establish some trust relationship between them to make it possible to effectively isolate 01:14.680 --> 01:23.720 users and make decisions more stringent on who can access what and who can see what 01:23.720 --> 01:26.320 anywhere. 01:26.320 --> 01:35.240 So this is more or less not to talk about what is how it's done internally, but more 01:35.240 --> 01:43.800 like what we have now, and we are at the point where we are able to establish trust 01:43.800 --> 01:51.680 between two separate IPA deployments, completely separate, and it looks like a trust between 01:51.760 --> 01:54.520 Active Directory and IPA. 01:54.520 --> 02:00.680 In the sense that you use exactly the same procedure, so there's nothing new procedure 02:00.680 --> 02:01.680 wise. 02:01.680 --> 02:15.680 It's IPA trust at type of the trust and something else, but from the result, things continue 02:15.680 --> 02:19.360 working, similarly to the trust of AD. 02:19.360 --> 02:23.720 So Kerberos authentication works kind of. 02:23.720 --> 02:33.600 SSSD resolves users and groups, ideal to write works, so you can assign certain things, and 02:33.600 --> 02:41.360 we found few factors that force us to continue this development, so this is why it's 02:41.400 --> 02:50.400 not merged upstream on not available in the distributions, but the current state is 02:50.400 --> 02:58.120 such that you can deploy it and test it and tell us what's missing from your use cases. 02:58.120 --> 03:01.680 This is an interesting part of the station. 03:01.680 --> 03:07.960 People are not really willing to talk about their internal infrastructure, they build on 03:08.000 --> 03:15.640 top of the APA, because sometimes it's security through the obscurity, sometimes it's 03:15.640 --> 03:22.560 business, sometimes it's a really competition advantage and so on, but we really want 03:22.560 --> 03:32.400 to hear use cases, and we're given a model that can reproduce what we have and give 03:32.400 --> 03:37.840 you a freedom to go forward and see how this can be. 03:37.840 --> 03:43.760 Not only extended, but you can also demonstrate through this automation that we will show, 03:43.760 --> 03:45.840 how your use case is supposed to work. 03:45.840 --> 03:51.360 If you extend that automation to demonstrate your use case, it will help us to actually ensure 03:51.360 --> 03:53.680 that we implement that use case. 03:53.680 --> 04:02.360 So this is not just about a new feature, it's how we could collaborate potentially demonstrating 04:02.400 --> 04:04.880 certain things. 04:04.880 --> 04:15.760 So the demonstrate up of what I will show runs, it uses Ansible, Ansible Free APA specifically, 04:15.760 --> 04:26.360 to provision machines, which are FMRL containers, but don't look at this like it's containers 04:26.440 --> 04:28.160 or something. 04:28.160 --> 04:33.560 Once tooling is run, it generates an inventory that has machine names. 04:33.560 --> 04:39.440 So if you have other mechanisms to deploy these machines to bare metal or VMs and so on, 04:39.440 --> 04:46.440 the same inventory, the same playbooks will work against those machines. 04:46.440 --> 04:48.680 So that's a good thing. 04:48.680 --> 04:55.560 And these slide serves as a reminder if you have not really used podminton, that's 04:55.600 --> 04:59.320 how you can get certain things in podminton. 04:59.320 --> 05:01.760 I got an end-writing. 05:01.760 --> 05:05.640 So how this automation looks like? 05:05.640 --> 05:14.480 So the idea is to basically reuse some of the apps to present that we have already, 05:14.480 --> 05:21.920 like I was on the mention, Ansible Free APA is one of those prayers that we can rely 05:21.960 --> 05:26.400 on in order to deploy a complex topology. 05:26.400 --> 05:32.120 So you know, Free APA, you can deploy servers, replicas, clients, you need resources, 05:32.120 --> 05:37.200 you need the very metals or VMs so that it's kind of complex. 05:37.200 --> 05:44.040 And then we are talking about item to item trust, which is establishing trust between 05:44.040 --> 05:48.360 to independent or more deployments, so it's even more. 05:48.360 --> 05:53.720 And then it's not this, I think, and then we just came up with an idea, like trying to mimic 05:53.720 --> 05:58.760 all those topologies and deployments as podminton containers. 05:58.760 --> 06:05.800 So we figured out the way how to, with a very simple podminton boss file, how to describe 06:05.800 --> 06:11.440 in a German file in a icy way, multiple of those Free APA deployments. 06:11.440 --> 06:21.600 And then in terms of five to six meetings, you can bring up multiple, the Free APA deployments 06:21.600 --> 06:25.680 and start playing with complex features like item to item trust. 06:25.680 --> 06:35.520 So in this demo, what we did is just to bring up one host, not only one host, with enough 06:35.520 --> 06:41.160 memory, you can just run this automation that we have upstream. 06:41.200 --> 06:46.680 The automation relies on a container file, and that container file is deployed is kind of 06:46.680 --> 06:52.200 installing Free APA, but it also contains experimental reports that are including the 06:52.200 --> 06:55.160 item to item trust feature. 06:55.160 --> 07:01.120 So thanks to that, in this slide, yeah, this is what I mentioned. 07:01.120 --> 07:09.240 You can just bring up one host, it can be your laptop as well, and you run podminton 07:09.240 --> 07:16.520 compose, and then you start bringing kind of federal containers inside the host, and those 07:16.520 --> 07:24.520 federal containers will install or will contain already the RPN for IPA, and also for IPA 07:24.520 --> 07:26.800 to IPA trust. 07:26.800 --> 07:36.520 And yeah, you can do, and then you can, once you have the clusters up and running as 07:36.600 --> 07:42.360 containers in your host, you can continue running Ansible Playbooks, perhaps regular Ansible 07:42.360 --> 07:47.240 Playbooks in order to establish trust or start testing the features. 07:47.240 --> 07:54.920 So this will happen in this slide, where we are basically applying Ansible Free APA on the podminton 07:54.920 --> 08:03.800 container, so that we still do independent IPA domains, if I want demo, and if I do demo, 08:04.040 --> 08:09.880 and yes, you can continue running Ansible Playbooks to establish trust in this case. 08:12.520 --> 08:14.280 So yeah. 08:17.720 --> 08:25.480 Yeah, so this automation is kind of, this is now a playbook that kind of automates the steps. 08:25.480 --> 08:31.800 And one kind of step there is the established bi-directional trust, and then add ID 08:31.800 --> 08:40.200 range and stuff, that's going to change, because we still haven't finished all this kind of 08:40.200 --> 08:48.840 how it's going to look like. One thing we realize is that if you move it a bit because they 08:49.480 --> 08:58.120 contradict each other, those mics. One thing we figure it out quite early in the process is that 08:59.080 --> 09:06.360 in the case of trust to Active Directory, we rely on somebody as a domain controller to represent 09:06.360 --> 09:12.600 ourselves as if we are Active Directory the main controller in a separate forest. So Active Directory 09:12.600 --> 09:22.680 expects certain protocols and certain commands and functions to be there and operate them. 09:22.680 --> 09:28.200 But between IP and IPA we don't need that. And some might think that this is actually a 09:28.200 --> 09:35.880 liability if you run some ways of the main control on each IPA replica, if you want to have that 09:35.880 --> 09:42.680 functionality. So we started looking at how we can improve on this. And one of possible ways to 09:42.680 --> 09:52.360 improve it is basically switch this particular step of introducing the trust to a different 09:52.360 --> 09:59.720 workflow. And most of those workflows nowadays protected with OAuth, so we need to have some sort of 09:59.720 --> 10:06.440 OAuth mechanisms. And then we started looking at this from the other side, okay, you have users, 10:06.440 --> 10:13.000 and ideally your admin user should not have password. You should have some passwordless method 10:13.000 --> 10:21.800 associated with it. So for example, smartcard. And to get smartcard working in a different 10:21.800 --> 10:30.360 corporal realm, you have to trust corporal spk in it certificates issued by the other realm that 10:30.520 --> 10:36.920 owns this. So you just need to have the certificate chain that is trusted. So there's already 10:36.920 --> 10:43.560 additional information that you have to trust before you establish trust. And that means that 10:46.280 --> 10:53.000 you become dependent on something that you don't have as a need when you establish trust with 10:53.080 --> 11:01.000 AD, because AD is kind of poor in terms of what it can propose in the authentication methods 11:01.000 --> 11:10.840 overcarables. It can do, yeah, it can do pk in it, sure. But in most cases, you have the administrative 11:10.840 --> 11:17.480 way of distributing those certificates already. And users authenticate not against you, 11:17.480 --> 11:23.240 but they authenticate against the domain controller somewhere there, right? In Active Directory, 11:23.240 --> 11:28.040 not on IP size. So we don't really need to trust the certificates other than 11:28.920 --> 11:34.920 right on the machine, well, customer is doing this. Then the other part is we have other 11:35.960 --> 11:45.480 passwordless methods that IP is supports, like file the two tokens, bus keys. We have radius authentication, 11:45.560 --> 11:52.360 we have our own OTP authentication, all requiring use of carboros, and all requiring use 11:52.360 --> 11:59.000 actually of something that wraps this information low. We use anonymous pk in it for that, 11:59.000 --> 12:05.320 and that requires trust in this chain of certificates again. So you quickly get to the point that 12:05.320 --> 12:12.840 it's better somebody else's will be handling this problem for you. For example, by issuing a request 12:12.920 --> 12:23.080 to someone else, or by dp, authenticate in there, granting access to an application that does 12:23.080 --> 12:31.160 enrollment for you, and then it's a normal task for web-based and of applications protected 12:31.160 --> 12:40.040 with or off. So that kind of thing also needed to log into the web UI. That the same thing 12:40.120 --> 12:47.720 is needed if you want to add support of passwordless methods to enroll machines, so that the 12:47.720 --> 12:55.400 administrator account is not really just a password-based. And we're realising that we kind of 12:55.400 --> 13:03.000 stop here, solve that problem, and then establishing trust becomes just one of consumers of that 13:03.000 --> 13:10.760 thing. So this is where we are. We are working on that part. And as that work is done, most likely 13:10.760 --> 13:19.960 we wouldn't need to have somebody's domain controller for these purpose on any of the IP servers. 13:19.960 --> 13:25.480 But of course, if you have trust to AD, you will have to continue using that. If you want to have 13:25.480 --> 13:32.520 somebody as a file server in the domain, then you will have to have the main controller available, 13:32.520 --> 13:41.160 but that could be a single one. So anyway, this is where we are. And after you completed the trust, 13:41.160 --> 13:48.600 the staff should work as it works for normal trust to AD. So you ready to resolve users' 13:48.680 --> 13:55.240 groups from trusted domains. All operations should continue working. Usually administrative 13:55.240 --> 14:03.160 operations they should be possible, so effectively all this stuff should work. So yeah, 14:03.160 --> 14:16.360 I have a small demo, recorded, and I pressed long button. So this is recording of 14:17.320 --> 14:25.160 effectively admin logging in into the system, getting its own 14:26.280 --> 14:35.560 Kerberus password. Our ticket, getting the Kerberus ticket, so we get the TGT, we can do any 14:35.560 --> 14:42.920 operations. So we are on IPA and look up one variable from it, so this is the Kerberus staff. 14:43.000 --> 14:49.560 The trust is already established, so we have this data. You can see that it says still active 14:49.560 --> 14:57.080 directory domain, because that's how it looks like internally. And then you can resolve users from 14:57.160 --> 15:12.200 the other domain. This is not all. So this is how the environment looks like and you can 15:13.240 --> 15:23.560 literally take the inventory and look at the generated files and so on. So we kind of 15:23.720 --> 15:35.720 there, right? So next step is to look at what else can be tested. And we tested the number 15:35.720 --> 15:43.960 of things already, so something like you can add them, these trusted users to external 15:43.960 --> 15:51.880 groups, you can propagate this to post-execroups and SSSD will do correct resolution of all 15:51.960 --> 15:58.120 these details. And you can add them to pseudo rules, to age backgrounds, it all works. 15:59.080 --> 16:07.800 As you expect with the trusted AD users, you can actually add them to the default trust view. 16:08.440 --> 16:16.120 So you can assign post-exproperties to them and here lies one of the first issues we found. So 16:16.840 --> 16:23.720 if you have admin from trusted domain, that admin, unlike most of the Windows cases, 16:24.600 --> 16:30.760 that admin will have post-execroups, 100% because this is IPA admin from the other system, 16:31.720 --> 16:40.040 from the other deployment. So we'll have a home directory by default in slash home slash admin. 16:41.000 --> 16:49.160 And that's the same directory that our own admin has. So they already clash on that admin. 16:49.160 --> 16:55.640 And if they are able to login to the system, they will be an admin at this trusted domain. 16:56.040 --> 17:03.080 So they will have different post-exID, right? We'll be able to authenticate using their own 17:03.080 --> 17:08.600 credentials against their own KDC. They will login to the system if they allow it, for example, 17:08.680 --> 17:15.720 if each pack allow all rule is enabled. But they cannot use that home directory because they 17:15.720 --> 17:22.920 have different post-exID than our admin. So obviously we need to do something, we need to kind of 17:22.920 --> 17:32.600 twist these home directory for these users. But this is non-generic thing, some admins might have 17:32.600 --> 17:38.360 different definitions of the home directory. It would be good to have that definition actually 17:38.440 --> 17:47.160 done and must, rather than one by one. If you have 10,000 users, doing 10,000 idea of 17:47.160 --> 17:53.640 a reuse just to redefine home directory, that's a problem. So we found another problem to solve. 17:53.640 --> 17:59.640 And that's another problem that we already heard from some customers for active directory 17:59.640 --> 18:08.200 use cases. So templates in the idea of the rights, based on this is the whole domain, they should 18:08.200 --> 18:18.920 have their home directory mangled this way. Or they all should have shell that is not been 18:18.920 --> 18:26.360 bash but been limited, for example, for all users from that domain. And then specific idea of 18:26.440 --> 18:33.640 the right for people who get the right shell or everyone has to be disabled. So something like that, 18:33.640 --> 18:40.440 these are the things that would be useful in the other way of doing trust. But in IPAK 18:40.440 --> 18:49.160 is they become necessity for having this trust. So yeah, we do need to define these things. 18:49.160 --> 18:56.120 And we tested all of these other rights and the basic stuff works. I don't know where to take 18:57.160 --> 19:03.880 non-basic stuff, of course, the template of the rights are not implemented yet. So it's identified 19:03.880 --> 19:13.960 problem. And if we look at the live demo kindish, yeah, we can do a live demo if the time 19:13.960 --> 19:19.880 will permit. But here are screenshots from the various steps of doing this. So yeah, you have 19:19.960 --> 19:27.000 trust find, you can apply idea of a right user add. So you can create that user. You can 19:27.000 --> 19:36.360 not lag into the web UI. It's broken at this point with this trusted user. But you can log into 19:36.360 --> 19:45.320 the machine on the other environment. And if MK home deer is set up, it will be used and 19:45.480 --> 19:50.760 applied. But of course, you have to change the home deer. So here, I didn't change in it, 19:50.760 --> 19:58.440 home deer to use the substitution symbols. But I could have the username fully. Well, in this case, 19:58.440 --> 20:06.760 just substitution symbols work because SSSD will expand this automatically. All ready right now 20:06.760 --> 20:13.880 without any modification. It's kind of the side effect of how SSSD expansion's work 20:14.760 --> 20:23.320 in the shell. And I think also in the home directory. And then, yeah, if you log in into that 20:23.320 --> 20:32.680 machine, you can see that we got a bunch of tickets available. Then using the IPA API tools, 20:32.680 --> 20:41.320 the common line tools will try to authenticate as that user against its own environment. So 20:41.320 --> 20:48.520 you get the HTTP ticket common from a different environment. So it's kind of fancy stuff. 20:51.400 --> 20:59.480 So we have these steps in the kind of live demo. These are available on the GitHub 20:59.480 --> 21:06.440 wrapper. And they actually plug into GitHub actions in that wrapper to demonstrate that you can 21:06.440 --> 21:13.400 run this whole environment into GitHub actions somewhere and do all this step. So this is what 21:13.400 --> 21:22.360 what happens once you do this deployment. I hope I will be able to scroll and actually you can 21:22.360 --> 21:34.280 see this output here when this script was running. So you actually get all this Ansible output 21:35.000 --> 21:44.920 of the things that we're on. And then I ran get and pass with the admin from the trusted 21:44.920 --> 21:56.440 domains. So this is run on IPA2Demodotest and asking to resolve IPA1Demodotest's user. And I get it 21:56.520 --> 22:05.160 resolved and handled this way. So it works in the other way around works as well because this 22:05.160 --> 22:14.360 is by directional trust. Intentionally I set up it by directional in this case. What else is 22:14.360 --> 22:30.360 working? We have this I hope it works. A demo that I did. Now I cannot make it full screen. 22:32.280 --> 22:40.680 This is a demo that I made last year that basically after I established trust I can 22:44.360 --> 22:55.720 define resource-based controls for server services across the trust link. So I can say 22:55.720 --> 23:04.360 so here it actually tries to establish trust. Using, well in that case it was at that point 23:04.360 --> 23:16.520 using really active directory like method to install things. And I can define so that a 23:16.520 --> 23:26.840 server service from one side is able to request service ticket on the other side of the trust. 23:27.560 --> 23:34.200 This is disabled by default but you can allow it specifically. This is useful if you have 23:34.200 --> 23:42.680 NFS server in one domain and then users in the other one and they log in to the third one. 23:43.560 --> 23:51.720 Three different deployments and they have to have some rules to allow this. And actually NFS 23:51.720 --> 23:58.360 pays at home there's that has to be mounted. This one example of these dynamic rules where we 23:58.360 --> 24:07.480 have to be able to decide that the users come in from this trust. I able to access files in 24:07.480 --> 24:16.200 the other trust and so on. So these are kind of things that we all have working and yeah I have this 24:16.200 --> 24:25.080 fancy way of asking give me a service on behalf of this user. So this is SVU to proxy thing and indeed 24:25.080 --> 24:36.360 I get the ticket and then I can see and on the other side I can also consume that one and see 24:36.360 --> 24:48.360 in the KB5 logs that this actually happened. Yeah and you can see we got the constraint dedication 24:48.360 --> 24:56.840 across the trust link. So it's pretty advanced already except this established trust part. 25:03.560 --> 25:08.360 So what are the next steps here? How I can get? 25:18.360 --> 25:33.560 What are the next steps? We are at the point where we want to get the idea of the right 25:34.200 --> 25:42.600 template working. It's independent of the IB8 IPA trust so it has use of fullness for other 25:42.600 --> 25:51.240 use cases and the Active Directory trust and so on and even for the local idea of the rights 25:52.280 --> 25:58.280 in the Active Directory domain this should be working because the machinery is kind of the same 25:58.280 --> 26:06.840 or should be the same there. We are working on the all-thent point to get this working. 26:07.800 --> 26:16.040 There are more to all of than just taking existing stuff. Unfortunately it's as complex as 26:16.040 --> 26:23.640 Kerber as itself if you want to get it secure but it will help us in solving a number of other 26:23.640 --> 26:32.280 problems like authenticating into the web UI or redirect into external IDP because we can not 26:32.280 --> 26:41.240 currently authenticate with external IDP. In the web UI we can do 26:41.240 --> 26:48.280 can pass the information how user authenticated across the trust boundary right now it's 26:48.280 --> 26:55.240 stripped off but we want to be able to so that you can actually inherit this information. If you trust 26:55.320 --> 27:02.600 that domain already you ought to be able to trust the decisions they made to inherit 27:03.320 --> 27:09.960 properties how users authenticated so if user was authenticated with smart card or user was 27:09.960 --> 27:16.840 authenticated with the fighter to token or a password we should be able to make decisions based 27:16.920 --> 27:25.640 on it and allow or reject a request for tickets and yeah federated authorization would 27:25.640 --> 27:33.000 obvious to become just a normal thing on top of that. Yes, so patience. 27:33.080 --> 27:47.880 Thanks for the talk and I have two questions. First one is is there a way for when you 27:47.880 --> 27:55.080 establish the trust to just have a pre-shared T kind of like what you would do for a Kerberos 27:55.080 --> 28:05.400 trust so that if two teams don't want to exchange their admin password of the IP admin 28:05.400 --> 28:13.160 password they could just basically agree on a pre-shared T just to establish the trust or do 28:13.160 --> 28:20.520 you need the other teams admin password to do. So you're authenticated against your own domain 28:20.600 --> 28:26.840 controller not against this one so it will just redirect you to talk to that domain control there's 28:26.840 --> 28:33.560 no changing that there's no additional key on it. Then the second thing you can assign admin 28:33.560 --> 28:41.480 rights in the trust in domain for the users from trusted domain already so you can say that 28:42.440 --> 28:54.280 Jonathan from NVIDIA can manage Alexander's deployment. You can enroll machines you can actually 28:54.280 --> 29:01.560 add hbcrolls to do roles anything wipe my password you can become admin on my cluster there's no 29:01.560 --> 29:09.080 problem this is already working you don't need to become any user on my side to do that 29:10.040 --> 29:15.720 you're still really establishing the trust in your first place and even the step-listen trust yep 29:16.920 --> 29:24.120 in my second question was is there any concept like global catalog or is is the all-the-app 29:24.120 --> 29:30.200 kind of like be able to kind of delegate the request or how does that work on the all-the-app 29:30.200 --> 29:37.320 so right now we use the same mechanism we use with active directory trust so there is a cross-relm 29:37.320 --> 29:48.520 entity access on the not the cross-relm entity the trusted domain in the main account credentials 29:48.520 --> 29:56.360 access on the domain controller to SSSD. SSSD uses it to authenticate to the other side and then 29:56.360 --> 30:09.560 use GSS API authentication to LDAP to talk to it SSSD had to be teach to learn that in IPA 30:10.520 --> 30:18.200 provider there could be IPA subdomains not just AD subdomains because that defines the schema 30:18.280 --> 30:28.280 and what to expect from the DIT in LDAP 3 and so on so this was the big work that that SSSD team did 30:29.080 --> 30:37.800 it's not completed yet that pull request is still open and being reviewed but we are fairly close 30:37.800 --> 30:48.040 on finishing up those beats and once it's done it's done it's merged as SSSD will be able to 30:48.040 --> 31:01.560 handle thank you yeah we are out of time but thank you for presentation I would like to ask the 31:01.560 --> 31:10.760 question we discussed when you plan the stock how do you check that the second domain you 31:10.760 --> 31:20.440 established trust with is the been in one and not malicious one it's a good question thank you so 31:21.560 --> 31:27.480 first in order to establish trust between two domains you have to have admin rights in both of them 31:28.440 --> 31:38.440 so you have to have this admin rights then the second part is that's really way it stops right now 31:38.440 --> 31:47.240 even with the active directory if there is a way to spoof DNS resolution and point to a different 31:47.240 --> 31:54.920 servers that most likely will happen so to do to solve that as I was telling yesterday in the 31:54.920 --> 32:01.000 DNS talk we are working on the encrypted DNS so that the communication is done through the trusted 32:01.000 --> 32:06.440 channels that you can not supposedly take over 32:24.920 --> 32:32.920 the channel to we would be relying on a channel to communicate and we have the DNS 32:32.920 --> 32:41.880 resolvers encrypted DNS resolvers yes in the established trust mode we would we use all of 32:43.160 --> 32:50.040 methods we would be relying on the chain of trust for the HDDPS to that side so we have to 32:51.000 --> 33:00.520 see a certificates pinned on our side when talking there and so on so this is like normal web thingy at that point 33:02.760 --> 33:04.760 yeah 33:05.080 --> 33:07.080 thank you