By default,
Linux keeps information about user accounts and groups stored locally.
For example, user accounts are defined in the Etsy password file.
The name can be a bit misleading because it seems like it stores password data,
but it's just data about user accounts.
So if we run cat
Etsy password,
we can spot a line like this,
which shows us information about the username, the user id, which is 1000,
the user's home directory and the user's preferred shell, which is bin bash.
The problem is in today's world, we usually have to manage hundreds of servers
and keeping track of what user accounts and
groups exist on each system can be a hassle
even with automation tools like chef Ansible or Puppet,
especially if we constantly need to create new user accounts,
remove unused users to find new groups and so on.
So there's an easier way to do this.
For example, let's say a new member joins our team
and we need to create a dedicated user account for this member on 200 servers.
Instead of updating user accounts on hundreds of servers,
we can just configure them differently from the get go all we need to do is add an LDAP
server into the mix.
LDAP is short for lightweight directory access protocol.
We can configure our Linux systems to use an LDAP server
as an additional source of information for user and group account.
So whenever we need to add, remove or modify user accounts and groups,
we avoid having to make changes on hundreds of individual servers.
All we need to do is update data about these accounts on a single central location
on the LDAP
server.
And our Linux servers will get the updated data about
the user and group accounts automatically whenever they need it.
It's easier to understand this if we see it in action.
So let's dive right into a practical exercise.
First, let's start off by checking for two user identities.
If we type in ID John,
no such user
and ID Jane,
no such user,
we'll see that these user accounts don't exist on the system.
Now, later in our lesson, we'll get back to these users and notice some differences.
Now, let's get an LDAP server running
in the real world. It might not be our responsibility to manage that LDAP server
as it might be running on Microsoft Azure or on a Windows server.
Our job is to manage Linux servers. Instead.
In that case, we'll just need to set up the clients to use LDAP
but not the LDAP
server itself,
which means we'll need to instruct all Linux servers to
ask for user and group identities from a central LDAP
server.
Now to avoid having to set up an LDAP server, which is a complicated process.
Let's just get our hands on a preconfigured one.
And for this purpose, we'll use LXC, which is short for Linux containers.
You can think of LXC as a Docker for
an entire operating system instead of a single application.
Now, first, we'll have to initialize LXD,
which is the hypervisor that will monitor LXC containers.
Now,
we can press enter here for everything displayed to
pick the default values shown between the square brackets.
Now, if you want to test this out yourself,
just make sure that the size and gigabytes of the
new loop device is set to at least five gigabytes.
That's the default value in our case. So we can press enter on that option as well.
OK? For our convenience, we've created a very simple
LDAP server code cloud
and we have it in an archive.
Now for our convenience, we've created a very simple
LDAP server here at code cloud
and stored it in an archive here.
And if we take a look at our files,
we'll see a tar archive which contains our Linux container image.
So let's restore the image to our system with this command.
Now,
after this import process hits 100% we still have to wait
a while until it finishes setting up the Linux container.
We will know when it's done because
the command-line prompt will be displayed again.
Now let's list our Linux containers.
We will see our restored containers called
LDAP dash server and it's currently stopped.
So let's start it up
and that's it.
Now, we have an LDAP
server available.
If you want to experiment with it for simplicity,
every password on it is set to the word password,
not super secure but convenient for demonstration purposes.
So if you want to add data to the LDAP
server, the password for the admin is password
and the password for the two Linux accounts we defined on it.
John and Jane is also password.
Now, let's list our Linux containers again.
Now we have to copy this IPv4 address because we'll need it in the next step.
Now, finally, we get to the real focus of our lesson.
How do we configure our Linux system to use group
and user accounts that are defined on this LDAP server?
Well, there are many ways to do this,
but let's check out what's probably the easiest way
we can install a package called
LIB nss dash LDAP
D.
Notice that it's LDAP
D with ad at the end,
there's also a package called LIB NSS dash LDAP without that D letter at the end.
But this package that ends with ad has some improvements over the other one,
NSS is short for name service switch.
And it's just a convenient way for Linux to
get data about the various things from various sources.
So whenever a Linux system needs to
get information about things like user accounts,
groups, passwords, host names and other stuff,
it can consult the name service switch to find out where to get this data from.
Now after we run our command here.
Now, after we run our command,
we get a guided install wizard where it's
very easy to pass our configuration options.
Now note the highlighted red text at the top.
In this first step, we're configuring settings for something called NSL CD,
the name service local daemon,
a component responsible for retrieving data from the LDAP
server. That's why here we need to type in the IP address of our LDAP
server.
First,
we'll replace the 127.0 0.0 0.1 IP shown as an
example with the actual IP address of our LXC container,
the one that we copied earlier.
Now after our IP address,
we also add a forward slash just like we had in the example shown before.
After we press enter here, we get to the next configuration step.
We need to pick a distinguished name of the LDAP
search base.
LDAP can store information for a lot of departments in our organization.
So things are separated in a tree like structure
in our case. This is the part where we tell our name service local daemon,
which segment of this tree is storing information about our Linux users and groups.
And we have some helpful text that shows us an example of what we could enter here.
Now,
the LDAP server from our Linux container is configured to keep user and
group information in a tree stored under the code cloud.com domain name.
So the components of this domain are code cloud and com,
which means we will have two domain components here abbreviated as DC.
Now, in some cases, the LDAP
server might store information for a subdomain as well.
For example, users dot code cloud.com.
And if that were the case,
we'd need to add an additional component at
the beginning containing the name of that subdomain.
So we'll say DC equals users and this would equal users dot code cloud.com.
But let's delete this subdomain component since we don't need
it and press enter to continue to the next step.
And here's the most interesting part.
Since at this point,
we finally tell our Linux system where it can
find additional data for user and group accounts.
Passw
D refers to user data
group to data about groups and shadow is concerned with passwords.
So we'll take these first three boxes here, simply put we infirm.
OK?
So we're informing our system that user group and password data is
not only stored locally but on the LDAP server as well.
Note that this list goes down quite a bit and there
are more elements than we might currently see on the screen.
We don't need to enable LDAP lookups for the other entries here
since we're only concerned with user and group accounts in this lesson.
Now, let's press enter to wrap up our configuration.
OK.
So what does this configuration wizard do?
Well, we can already see from the output that it modified a file called Etsy
and a switch.com
short for name service switch.
If we take a look at this file, we'll see this.
The word LDAP was added to three lines in this file
equivalent to the three boxes that we ticked earlier in our configuration wizard.
So if we take a look at the first line,
this simply tells the name service switch that when it's looking for password data,
that is data about users,
it can find this information in three places
in the default files like the Etsy password file.
Then some user data might be provided by systemd
and finally valid user data is also present on the LDAP server.
But this simply informs the name service switch where it can pull data from.
However, it is not able by itself to pull data from LDAP.
So that's where the other component we looked at
NSL CD comes in
the name service local daemon is able to get that data from the LDAP
server.
And its main configuration file can be found at Etsy NS L cd.com.
So these are the files that we can edit if
we want to change something or fine tune settings.
Now, let's see if all of this actually works.
Remember at the beginning of our lesson when we checked for two user accounts,
John and Jane,
they weren't present on the system.
However, on our preconfigured LDAP
server, we added definitions for both of those accounts. So let's test it out.
Can our Linux system find these? Now,
now when we run the same two commands,
we can clearly see in the output that
our system now knows about these additional accounts
on our LDAP server.
We defined that both users should belong to a group named LDAP users.
Now,
this was done for convenience to make it easier to notice when
users were defined locally and which were defined on the LDAP server.
But we could have made these users part of any other group
to see all users, both those defined locally and those defined on the LDAP
server. We can use a command like this.
Get ENT is short for get entries
and this command asks the name service switch to show entries for the past WD section
to get this data from all of the sources. It has available.
All the users seen here are defined locally except the last two John and Jane,
which were defined on the LDAP server.
But we might want to filter output to only see entries from the LDAP
server.
To do that. We can pass the dash dash service option
and tell our command that we want entries only from the LDAP service.
Now to get group entries defined on the LDAP server,
we can enter this.
Now notice an interesting thing about our user entries above
on our LDAP server.
We fine tune these accounts a little bit and we provided data
about the full name of these users home directories and user shells.
But there's a slight problem.
We can see that John should have his personal directory at slash home slash John.
But if we take a look at our system, this location does not exist
and this can be an issue.
We can't manually create home directories for everyone.
Since we'd get back to the same problem described at the
beginning of our lesson with updating a whole bunch of servers.
Every time a new person comes in,
we'd have to reconfigure hundreds of
servers and create specific home directories.
But this has an easy solution as well.
We can use pluggable authentication modules also known as PM.
Every time a user logs in these modules are automatically triggered,
all we need to do is pass an additional instruction to them
to create a home directory. When someone logs in
in case that home directory doesn't exist.
Now, for this purpose, we will run this command
pseudo pam dash
a dash update and we will tick the box next to create home directory on login.
Then we'll press enter to save this change. Now, let's test this out.
We can enter the command to log in as John
and we can confirm that
So that's it.
Everything is working as expected.
Now, at this point, if we had 100 Linux servers configured the same way,
updating user and group accounts for all of these systems would be easy.
We just log to the LDAP
server, update data about our accounts
and all 100 Linux servers would instantly have it
available one central location where we can create,
remove or modify our Linux users and
passwords plus our Linux groups pretty convenient
and I hope you've enjoyed this lesson and I'll see you in the next one.