Hey everyone and welcome back. So in this skill right here we have two main concepts
you want to be focusing on. The very first one is something called Pam and then the next
one is something called Elda but the very first thing we'll do is we shall talk about
Pam first. So what exactly is Pam and what does it do for us? Well the reality is Pam
stands for the Plugable Authentication Modules. Now the clue is in the name right here. Simply put
if you have some type of application and you want to invoke some type of authentication i.e. how
the users themselves may be authenticated for example. You don't have to worry about writing
that into your application itself instead. This functionality is plugable directly into the
system by using Plugable Authentication Modules. So realistically all you have to do in order to
be able to control authentication of particular users is that you modify and manipulate these
Pam configuration files. So really this makes it much much easier for us to be able to authenticate
users as well as to control policy for security. So if say for example you wanted to invoke some
type of password history you know so that users cannot reuse passwords. Let's say your password
was originally hello1 you change it to hello2 and then when you change it again you want to change
it back to hello1 you can maybe permit or deny that type of behavior because password1 would
already be a previous password or maybe you wanted to control via IP address where someone could
log in from i.e. if they happen to come from the United Kingdom they had a UK based IP address. You
may be the side that you don't want to accept users from the UK people like me maybe we are
troublemakers and if you want to do that with Pam that is no problem at all. You can also effectively
put in some type of limits with respect to when users can actually access the system. Maybe you
don't want a user to access the system on a Saturday or Sunday or at midnight whatever it may be. The
policy itself doesn't actually matter the point I'm trying to make here is that you can set the
policy by modifying these Pam configuration files. So really this is a very very useful tool for us
because anything that can make our job simpler well that can't be a bad thing can it. So let's
talk about the Pam configuration file because it seems to me at least that this is really where all
the action is taking place. Now the reality is this configuration file is within the Etsy directory
and it's called Pam.conf. Now with respect to Pam.conf one thing I will say is that having all
your configurations directly within this particular configuration file this is a little bit outdated.
The reality is you're more likely to encounter within the Etsy directory you're probably going to
see a Pam.d directory and within this directory we're going to have a whole bunch of configuration
files so you know the way sometimes in Linux we can ultimately modularize and chunk up our
configuration files into multiple configuration files within a particular directory. This really
is what is happening in more modern implementations of Pam. We use the Pam.d directory which has
multiple configuration files relating to Pam but like I say we do want to be aware of the
Pam.conf if only for historical purposes with respect to the LPIC2 examination objectives.
So how about we actually look at this configuration file so if I go into my Etsy directory and I do
an ls and I happen to grep for Pam we can see here we have the Pam.d directory and here we have the
Pam.conf configuration file itself so if I go into the configuration file and hit enter check this out
now it even has the good manners to tell us that most programs will actually use a file under
this particular directory i.e we will have multiple files relating to specific services
in this directory as opposed to just using one global Pam.conf like I said but it's a good idea
to actually notice the structure right here so here is the deal we can see here the formats if you
look at this part right here and at the very left we see something called serve really this is the
service column now this is really relating to the service to which the module is related so say for
example you are running some type of SSH service and you wanted to have user authentication relating
to this SSH service then this is exactly where you would specify this in the very first column
now we also have the type column which you can see and this essentially has a bunch of different
values so within the type column what we can specify here in fact let me just write this up here type
we can specify information relating to the account now what the account value is going to specify
is really is this user going to be allowed on the system now we also have another option called
authentication this might sound like the exact same as account although it is slightly different
and that this is about the authentication of a user so we're thinking here about a password
so if you can imagine we tried to specify for the service SSH maybe we went into the type
and using the account we could specify the account ipv0 that means ipv0 would be in this case here
allowed to use the SSH service but of course just being allowed as a user is not enough
whilst that user is allowed this access someone has to authenticate themselves to prove that they
are that particular user and this is where we would specify ipv0's passwords which would
authenticate that user as ipv0 and allow or disallow if you so wish access to that particular
service that you are specifying now the next thing and this can be a little bit confusing
is we have our password option now all the password is it's relating to the changing of a
password so we can actually use the palm module to change a password be careful to remember that
this password option right here this has nothing to do with password authentication that is handled
by authentication and we also have lastly the session option and this is just going to relate to
this particular accounts environment with respect to the service of things like you know should you
mount the home directory of that user when they happen to use this particular service whatever
it may be so that is everything relating to the type option here next we can see here something
called control and this again has multiple different options so with respect to the control option we
have a bunch of different values we want to check out the very first one is something called the
requisite value so what we're seeing here with the requisite value is that the module must actually be
successful in authentication to actually operate that said if the module happens to fail the
authentication process what is going to happen is that the user is going to get some feedback
immediately telling that user that the authentication failed without any kind of delay the next option
we have would be the required value now this is very very similar to requisite the difference here
is that just like before for the authentication module to actually operate the results of the
authentication module must be successful the difference here though is that if the user fails
to authenticate at any point in the test you are not going to be immediately informed simply put
let's imagine you happen to have some type of server authentication this could be like say
something called a radius server or you happen to have some type of local authentication on the
system i.e the password restored locally if you log in if the system is configured to check
your credentials with the radius server and you happen to fail that authentication i.e you give
the wrong password well required is going to fail anyway but the difference is it's also going to
run through the other checks i.e it will then check the local password settings but here is the deal
even if you happen to provide credentials which match on the local database by virtue of you
failing the first check against the radius server you still will not be authenticated it will be
deemed as a failure the difference being here though is that instead of being immediately
told about your failure it's still going to run through the entire checks before reporting the
failure so a little bit confusing there one is going to tell you about the failure right away
the other one it might seem a little bit sadistic it's going to continue checking the other
authentication methods even though ultimately by virtue of failing earlier on you're still not going
to be authenticated so the next one we have is the sufficient control value in this case here if we
happen to get a pass we don't have to continue checking for any more this is more kind of like
or logic i.e we don't have to have everything authenticate and everything hits so whether we
happen to be authenticating with some type of external server like a radius server or LDAP or
a local database once we get authentication we do not have to continue checking a valid
authentication here anywhere it's going to give us the green light next we have the optional control
value now this is not a mandatory value instead this is only going to be needed only in particular
scenarios when say for example another module happens to rely upon it okay so we have the service
name we have the module type we then have the control flag then we specify the path to the module
and then we can actually provide arguments to that module path if the module path happens to take
any arguments that really is the basic setup of the original pam.configuration fail but like I say
more modern distributions are going to be implementing this directory based implementation
so let's actually check out the pam.d directory then so what i will do here is i'll just escape out
and i will go into pam.d i'm doing ls now we can see here in fact let me just long list this
now we can see instead of actually having a line in the pam.con file which tells you a
particular service instead we have these individual files which denote the service or say for example
within this file right here this will be related to cron which we can use for scheduling particular
tasks or say for example samba if you want to authenticate with samba we could go directly
into this file right here if we want to look at ssh authentication we could go into this one right
here so say for example we dive right into this one right here sshd then so i will say
sudonano sshd and go in here so notice the slight difference here no longer do we have
this service column we go straight to the type column which we can see right here so in this
case here this is the type account so this is going to be related to particular users who are allowed
to log in notice that the control flag says this is required and then we actually have the path to
the module itself here so this actual module here is pam no login dot s o and the little description
here ultimately tells us that this is going to disallow non-root logins whenever we have this
ssh no login file created now one thing i should actually specify here or point out is that we also
have this include option now all we are saying here is we want to include the rules that are
specified within this particular file so we have this file common auth and we can see here the sshd
configuration is relying on whatever is specified in here it is including it ultimately it is
consuming these rules so if we go into common auth now we can see this right here and hit enter we
can see the type is authentication we can see here that this is a requisite control value so we
know if the user happens to fail the authentication at any point the user is going to be told about
this failure immediately and here we can see it referencing the pam deny module which is ultimately
a module used to deny access and we'll get to look at the different pam modules in the next
nugget now we have a whole bunch of different files that we can configure right here if i happen to
go in let's say for example into the common passwords file if i scroll on down we can see here this
is going to be related to the password type which is about changing of passwords and here are some
of the checks we're going to run through we can see we're going to run through the pam unix s o
module we have additional features here we can see we have the sha 512 hashing algorithm what i'm
going to do is i'm first going to create a new user okay so let me show you this if i say sudo
user add and i just call this test account and then i will say sudo passwd for test account to
specify a password let's just say the password will be john okay so jio hn okay so that was a fairly
simple password what i will do is i will substitute the user to change into test account okay so i'll
say the user so i'll type in the password of john okay so if i say who am i we can see we have the
test accounts now what i want to do is i want to change my password but i want to add in some
additional controls here so what i will do is actually i'll go back to ipv0 and i will go into
the common password file and down here what i will do is i will specify the min length of a
password okay so i can use the keyword minlen and i'll make that password let's maybe say it's got
to be 11 characters long so think about this this is all about the password type which we know is
about changing passwords within my series of checks i'm going to make sure it checks that the min length
is 11 so let's save this and if i go back and i substitute user into test account and i will
type in john as a password if i happen to say passwd and i type in john as my current one
if i try to type in a password that is maybe just say 10 characters long so i'll just say jio hn
jio hn jio so that's john john joe that's only 10 characters if i hit enter and i do it again
jio hn jio hn jio and to answer it's telling me i must choose a longer password because we now need
to have 11 characters when we are changing a password now so if i'm going to change it what
i can say is jio hn jio hn jio h that will be 11 characters i do it again jio hn jio hn jio h and
hit enter suddenly now the password has been successfully updated but we're able to control
our authentication in a very particular way just by manipulating these palm configuration
files and the palm configuration file that i happen to manipulate was all about changing passwords
that was relating to that type of password but again like i say we can have control over the
account as the user allowed the authentication the changing of passwords or the session itself
what should actually happen for that user once they have become authenticated and again if we do
an ls-l we can see common account settings common authentication settings common password settings
and common session settings as well as session non-interactive sessions as well as as we can
see here these service specific authentication files which ultimately can if they so choose
include and call in these more general settings right here so i know that was a lot to get to
within this opening nugget it can be a very confusing concept when you first dig into it but
once you begin playing around with these configuration files and making the changes slowly but surely
things will begin to make sense but what we really have to understand are the different types of palm
modules available to us because these are crucial to the operation of pluggable authentication modules
and well that's what we're talking about in the very next nuggets i hope this has been
informative for you and i'd like to thank you for viewing