So let's start with the next talk.
And this welcome, Thomas Werner, talking about Ansible Free APA.
Hello.
So, let's go in here.
So, this talk will be about Ansible Free APA to use for AD integration, so Microsoft Active Directory,
and also to set up external identity providers.
The plan was to have an online demo here, but yeah, there have been some issues.
So, there is slides and there will be online demo later on on the web page.
So, for the automated Free APA deployment, I have been using the work from my colleague, Raphael,
and we had to change something in the inventory to make it work, especially in my environment.
So, if you want to do it on your own, it's used as a base for the whole presentation.
These are the steps to do, and one important thing is please fix time and time zone on all the machines,
otherwise you will have fun.
With covers, tickets, not valid tickets, tickets that are in the future or in the past and so on, so not fun.
The first step was get your windows you want to use.
There is a nice documentation on this web page from Raphael.
The different steps you need to do where you can get the images and what kind of images are working and so on.
The first step that we need to do from Windows AD step setup is to change the first script that we have this,
Windows AD setup playbook to disable IPv6 because if we do not, we will have lots of fun with DNS later on.
So, this was one of the most important things.
And we're coming to the setup of the IPA server.
For IPA server, as we wanted to have a replica deployment later on, it was needed also to enable DNS and auto reverse.
Sadly, there is an issue with auto reverse creation later on, but it is fixed manually.
And there is another issue with DNS with Windows, so you need to disable DNS stack validation.
In the lab, that's a lab.
Yep.
You will find out if it's working for you or not.
So, then you can simply do the steps that are on the web page.
So, the first IPA setup, then there is a nice test to make sure that DNS is really working on both sides.
This is the NSLookup test.
So, it tries to find the Kerberos TXT records on Windows side and Linux side on both ends.
So, it verifies that everything is working in here.
And the last one is setting up the trust.
I'm not adding the information in here because it's completely unchanged from the script in here.
And after we've done that, we can log in with the AD administrator into our Linux server.
ServerLinIPa test.
You can see I can log in, I have a ticket, I can get my AD, and then I'm trying to do a change in IPA.
And it says, hmm, invalid credentials.
Okay, so, but we have a solution for that.
Also an answer for your IPA that was added lately.
So, we can add, we can grant the rights to the AD administrator to act as an IPA administrator.
So, the first one is adding an ID overwrite that is needed to be able to use the AD administrator.
And the second one is adding this an overwrite for this administrator to the admins group to make sure that this user is able to do something so that it has admin rights on IPA.
And after we've done this, we can directly add a user, remove a user.
You can do everything.
So, host, users, whatever you want be.
AD administrator is an IPA administrator.
And the next part was, okay, let's try to do client deployment using this AD administrator.
So, the inventory file needed to be a little bit changed in here.
So, there's a client set up.
There is also a setting.
I don't know if you know about that.
This is configured DNS resolver.
This is a feature of the IPA client role to set up the client in a way that is that the DNS server or the DNS server you're configuring here.
This is the IP address of the DNS server that was used.
So, the first step of IPA client role is to set up network manager or systemdresolved or resolveconf so that you are able to use the DNS server directly.
So, it's not needed to do this manually.
And also, if you do an unconfigure, it will remove it again if you set the variable.
So, it's doing this automatically.
And the next two lines are to force it to use the administrator of AD.
And there is one important thing here.
You need to write it correctly.
So, that means a capitalized A in administrator and also the domain capitalized.
Otherwise, it will not work.
If you log in, it's working without because there is a rule for that.
But here, there is nothing.
So, you need to write it correctly.
This is the first issue.
So, why isn't it able to find the AD administrator?
But, okay.
With this, we are able to deploy the client.
And it's working afterwards.
So, you see here, the next one is the playbook to deploy the client.
So, it's the normal thing you see on Ansible Free APA.
There is a playbook for this.
So, you can simply consume it.
Yeah, so, client was easy.
What is next?
Yeah, replica.
But for replica, we ran into an issue with command line and also Ansible Free APA.
So, there is currently an issue in the replica connection check.
It tries to use admin.
And for sure, the password is not valid.
So, it fails.
We will find out what exactly the issue is to solve it.
It's affecting command line.
So, Free APA package itself and also Ansible Free APA.
So, it doesn't matter which you're using to deploy.
They will both fail.
But there is a temporary workaround.
So, disable replica contact.
But make sure that it's working.
So, DNS needs to be working.
And also, the reverse lookup needs to be working.
Otherwise, it will fail also.
And the next step is simply to deploy the replica.
And then we are there.
And we have a working replica.
We can use it also to deploy clients.
Also using administrator AD8-PI test and so on.
So, we have some issues and we will work on them in the next time.
But they are relatively small in my opinion.
It could have been worse.
And now we are coming to the second part.
A colleague of mine wanted to present this here,
but he was not able to come.
So, the second thing that we added in Ansible Free APA
was the possibility to configure and use external IDP.
There will be another talk later on about external IDP.
It will be true.
But we will be a big deal for that.
So, any open questions here might be solved by this one.
So, Free IPA has the modules for external IDP.
There is a new module that was added to Ansible Free APA
and also the use of external IDP was added to the user and so on.
So, we can configure Free IPA as an OAuth application on GitHub.
This is the example that I will show here.
So, let's go directly to this one.
So, we are creating a GitHub OAuth application in the first step
because this is needed to be able to configure external IDP with IPA.
So, the steps is simply go to your GitHub,
go to developer settings, OAuth apps and register a new application
and read the docs.
If you do so, it will ask for several things.
So, it will ask for application name,
the homepage URL which is also the authorization callback URL.
So, you should have the same in there.
This is the iperserver.com.
And please also add a description to be able to find it later on.
And enable device flow, this is needed for IPA to be able to handle this at all in the end.
So, this is very important to enable.
And then click register application.
And if you have done so, you will get a client ID and also a client secret.
It's very important to keep those secret.
But one thing, you need both of them in the next step for the setup of external IDP.
So, there is no way to get to the second one again.
So, either write it down, make a screenshot, whatever, but in a safe way.
And if you have those settings, you can go to Ansible Free APA.
And here you see, we are using simply them in text form.
But you can also use Ansible Vault for that.
So, that you do not have the passwords here, but for simplicity.
It's here, the same with IPA admin password.
It's here simply to make it simple for us to see what's going on there.
Otherwise, it will be a little bit cryptic.
And so, this is simply creating, setting up the external provider.
And in the next step, we need to retrieve the GitHub user ID.
Oh, one thing that we should add here.
So, IDP user ID is set to ID here.
There is another way, but this is way better
because with GitHub, it's possible to reuse names.
So, it's really good to use ID here for authentication
because then you will not run into this possible name clash later on.
And this is common problem for many IDPs,
that if you delete the user and after some time,
another user registers the same user visible name,
that user becomes basically squirting the previous one.
And many of those providers, they run like 90 days protection of the accounts.
Even if you delete accounts, you can not register one.
But eventually, they expire.
So, somebody can squirt your account in this way.
If you've configured your systems to trust whatever was the user name in the system, good luck.
You will be hacked a year later when you start doing it.
So, taking these other fields into account is very important.
And this is part of administrators to kind of design this thing.
Unfortunately, all these fields, they are not visible in the UI.
So, normal view can not see this information.
So, it's admin that needs to discover.
Yeah. So, use it this way.
So, we're retrieving the GitHub user ID.
It's stored here.
And in the next step, the IDP user ID is using this retrieved user ID.
The bad thing here is, sadly, IDP user ID here and IDP user ID here is not the same.
One is a user ID, so a number, and the other one is really a user name.
So, be careful and read correctly.
So, the thing is, Ansible Free API is trying to use the names from IP itself.
So, you will see the same naming issues in Ansible Free API that you see in free IP itself.
And after we've done this, the user is able to authenticate.
So, it needs to get the code, and with the code, it's possible to log in.
And that's it.
Thank you.
So, we have like six minutes.
Do you have questions?
Yes, please.
Please scroll to the beginning of your presentation where you describe the service stuff.
This one?
Yes.
Well, I hate the NSSEC myself, but why do you disable the NSSEC presentation?
If you do not disable the NSSEC right now, the IPA server gets a reply from the Windows DNS server,
it's ignoring it.
Maybe you should have said that this is about the lab setup.
So, if you have a lab where you don't have a Windows configured DNS SSEC in the Windows DNS server setup,
which is not default, they don't set up the DNS SSEC.
So, your lab is basically disconnected from the Internet, and it doesn't care about DNS SSEC.
So, that's your ADC DNS SSEC in that lab, or you don't.
So, Thomas choose the easiest way to configure DNS SSEC in the lab.
But, IPA configures DNS SSEC by default if you use the internal DNS server.
That's why it's forced into disabled validation because it's enabled on IPA sign.
So, either that Windows setup in the lab needs to gain DNS SSEC configuration,
or both of the sites needs to drop DNS SSEC validation.
Sorry, I don't get, because, well, if you implemented DNS SSEC validation,
implying that the DNS records SSEC are required, it's something weird.
Otherwise, you just don't get any signatures, and you have nothing to disable.
Now, a buy-in server, which IPA uses as an internal server, has DNS SSEC validation enabled by default.
You cannot switch it off unless you explicitly say to switch it off.
Yes, but if there is no signature, it should not reach anything.
It does check, and it does reject the request.
It rejects on signed address.
But this is just a lab story.
I try you do not disable DNS SSEC validation in the wild,
unless you know what you are doing and then pay consequences.
Okay, thanks.
Yeah, I think probably the problem, the reality is that a lot of RokyD setups don't have it enabled
because nobody ever talks to them, they're blue.
In many cases, people are using cloud-based DNS services,
so it's not the DNS server on your infrastructure.
It's some of the DNS servers provided by, I don't remember the names of those companies,
and those typically do not have DNS SSEC enabled for the whole zone that the company rents out of them.
Okay, yes, just a second.
Okay, so there's some language. Does this experimentary work with Samba as well?
Does the external ID provider work with Samba also?
I think I need to answer this.
Thank you.
One of them is using AD user to manage IPA.
This will work with Samba, because this is just a normal job between IPA and activity.
The external ID provider is called IPA users, because IPA only authenticates users that are in IPA.
AD users authenticated by the active territory domain controllers.
Microsoft implementation of active territory does not have perverse pre-authentication method
that supports anything like that at all.
Completely.
Same with Samba AD.
Samba AD built with Heimdall has no way to handle this.
Samba AD built against MIT perverse has theoretical way to handle this.
It's not implemented, and it's on my and Andrea's plans to complete this work on Samba AD site.
There will be more about it in the hour talk, that will be the last talk of the day.
More questions?
I hope it was captured by the mic.
I hope.
Yes?
It's the difference between this kind of integration and the one you spoke about in the morning.
Wow, good question.
Maybe I can answer this one.
This is basically Azure Freebase.
It's a new Samba network that will make the point of computer development.
Here we have an ID integration.
This kind of Azure Freebase is simply created to establish a class with AD.
The one for my presentation is basically a container service that is capable of connecting to the LDAP from AD
to make a request to LDAP, Python LDAP, something like that.
The one that was in the morning, the PAA theorem, in the center, the client enrolled into AD or IPA
and provided services to web applications, which is key to all of this case.
Any more questions?
We have time.
Thank you.