To complete our identity management solution,
the whole idea is that we are sharing user accounts between our systems,
so we're going to install SSSD on AlmaLinux.
You can see that we're installing SSSD and the plugins for LDAP, along with the
utilities that are used to create the home directory. We can make sure that we
can resolve the hostname Ubuntu. Remember, that's the name of the certificate
that we've issued to our Ubuntu host.
We already have the CA certificate installed on this system.
Once we've done that, we can set up all of the authentication systems in PAM
to use SSSD for authentication and to make sure that we are creating a home
directory if the home directory doesn't exist; ‑‑force is just there because,
of course, the configuration files are going to exist, and we're going to be
overwriting those files.
It's the oddjob daemon whose task it is to create our home directory.
We just need to make sure then that service is enabled and started.
We can then move ahead to creating our SSSD file. We can really use
the same file that we have on Ubuntu, but because of differences in
the defaults to the service,
we just need slight differences. So we need to specify the services that
are going to make use of SSSD within our configuration. And, of course,
then, we add in the complete domain, example.com.
I've just got a sample here. But we don't need the shadow‑utils domain. On
both systems, though, we do need to make sure that we've set the permissions
to be read and writeable only to the root user.
So with that done, it's a matter of moving out to our AlmaLinux system to
complete the identity management solution by going ahead and installing the
SSSD on Alma, configuring our service, and then, of course, making sure that
we can access as the John user. And here we are in a big celebration as we
enter our last demonstration as we complete our identity management solution.
So we can begin by installing the necessary components, and of course, we are
using the yum utility on AlmaLinux 8. We're going to install then sssd,
sssd‑ldap. We need to make sure that we've got the oddjob daemon installed,
so the package oddjob. This carries out the task of creating our home
directories and making sure that we've got the correct module for this, so
our oddjob‑mkhomedir. So with this then looking good,
we can allow the installation to run through, and in a very short time, you
should be seeing a nice little screen completing the installation. But we know
that we are running our identity management, our LDAP server, on the Ubuntu
system, and we need to be able to resolve it by the name Ubuntu. So make sure
you know the IP address of your Ubuntu system, and then we can go through and
create a hostname record.
So we're using echo here, and we're creating then the IP address and
hostname, but we're piping it to sudo and tee. Tee ‑a is going to append
then through to our host file. It will write to the screen and to the file,
but this just becomes an easy way as a user we can elevate our privileges
with sudo to carry out the task. And look at this, with that done, we're
able to ping the Ubuntu host.
Next up, we need to make sure that we've got the correct
authentication mechanisms in place,
modifying the /etc ls switch .conf to use SSSD, and making sure
that PAM also knows to create the home directory.
So as we go through and do this,
we can set up our authselect, selecting the profile sssd with
‑mkhomedir. Now, it's telling us all of the files that it's going to
overwrite, but we can see that these already exist.
So what we're going to do is use the option ‑‑force, so we're
overwriting the existing files with our new SSSD profile. As long
as we haven't previously edited it,
it should be okay to do this. Once we've done that,
we can see that we do need to enable the oddjob.service.
So we can go through and run this.
I can go through and cut and paste what they've got in the screen and use
sudo in front of it, and it's the oddjob daemon that is responsible for
creating our home directories if they don't exist.
So we're getting a long way down the track now. We
have to edit the /etc/sssd/sssd.conf.
So using whichever editor you like, I happen to be using vi in this case,
I haven't installed the fuller vim package, and we can then
navigate through to the /etc/sssd/sssd.conf.
Now again, for ease,
I'm just going to cut and paste the file that we had on the Ubuntu system.
But because of differences between the default,
we need slightly different information.
So we only need the one domain, we don't need our shadow‑utils domain,
but we do need to then make sure that we remove that information.
So let's remove then our domain and shadow‑utils.
And then just returning back into my sssd section,
we need to make sure that we explicitly reference the services
for nss and pam. So just slight differences in the way in
which the sss daemon defaults work, but it's easily rectified.
We also need to make sure that on both systems the service won't run
correctly if you haven't set the correct permissions.
So it needs to be readable and writable only to the root
user. So we can go through and see our permissions being set.
And we're just about ready to go.
We need to enable our SSSD service and to start it. So we
can go through and quickly add this in.
And we should be ready to run through now as our test user.
So working as vagrant,
we can then go through and do an su ‑. John, remember John is the account
that we have in the OpenLDAP system, add in the password, and we can see
then the home directory has been created.
We can see that we're in that directory now, and when we check the id,
we've got the same user id and the same group membership as we saw on the Ubuntu system. We're able to share our accounts.