Just because we have an identity solution on our Ubuntu server,
it doesn't mean that the Ubuntu server is using that identity solution.
We can make it use it by installing SSSD and linking it through
then to our identity database or databases.
We could install then the plugins for SSSD and LDAP.
We could also then make sure that we update our
pluggable authentication modules,
ensuring the home directories are created for our users if they don't exist.
Remember, now we're going to have centralized users, so creating the user
inside of LDAP isn't in itself going to create a home directory on the
systems, considering as well that we might have 10 or 20 different systems
that are linking into the LDAP database. Once we've set that up, we can go
ahead and configure SSSD.
We need to copy across a sample file, and it's some of that sample that we'll be
using through to our etc, sssd, and sssd.conf. With that, we can edit the file
and add in the domain‑specific information for our LDAP database. We also can
enforce StartTLS through our sssd.conf.
With that done,
we can restart our SSS Daemon, and then we should be able to log
on as our user account John. So why don't we move out to our
command line and see this working, enabling at first
authentication on our Ubuntu system.
So installing SSSD and LDAP, configuring SSSD, and then going
through and testing our access. And, look at this, we're back at the
glorious command line of our Ubuntu system.
We're working as a standard user, which is always a good way to
be, and use the sudo command when we need to elevate our
privileges, such as installing software,
which is of course what we're going to do now by adding in then the
SSSD and LDAP plugins. We can allow this then to run through, and
as I said, there are other plugins that are available, such as for
authenticating through to Active Directory. We're going to leave it
as this though, so we can allow this to run through.
Now the service won't have fully started, but don't be too
concerned about that, we will configure it in a moment.
But first, let's go through and make sure that PAM, our pluggable
authentication modules, is set to enable the home directory creation.
So of course when we're normally creating users on a server‑by‑server basis,
it's very easy to have the home directory created when we
create the user, but with directory‑based users it's not the
same. This way we can ensure the home directory does exist when
the user first authenticates.
So with that done and dusted,
we then need to look at ensuring that we've got some valid SSSD
configuration. There is no configuration that exists by default on
Debian‑based systems, but we can then go through and copy across a
template, and then use some of the templates, and add in settings for
our own specific database.
So we're moving through into usr/lib/x86_64 and linux‑gnu, you can
see it as well as I can on the screen, and then the sssd/conf
subdirectory and the sssd.conf. This is a simple way to get the basic
settings that we need and put it into our /etc/sssd/sssd.conf. We
might as well secure this,
we can leave it open, but we might have credentials, we don't need
credentials, but there could be credentials in these files.
So if we use chmod ‑v, we are then seeing our permissions change,
we're ensuring it's only accessible to our owner, who will be root.
Now this has failed,
I forgot to run sudo, but it's also a good demonstration
because if I use sudo and bang bang (!!),
we run exactly the same command with all of the options and arguments, but
this time, of course, I've put the sudo command in front.
It's always a good one to remember. Now we can go ahead and edit the file.
Of course now, we know that I've got to use sudo in front of my editor command,
so we can run through and use sudo, and the editor doesn't really matter, I'm
going to use vim, but if you prefer nano, use nano. Now these are the basic
settings that we want, but underneath domains, we're only pointing to one
domain at the moment, but we want to add in our own domain. SSSD can
authenticate to multiple domains, you could have multiple LDAP servers. So
we're adding in the domain example.com, but we also need to define that, so I'm
just moving down below the PAM settings and then adding in a header for domain
and example.com, and I'm just pasting the information in. Again, this is
provided through the course downloads, so you're able to edit it yourself.
We can see then that we're using the domain, both for the user
accounts, the id_provider, and the auth_provider, so our
passwords. We're pointing through to LDAP and //ubuntu. We have
to be using the correct domain name.
We're caching credentials, so we're storing them locally once we've
connected, and we can see that we are connecting through to the base
example.com, and the important setting there is ensuring that we are
using TLS, our start_tls is enabled. So we can then go through and save
those changes. With those changes made, we can go through and restart
the SSSD service.
As I said, it failed to start after the installation, but
now it should start without any errors.
Now it's a very simple task of just doing an su ‑ through to our john account,
and entering the password that you set with the LDAP passwd command, and we
can see then that we're able to authenticate as our user who's based in the
Identity Management Solution. We're taken through to his home directory which
was created on first login.
Now whilst this is very good, and it is good, we have seen our system working,
we're also able to go through and check our group membership. Remember,
he's a member then of the group staff, and that, again, is in the
Identity Management Solution, our LDAP directory. But we've also gone
and now set this up so we can work from our other system, so let's take
a look on Alma and see how we can use this LDAP directory from the AlmaLinux system as well.