Hello everybody, welcome to the building, cross-domain truss between Freythe and Plyman
Stalk.
We have the pleasure to have Alexander Bokovoi for Cisco Trevino, please enjoy the ride.
Thank you everyone, this is the last talk of the day, and I hope I will provide something
that you can enjoy with, and then enjoy the end of the first one.
So this talk is about a progress we made over the last year in making IPA trust IP.
So that you can have split of your infrastructure into smaller blogs, and then users
are in one blog, and then systems separated in another, and another, and another, and then
use establish some trust relationship between them to make it possible to effectively isolate
users and make decisions more stringent on who can access what and who can see what
anywhere.
So this is more or less not to talk about what is how it's done internally, but more
like what we have now, and we are at the point where we are able to establish trust
between two separate IPA deployments, completely separate, and it looks like a trust between
Active Directory and IPA.
In the sense that you use exactly the same procedure, so there's nothing new procedure
wise.
It's IPA trust at type of the trust and something else, but from the result, things continue
working, similarly to the trust of AD.
So Kerberos authentication works kind of.
SSSD resolves users and groups, ideal to write works, so you can assign certain things, and
we found few factors that force us to continue this development, so this is why it's
not merged upstream on not available in the distributions, but the current state is
such that you can deploy it and test it and tell us what's missing from your use cases.
This is an interesting part of the station.
People are not really willing to talk about their internal infrastructure, they build on
top of the APA, because sometimes it's security through the obscurity, sometimes it's
business, sometimes it's a really competition advantage and so on, but we really want
to hear use cases, and we're given a model that can reproduce what we have and give
you a freedom to go forward and see how this can be.
Not only extended, but you can also demonstrate through this automation that we will show,
how your use case is supposed to work.
If you extend that automation to demonstrate your use case, it will help us to actually ensure
that we implement that use case.
So this is not just about a new feature, it's how we could collaborate potentially demonstrating
certain things.
So the demonstrate up of what I will show runs, it uses Ansible, Ansible Free APA specifically,
to provision machines, which are FMRL containers, but don't look at this like it's containers
or something.
Once tooling is run, it generates an inventory that has machine names.
So if you have other mechanisms to deploy these machines to bare metal or VMs and so on,
the same inventory, the same playbooks will work against those machines.
So that's a good thing.
And these slide serves as a reminder if you have not really used podminton, that's
how you can get certain things in podminton.
I got an end-writing.
So how this automation looks like?
So the idea is to basically reuse some of the apps to present that we have already,
like I was on the mention, Ansible Free APA is one of those prayers that we can rely
on in order to deploy a complex topology.
So you know, Free APA, you can deploy servers, replicas, clients, you need resources,
you need the very metals or VMs so that it's kind of complex.
And then we are talking about item to item trust, which is establishing trust between
to independent or more deployments, so it's even more.
And then it's not this, I think, and then we just came up with an idea, like trying to mimic
all those topologies and deployments as podminton containers.
So we figured out the way how to, with a very simple podminton boss file, how to describe
in a German file in a icy way, multiple of those Free APA deployments.
And then in terms of five to six meetings, you can bring up multiple, the Free APA deployments
and start playing with complex features like item to item trust.
So in this demo, what we did is just to bring up one host, not only one host, with enough
memory, you can just run this automation that we have upstream.
The automation relies on a container file, and that container file is deployed is kind of
installing Free APA, but it also contains experimental reports that are including the
item to item trust feature.
So thanks to that, in this slide, yeah, this is what I mentioned.
You can just bring up one host, it can be your laptop as well, and you run podminton
compose, and then you start bringing kind of federal containers inside the host, and those
federal containers will install or will contain already the RPN for IPA, and also for IPA
to IPA trust.
And yeah, you can do, and then you can, once you have the clusters up and running as
containers in your host, you can continue running Ansible Playbooks, perhaps regular Ansible
Playbooks in order to establish trust or start testing the features.
So this will happen in this slide, where we are basically applying Ansible Free APA on the podminton
container, so that we still do independent IPA domains, if I want demo, and if I do demo,
and yes, you can continue running Ansible Playbooks to establish trust in this case.
So yeah.
Yeah, so this automation is kind of, this is now a playbook that kind of automates the steps.
And one kind of step there is the established bi-directional trust, and then add ID
range and stuff, that's going to change, because we still haven't finished all this kind of
how it's going to look like. One thing we realize is that if you move it a bit because they
contradict each other, those mics. One thing we figure it out quite early in the process is that
in the case of trust to Active Directory, we rely on somebody as a domain controller to represent
ourselves as if we are Active Directory the main controller in a separate forest. So Active Directory
expects certain protocols and certain commands and functions to be there and operate them.
But between IP and IPA we don't need that. And some might think that this is actually a
liability if you run some ways of the main control on each IPA replica, if you want to have that
functionality. So we started looking at how we can improve on this. And one of possible ways to
improve it is basically switch this particular step of introducing the trust to a different
workflow. And most of those workflows nowadays protected with OAuth, so we need to have some sort of
OAuth mechanisms. And then we started looking at this from the other side, okay, you have users,
and ideally your admin user should not have password. You should have some passwordless method
associated with it. So for example, smartcard. And to get smartcard working in a different
corporal realm, you have to trust corporal spk in it certificates issued by the other realm that
owns this. So you just need to have the certificate chain that is trusted. So there's already
additional information that you have to trust before you establish trust. And that means that
you become dependent on something that you don't have as a need when you establish trust with
AD, because AD is kind of poor in terms of what it can propose in the authentication methods
overcarables. It can do, yeah, it can do pk in it, sure. But in most cases, you have the administrative
way of distributing those certificates already. And users authenticate not against you,
but they authenticate against the domain controller somewhere there, right? In Active Directory,
not on IP size. So we don't really need to trust the certificates other than
right on the machine, well, customer is doing this. Then the other part is we have other
passwordless methods that IP is supports, like file the two tokens, bus keys. We have radius authentication,
we have our own OTP authentication, all requiring use of carboros, and all requiring use
actually of something that wraps this information low. We use anonymous pk in it for that,
and that requires trust in this chain of certificates again. So you quickly get to the point that
it's better somebody else's will be handling this problem for you. For example, by issuing a request
to someone else, or by dp, authenticate in there, granting access to an application that does
enrollment for you, and then it's a normal task for web-based and of applications protected
with or off. So that kind of thing also needed to log into the web UI. That the same thing
is needed if you want to add support of passwordless methods to enroll machines, so that the
administrator account is not really just a password-based. And we're realising that we kind of
stop here, solve that problem, and then establishing trust becomes just one of consumers of that
thing. So this is where we are. We are working on that part. And as that work is done, most likely
we wouldn't need to have somebody's domain controller for these purpose on any of the IP servers.
But of course, if you have trust to AD, you will have to continue using that. If you want to have
somebody as a file server in the domain, then you will have to have the main controller available,
but that could be a single one. So anyway, this is where we are. And after you completed the trust,
the staff should work as it works for normal trust to AD. So you ready to resolve users'
groups from trusted domains. All operations should continue working. Usually administrative
operations they should be possible, so effectively all this stuff should work. So yeah,
I have a small demo, recorded, and I pressed long button. So this is recording of
effectively admin logging in into the system, getting its own
Kerberus password. Our ticket, getting the Kerberus ticket, so we get the TGT, we can do any
operations. So we are on IPA and look up one variable from it, so this is the Kerberus staff.
The trust is already established, so we have this data. You can see that it says still active
directory domain, because that's how it looks like internally. And then you can resolve users from
the other domain. This is not all. So this is how the environment looks like and you can
literally take the inventory and look at the generated files and so on. So we kind of
there, right? So next step is to look at what else can be tested. And we tested the number
of things already, so something like you can add them, these trusted users to external
groups, you can propagate this to post-execroups and SSSD will do correct resolution of all
these details. And you can add them to pseudo rules, to age backgrounds, it all works.
As you expect with the trusted AD users, you can actually add them to the default trust view.
So you can assign post-exproperties to them and here lies one of the first issues we found. So
if you have admin from trusted domain, that admin, unlike most of the Windows cases,
that admin will have post-execroups, 100% because this is IPA admin from the other system,
from the other deployment. So we'll have a home directory by default in slash home slash admin.
And that's the same directory that our own admin has. So they already clash on that admin.
And if they are able to login to the system, they will be an admin at this trusted domain.
So they will have different post-exID, right? We'll be able to authenticate using their own
credentials against their own KDC. They will login to the system if they allow it, for example,
if each pack allow all rule is enabled. But they cannot use that home directory because they
have different post-exID than our admin. So obviously we need to do something, we need to kind of
twist these home directory for these users. But this is non-generic thing, some admins might have
different definitions of the home directory. It would be good to have that definition actually
done and must, rather than one by one. If you have 10,000 users, doing 10,000 idea of
a reuse just to redefine home directory, that's a problem. So we found another problem to solve.
And that's another problem that we already heard from some customers for active directory
use cases. So templates in the idea of the rights, based on this is the whole domain, they should
have their home directory mangled this way. Or they all should have shell that is not been
bash but been limited, for example, for all users from that domain. And then specific idea of
the right for people who get the right shell or everyone has to be disabled. So something like that,
these are the things that would be useful in the other way of doing trust. But in IPAK
is they become necessity for having this trust. So yeah, we do need to define these things.
And we tested all of these other rights and the basic stuff works. I don't know where to take
non-basic stuff, of course, the template of the rights are not implemented yet. So it's identified
problem. And if we look at the live demo kindish, yeah, we can do a live demo if the time
will permit. But here are screenshots from the various steps of doing this. So yeah, you have
trust find, you can apply idea of a right user add. So you can create that user. You can
not lag into the web UI. It's broken at this point with this trusted user. But you can log into
the machine on the other environment. And if MK home deer is set up, it will be used and
applied. But of course, you have to change the home deer. So here, I didn't change in it,
home deer to use the substitution symbols. But I could have the username fully. Well, in this case,
just substitution symbols work because SSSD will expand this automatically. All ready right now
without any modification. It's kind of the side effect of how SSSD expansion's work
in the shell. And I think also in the home directory. And then, yeah, if you log in into that
machine, you can see that we got a bunch of tickets available. Then using the IPA API tools,
the common line tools will try to authenticate as that user against its own environment. So
you get the HTTP ticket common from a different environment. So it's kind of fancy stuff.
So we have these steps in the kind of live demo. These are available on the GitHub
wrapper. And they actually plug into GitHub actions in that wrapper to demonstrate that you can
run this whole environment into GitHub actions somewhere and do all this step. So this is what
what happens once you do this deployment. I hope I will be able to scroll and actually you can
see this output here when this script was running. So you actually get all this Ansible output
of the things that we're on. And then I ran get and pass with the admin from the trusted
domains. So this is run on IPA2Demodotest and asking to resolve IPA1Demodotest's user. And I get it
resolved and handled this way. So it works in the other way around works as well because this
is by directional trust. Intentionally I set up it by directional in this case. What else is
working? We have this I hope it works. A demo that I did. Now I cannot make it full screen.
This is a demo that I made last year that basically after I established trust I can
define resource-based controls for server services across the trust link. So I can say
so here it actually tries to establish trust. Using, well in that case it was at that point
using really active directory like method to install things. And I can define so that a
server service from one side is able to request service ticket on the other side of the trust.
This is disabled by default but you can allow it specifically. This is useful if you have
NFS server in one domain and then users in the other one and they log in to the third one.
Three different deployments and they have to have some rules to allow this. And actually NFS
pays at home there's that has to be mounted. This one example of these dynamic rules where we
have to be able to decide that the users come in from this trust. I able to access files in
the other trust and so on. So these are kind of things that we all have working and yeah I have this
fancy way of asking give me a service on behalf of this user. So this is SVU to proxy thing and indeed
I get the ticket and then I can see and on the other side I can also consume that one and see
in the KB5 logs that this actually happened. Yeah and you can see we got the constraint dedication
across the trust link. So it's pretty advanced already except this established trust part.
So what are the next steps here? How I can get?
What are the next steps? We are at the point where we want to get the idea of the right
template working. It's independent of the IB8 IPA trust so it has use of fullness for other
use cases and the Active Directory trust and so on and even for the local idea of the rights
in the Active Directory domain this should be working because the machinery is kind of the same
or should be the same there. We are working on the all-thent point to get this working.
There are more to all of than just taking existing stuff. Unfortunately it's as complex as
Kerber as itself if you want to get it secure but it will help us in solving a number of other
problems like authenticating into the web UI or redirect into external IDP because we can not
currently authenticate with external IDP. In the web UI we can do
can pass the information how user authenticated across the trust boundary right now it's
stripped off but we want to be able to so that you can actually inherit this information. If you trust
that domain already you ought to be able to trust the decisions they made to inherit
properties how users authenticated so if user was authenticated with smart card or user was
authenticated with the fighter to token or a password we should be able to make decisions based
on it and allow or reject a request for tickets and yeah federated authorization would
obvious to become just a normal thing on top of that. Yes, so patience.
Thanks for the talk and I have two questions. First one is is there a way for when you
establish the trust to just have a pre-shared T kind of like what you would do for a Kerberos
trust so that if two teams don't want to exchange their admin password of the IP admin
password they could just basically agree on a pre-shared T just to establish the trust or do
you need the other teams admin password to do. So you're authenticated against your own domain
controller not against this one so it will just redirect you to talk to that domain control there's
no changing that there's no additional key on it. Then the second thing you can assign admin
rights in the trust in domain for the users from trusted domain already so you can say that
Jonathan from NVIDIA can manage Alexander's deployment. You can enroll machines you can actually
add hbcrolls to do roles anything wipe my password you can become admin on my cluster there's no
problem this is already working you don't need to become any user on my side to do that
you're still really establishing the trust in your first place and even the step-listen trust yep
in my second question was is there any concept like global catalog or is is the all-the-app
kind of like be able to kind of delegate the request or how does that work on the all-the-app
so right now we use the same mechanism we use with active directory trust so there is a cross-relm
entity access on the not the cross-relm entity the trusted domain in the main account credentials
access on the domain controller to SSSD. SSSD uses it to authenticate to the other side and then
use GSS API authentication to LDAP to talk to it SSSD had to be teach to learn that in IPA
provider there could be IPA subdomains not just AD subdomains because that defines the schema
and what to expect from the DIT in LDAP 3 and so on so this was the big work that that SSSD team did
it's not completed yet that pull request is still open and being reviewed but we are fairly close
on finishing up those beats and once it's done it's done it's merged as SSSD will be able to
handle thank you yeah we are out of time but thank you for presentation I would like to ask the
question we discussed when you plan the stock how do you check that the second domain you
established trust with is the been in one and not malicious one it's a good question thank you so
first in order to establish trust between two domains you have to have admin rights in both of them
so you have to have this admin rights then the second part is that's really way it stops right now
even with the active directory if there is a way to spoof DNS resolution and point to a different
servers that most likely will happen so to do to solve that as I was telling yesterday in the
DNS talk we are working on the encrypted DNS so that the communication is done through the trusted
channels that you can not supposedly take over
the channel to we would be relying on a channel to communicate and we have the DNS
resolvers encrypted DNS resolvers yes in the established trust mode we would we use all of
methods we would be relying on the chain of trust for the HDDPS to that side so we have to
see a certificates pinned on our side when talking there and so on so this is like normal web thingy at that point
yeah
thank you