Once you’ve got your handy LDAP server authenticating users for login throughout your environment, inevitably you find yourself getting around to the question of authentication for all your backend tools/services machines.  Can you authenticate from Apache to that same auth store to reduce administration burden across the environment?

Yes you can.

Recall from part I of this series that we have a server that is serving auth for our mythical “Bob.com” environment.  Recall also the important info regarding this environment:

Internet domain name:                   bob.com
hostname of the server:                   ldap.bob.com
LDAP Search base:                          dc=bob,dc=com

File:  /etc/openldap/ldap.conf
#
# LDAP Defaults
#

BASE dc=bob,dc=com
URI ldap://ldap.bob.com
TLS_CACERTDIR /etc/openldap/cacerts

Now, we add to the mix an Apache web server that has an area it wants to secure.  Instead of using the old htpasswd method to create a disk-file containing usernames and password hashes, it would make much more sense to simply point Apache’s authentication system at our shiny new LDAP server so we eliminate yet another user/pass system we have to administer.

Apache

As many of you are already aware, Apache offers simple authentication to allow/disallow access to specific shared directories over the web.  The Apache Project has detailed documentation to help you get started here. I’ll cover the basics here.

Traditionally, in Apache’s config file(s) you specify a directory you wish to have secured via the “Directory” directive like so:

AllowOverride None
Options ExecCGI Includes
Order allow,deny
Allow from all
AuthUserFile /secure/passwd/file/location
AuthType Basic
AuthName “Cool Security Name”
Require valid-user

You then create your passwd file for Apache with the htpasswd utility, make sure the above path points to it, bounce Apache, and you’re authenticating locally.  Problem with this is that every time you need to add a new user to your environment, every instance like this has to be touched individually and you have to add the user (whether by copy/paste or otherwise is irrelevant) in each.

Enter LDAP.

Fortunately, the configuration for such a change is quite easy; Simple textual changes to the httpd.conf to repoint from the local disk file to the LDAP store is all you need.  First, make sure that your LDAP modules are properly loaded into Apache:

LoadModule ldap_module modules/mod_ldap.so

LoadModule authnz_ldap_module modules/mod_authnz_ldap.so

This tells the Apache core to load up these at startup so that the directives you supply in the Directory stanza will be understood.  Next, let’s add the appropriate info into the Directory section:

AllowOverride None
Options ExecCGI Includes
Order deny,allow
Deny from all
AuthName “Cool Security Name”
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative Off
AuthLDAPURL ldap://cool.ldap.server/dc=bob,dc=com?uid
AuthLDAPBindDN “cn=admin,dc=bob,dc=com”
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
AuthLDAPBindPassword 
Satisfy any

This simple change (after an Apache restart) should give your Apache server security over that directory, authenticating against LDAP.  Since your LDAP store is POSIX compliant for login, you have a few other things you can leverage in there as well.  Among those, are the “Group” field.  That’s right, instead of going out and adding individuals and/or preventing them, you can specify an entire class of people (say LDAP_Logins for instance) that if the user belongs to that group, suddenly they have access to anything that is authenticating against LDAP.

To add that ability, you can add groups to the stanza above like so:

Require ldap-group cn=mygroup,ou=Group,dc=bob,dc=com
Require ldap-attribute gidNumber=500
(you place your group number in place of the “500” above)

Now that you have the magic behind LDAP auth for Apache, you can add this to any Apache web server of the 2.x variety, and do your security centrally.

The ease of addition for new users on your network is now as simple as adding the user to your LDAP store, placing them in the appropriate group.  Once Apache was restarted the very first time to make this work, you never have to restart it for user additions.  It will simply query LDAP, and LDAP will provide the credential response Apache needs to continue forward.

Next time:  Sudoers in LDAP!

By now you should have a functional LDAP server, a properly configured client, and the ability to authenticate against your server.  However, the last couple “cogs in the wheel” are left to manage.

Generally speaking, when you add a user in UNIX-land, part of the process of the adduser command also sets their shell, creates a home directory for them and so forth.  As you may notice, there is no particular method to make this happen in Linux-LDAP.  You just have a store and a tool to manage the store.

Have no fear, it’s PAM to the rescue.

As we said in our first installment, the following packages are all that is necessary to have the basic plumbing of LDAP to work:

openldap
openldap-servers
openldap-clients
openldap-devel

While that is true, there are a couple more packages that put the finishing touches on this to make it sing.  Those are:

nss nss_ldap nscd

NSS is a glibc mechanism or interface allowing access to the common UNIX databases such as the password or hosts database.  It is most commonly used to provide an interface to both local /etc/passd and /etc/shadow files and usually for the purposes of interfacing with LDAP or NIS.

NSS_LDAP is a set of C library extensions which allows X.500 and LDAP directory servers to be used as a primary source of name service information such as users, hosts, groups, and other such data historically managed via local flat files or a NIS infrastructure.

NSCD is a name services caching daemon that provides a cache for the most common name requests.  While useful in speeding up response to queries, nscd has it’s own set of problems.  I’ll cover only some of it’s usefulness, and you should circumspectly determine whether you will need caching at all based on your organization’s size and the size of your serving infrastructure.

Home Directories

First and foremost, to make the login process as pleasurable/smooth an experience as possible, there are some things that we generally do in standard administration practices that ease the user’s experience.  Namely, we setup a standard set of configuration and environment files to provide a consistent user experience of the shell.  These are usually their home directory files such as:

.bashrc .bash_profile .bash_logout .vimrc .mozilla

Usually these are handled in the usual way via the useradd command, which also copies one of everything from the /etc/skel directory to your user’s home.

As you can see, simply adding a user to the LDAP store would not give occasion for this to happen.  PAM to the rescue!  PAM contains a module that is their “mkhomedir” module.  Depending on your architecture, this lives in the /lib or the /lib64 directories under “security”:

/lib/security/pam_mkhomedir.so /lib64/security/pam_mkhomedir.so

What these modules do when properly invoked is on the first connection of a user that is validated as a proper user/password combination via LDAP, PAM sees that they have no home directory, and creates the home directory for them just as if you, the administrator had created it with the adduser script.

This, by far, is one of the handiest modules provided by PAM.

Turning on the PAM

To turn on the mkhomedir facility for your servers and clients, simply do the following:

In /etc/pam.d there are a number of configuration files for handling login defs for varying circumstances.  What we are interested in is system-auth.  System-auth is also sourced by the sshd option, so this will work for both console logins and ssh/remote logins.

The last stanza of the system-auth configuration file is the “session” section.  On the second-to-last line between the pam_unix and pam_ldap designations, add the following:

session     required     pam_mkhomedir.so

This is a keyword set that tells Linux to load up and perform the functions offered by the pam_mkhomedir module.  Now, whenever you connect to a system configured in this way, it will automatically create the user’s skel information and change ownerships to the proper settings so the user can login.

Security

You may note that I also referred to using group-based security.  In LDAP/PAM-land, this is just as simple as the above PAM setup.  Look into the individual system’s /etc/security directory for a file called access.conf.  This file allows you to grant/deny access to individual users, groups, and also where they can connect to this machine from.  The syntax is clearly explained in the file itself, but here’s an example.

Let’s say I only want root, wheel, and the admins group to be able to access a certain system.  let’s say they can access this system from anywhere.  Now let’s say I also want the backup group to access the same system, but only from one host.  The setup is quite simple.  First, let’s allow complete access to the people we wish to be able to connect from everywhere.  At the end of the /etc/security/access.conf file, add the following line:

+: root wheel admins : ALL

This tells the system to add access for root, wheel, and admins from ALL hosts.  Now, let’s put in those backup admins, but only allow them to connect from the host we want them to come from:

+: backup : 10.1.10.10

This means the backup group can access this host, but only from the host 10.1.10.10.  There are many other methods of allowing and denying access in this file.  The documentation is contained within the file, so feel free to look through it for more information.

The MOST important line is the last line, however.  After you’ve setup all the people you WANT to access the system, that does no good if all access is still left on for everyone, everywhere.  The final line in the file should be to deny all access to anyone else not specified above, and would look like this:

• : ALL : ALL

Simply stated, this removes (or subtracts) all access for ALL other users from ALL other hosts.  This line is evaluated last after the preceding lines are, and will take the preceding lines into account when setting up it’s rules in memory.

At the very worst, if you mis-order the lines here, you may not be able to login to the system and will need to boot to single-user mode and then use the article here on this site entitled “A Neat Trick” to make /etc read/write so you can change the configuration and then reboot back into your system’s default runlevel, but if you’re careful, this will be quite easy to configure and manage.

Closing Thoughts

I’m sure there’s a few things I left out, and I will be revising this series at some point in time to allow for any omissions I’ve made.  I will also be adding in feature suggestions and will be following this up with a sudo article so you can overlay the “on-box” security set you’d like to see happen in your environment after your LDAP infrastructure is in place.

Feel free to drop me a note if you see anything amiss, and I’ll be sure to correct it and give you props.

Ok, so in our previous installment, we got LDAP all configured up from the client perspective.  I’ll cover some other client-based niceties such as extra PAM modules and security in our third installment.  For now, back to the show!

The Server

The lightweight Directory Access Protocol (LDAP) gives us tons of things to use to help make the system login/logout process easy to manage and maintain.  The LDAP server runs over the Berkeley Database (BDB) as a data backend, and has a long history as a protocol/standard.

As we said last time, the server configuration consists of the contents of the /etc/openldap directory with the primary file of interest being the /etc/openldap/slapd.conf file.  The secondary file of interest will be the /etc/ldap.conf file, another server configuration file.

/etc/openldap/slapd.conf

First, we will cover the ldap daemon (slapd) configuration file, /etc/openldap/slapd.conf.  This file is responsible for specifying information regarding what schemas to use, loggin parametwes, database specifications and locations, security, replication, and security grants.

Let’s start with a very simple slapd.conf file:

# OpenLDAP Server Configuration
# Primary Server Schemas
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/redhat/autofs.schema

# Logging
loglevel 0
pidfile      /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args

# bdb database definitions
database             bdb
suffix                   “dc=bob,dc=com”
rootdn                 “cn=admin,dc=bob,dc=com”
rootpw                secret
schemacheck    off

# location of the data files
directory              /var/lib/ldap

# Indexes to help speed up queries
index objectClass,uid,uidNumber,gidNumber,memberUid    
eq index cn,mail,surname,givenname                                                
eq,subinitial

# Grant users rights to change their own password
access to attrs=userPassword
by self write
by anonymous auth
by dn.base=”cn=admin,dc=bob,dc=com” write
by * noneaccess to *
by self write by dn.base=”cn=admin,dc=bob,dc=com” write
by * read

This is a very basic slapd.conf file without TLS security information, without replication information, and without any frills at all.  Recall that our primary goal here is to get a basic LDAP server running and working without any frills.  We want the ting to work, and then we’ll add features and security as time goes on.

/etc/ldap.conf

The /etc/ldap.conf file bills itself as the “configuration file for the LDAP nameservice switch library and the LDAP PAM module”.  While we just configured the operation of the server, we must now put the “glue” in place so that PAM knows how to ask questions of the LDAP system to know if a user is allowed to login or not.  Again, a very simple /etc/ldap.conf file:

# ldap.conf — simple configuration # Distinguished name of the search base base dc=bob,dc=com # The distinguished name to bind to the server with binddn cn=admin,dc=bob,dc=com # Password to bind to the directory with bindpw secretpassword # Search TimeLimit timelimit 120 # bind/connection timelimit bind_timelimit 120 # idle timelimit idle_timelimit 3600 # PAM password format pam_password md5 # Assume no supplemental groups for these named users nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman # Main LDAP configuration piece uri ldap://ldap.bob.com ssl no tls_cacertdir /etc/openldap/cacerts

A couple of notes here.  First, the nss_initgroups_ignoreusers portion can most likely be left out.  This is an artifact (as far as I am aware) of being on a RedHat system as several of these users are defaults on RedHat.  Next:  The timelimits are just sane numbers, nothing special.  Should there be any need for tweaking this, it will be in your own experience across your own environment.

Much like the earlier client configuration file, this serves somewhat the same purpose, but for the PAM system as a client rather than a system itself as a client.

Crank it Up!

At this point, you should be able to start up your server to begin configuring it for use.  In RedHat-land, as many of you already know, this is typically a two-part process.  First, you set the service to start at boot and then you start it up.  First, run the command to set the runlevels in which you want ldap to start:

chkconfig –level 2345 ldap on

And then use the RedHat tools to start the service up:

/sbin/service ldap start

At this point, you should have a fully functional LDAP server running with no particular schema or setup, ready to take data (in our case, POSIX compliant login information) and serve it out to your infrastructure.

Populating the Database

With the RedHat packages come a myriad of important tools you need to help migrate your current authentication information into the LDAP store.  The location of these helpful perl scripts is: /usr/share/openldap/migration.  Before you use these tools, make sure you edit the migrate_common.ph file in this location to match your environment like so:

$DEFAULT_MAIL_DOMAIN = “bob.com”
$DEFAULT_BASE = “dc=bob,dc=com”

This file is sourced by all the migration scripts resident in this directory, and will automagically insert these values where necessary.

Next, let’s do a trial-run of converting our passwd file in “LDAP-ese”.  Since you’ve already edited the migrate_common.ph, you can directly migrate your /etc/passwd and /etc/group files like so:

_From the /usr/share/openldap/migration directory:_ ./migrate_passwd.pl /etc/passwd ./passwd.ldif _Similarly, convert your groups file as well:_ ./migrate_group.pl /etc/group ./group.ldif

What these commands will do is convert your standard /etc/passwd and /etc/group file to ldif-formatted files for import into your LDAP store.  Let’s look at a record for an example:

> > dn: uid=bin,ou=People,dc=best,dc=turner,dc=com > > > > uid: bin > > > > cn: bin > > > > objectClass: account > > > > objectClass: posixAccount > > > > objectClass: top > > > > objectClass: shadowAccount > > > > userPassword: {crypt}* > > > > shadowLastChange: 14251 > > > > shadowMax: 99999 > > > > shadowWarning: 7 > > > > loginShell: /sbin/nologin > > > > uidNumber: 1 > > > > gidNumber: 1 > > > > homeDirectory: /bin > > > > gecos: bin > > dn: uid=bin,ou=People,dc=best,dc=turner,dc=comuid: bincn: binobjectClass: accountobjectClass: posixAccountobjectClass: topobjectClass: shadowAccountuserPassword: {crypt}*shadowLastChange: 14251shadowMax: 99999shadowWarning: 7loginShell: /sbin/nologinuidNumber: 1gidNumber: 1homeDirectory: /bingecos: bin
NOTE: Formatting Lost

The LDIF format has a number of self-explanatory fields that you can see correlate to your /etc/passwd file.  There are other fields here that LDAP needs, but are beyond our concern at this point.  We’ll come back to these later.

I picked a system-default user just to illustrate the format of the ldif.  This user generally has no password, and thus you cannot login using his credentials.  In the userPassword line above, for a regular login user, you would normally see {crypt} followed by a rather large SHA encrypted string representing the user’s hash.

This brings about the question of how you wish to manage your users.  Generally speaking, I allow the local /etc/passwd file manage root and all system-default users (bin, spool, lp, etc.) and all users I add post-installation get placed into LDAP.  In that way, I manage the user centrally from the outset.  I’ll be covering how I limit what users are allowed to access what systems in a later article.

Importing the LDIF

Once you have your LDIF, you have some decisions/edits to make.  look through your dumped ldif file.  Remove each stanza relating to the users you do not wish to manage via LDAP.  The resulting LDIF file will be the one we import.  Generally speaking, in a RedHat system I delete everything before UID 500 (which is usually me) and import everything else.

Once your LDIF file is how you want it to look, it’s time to import.  Import it using the following command, modifying the search base and admin user to suit your configuration:

_ldapadd -W -x -D “cn=admin,dc=bob,dc=com” -W -f passwd.lif_

When you run this command, the LDAP server will churn for a moment (depending on how large your passwd file is) and then will return a clean shell with no errors.

Time to “Get your GUI On”

At this point, I usually point people toward the excellent Apache Directory Studio available at the Apache Directory Project.  This is a gui directory administration tool that can browse and edit your entire store.  The Apache Foundation describes it like so:

Apache Directory Studio is a complete directory tooling platform intended to be used with any LDAP server however it is particularly designed for use with the ApacheDS. It is an Eclipse RCP application, composed of several Eclipse (OSGi) plugins, that can be easily upgraded with additional ones. These plugins can even run within Eclipse itself.

Apache Directory Studio is available for Windows, Linux, and Mac OSX and is a freely-available Apache 2.0 licensed product.

Once you download and configure the Apache Directory Studio, you should be able to view, browse, edit, and manage all aspects of your LDAP store.

Next time, we will tie PAM into LDAP, work with security and group-based access as well as cover a few “odds & ends” to help you use your LDAP store in a variety of different ways.

One of the things I’ve worked on over the last year is setting up a centralized LDAP server for authentication in a UNIX environment.  My clients range from early RedHat to our current distro of RH5.2 or CentOS5.2.

A huge issue I’ve run across while doing this work is that I had to piecemeal the information together from all over the Internet because the grand majority of what I could find out there was either for Windows clients or non-POSIX login authorization.

I plan to tell this story mostly in the context of a RedHat-ish rpm-based distro, and the setup of both the server and a Linux client to tell both sides of the story.  I will use my own terminology to begin, making it very simple to explain precisely the setup we’re looking for without getting into a lot of LDAP-ese.  As we go through the setup, I will slowly start to relate my description back to LDAP-ese so you can, once your setup is working, go back to the documentation and determine “just what happened here”

At the end of the story, I’m going to have a LOT of keywords so Google gets a good sampling of this to help someone who may be like I was, looking for a very specific UNIX auth implementation.

Server

One of the big things I needed first was to have the server packages installed.  When I did the original installation, I went a little overboard and downloaded and installed everything from the patch level I used, but the essentials are:

openldap openldap-servers openldap-clients openldap-devel

After getting these installed (via either yum or rpm -i…whichever is your preference) then you should have a subset of important files and tools lying about around your system.  These will be (in no particular order):

/etc/openldap /etc/openldap/slapd.conf /etc/ldap.conf

The /etc/openldap directory houses all the files pertaining to your server piece.  From your certs to the appropriate schemas to an example DB_CONFIG for the LDAP backend (Berkeley DB…more about these later…)  The primary file of interest in /etc/openldap will be slapd.conf.  In /etc/ldap.conf, you have the server configuration file.

In my setup, the purposes and configuration of these particular files seemed to be the biggest hinderance to getting everything running as I would expect.  At one moment, there was a config element in /etc/ldap.conf and in another there was one in /etc/openldap/slapd.conf.  It appears there has been some overlap from version to version, and even now you have to take all files together, viewing it all as a single configuration.  That’s where we will start.

/etc/ldap.conf

I’d say that my first confusing issue was that this file serves different functions depending on whether you are looking at a server or a client.  For the client, it is a simple, short file specifying the server and the ldap URI to use for searches.  In the server context, it is for the LDAP nameservice switch configuration and the LDAP module for PAM.

/etc/openldap/ldap.conf 

Let’s start with the client config.  I know this is putting the cart before the horse, but it is the simplest part of this procedure.  If we configure it now and utilize it in it’s easiest configuration, we know that once resolution and searches are functioning, the server is setup correctly.

First, let’s talk about your organization a bit before launching into this configuration.  Recall that our entire purpose at this point is POSIX-compliant user/pass functionality and everything that implies.  I’m not looking for a phonebook (what seems to be a large portion of the tutorials out there on the ‘net and in the O’Reilly LDAP book) and I’m not looking to find where employee X sits.  I want user/pass/GECOS, etc. of a POSIX-compliant login.

Most organizations are on the Internet these days.  Let’s take my mythical company “Bob.com”.  Bob’s company, Bob.com has a website and all the standard DNS resolution and email and the like for Bob.com is already working perfectly.  It already has a nifty website driving tons of customers to Bob’s company.  As for the infrastructure of UNIX logins and passwords, the ONLY THING that Bob.com and LDAP have in common is that their bits and bytes are traveling over the same wires as Bob.com’s Internet traffic.  That’s where the connection ends.  When we start talking about the naming in the LDAP space, even though Bob.com is valid in the Internet as well as the LDAP world, they have absolutely nothing to do with one another from a technical perspective.

In LDAP-land, Bob.com is the name of the company we will be serving.  So, think of this as the top of your tree from which all the other branches will grow.  Bob.com is your organization.  It is also the top of your tree.  This is a conceptual designation.

We will be installing the LDAP server on a piece of server hardware hanging in a rack.  This server will have a DNS hostname, and will be called ldap.bob.com.  This has absolutely nothing to do with LDAP-land.  This is simply the every day server naming and numbering like you would do for a new name/app/web server and the like.

The top of our conceptual tree in our organization is the bob.com base name.  In LDAP-land, we refer to this as your “search base”.  This is the name root from which all things flow.  Like an OU in active directory or a root filesystem in UNIX, everything happens under this.  So, for our LDAP-land based conceptual idea of our organization, we will have a base distinguished name of Bob.com.  In LDAP-ese, we refer to a base by it’s separate parts.  In the case of the base name (for our purposes) these separate parts are known as “domain components”.  This, should you choose an LDAP name space to match your Internet name space, is the sole point where these two worlds converge.  Bob.com is an Internet domain name while the LDAP-ese separations of the search base are called “domain components”.

Let’s see what this looks like:

Internet domain name:                   bob.com
hostname of the server:                   ldap.bob.com
LDAP Search base:                          dc=bob,dc=com

If you remember some of your DNS-fu, you’ll recall that the host/domain portions of the Internet name have significance in IP-Address land, but that is outside the scope of our little discussion here.  The important thing for you to know is that bob.com is an Internet-based domain name that can be resolved in your browser of choice to a location on the Internet for your viewing pleasure.  The LDAP name space of dc=bob,dc=com is an LDAP-formatted representation of the search base of your organization conceptually referred to as Bob.com.

I know that was painful, but the distinction is paramount to proper understanding of this process, how it is named, and how it is used.

So, let’s take our client configuration and give it a whirl…

Configuring a Client

Simply stated, the client only needs to know three things.  First, it needs to know our base conceptual name (or search base), an Internet-formatted URI to know how to get to the host that has this storehouse of information, and the OS itself needs to know to look at LDAP for this information rather than local files.  Let’s look at a client machine’s local file:

File:  /etc/openldap/ldap.conf

#
# LDAP Defaults
#

BASE dc=bob,dc=com
URI ldap://ldap.bob.com
TLS_CACERTDIR /etc/openldap/cacerts

That’s really all there is.  The search base and the URI to find the server.  You already know about the file that tells UNIX where to look for information.  It is the file /etc/nsswitch.conf

This file contains mappings regarding what the system should look at for which services.  The file is in the format:

service:     location1 location2 location3…

You can have as many locations as you need for UNIX to search, but we’re only going to worry about two.  local files and the LDAP store.  In the /etc/nsswitch.conf file, you will have three lines for authentication we are concerned with.  They will look like so:

passwd:     files
shadow:    files
group:        files

This essentially tells the system  that for passwords, password hashes, and groups that you should look at the local files.  Pretty straightforward.  However, to point us at the LDAP server for this information, you need only change this file in the following way:

passwd:     files ldap
shadow:    files ldap
group:        files ldap

What this will do is check the local files for a user and then the LDAP store for that user.  If they do not exist locally, they will resolve from LDAP.  The caveat here is that the user you’re trying to login with for testing LDAP should not already exist on the client system.  If it already does, you have a possible issue in that things will work, and you’ll never know if you’re resolving from local files or LDAP.  I’ll show you how to handle this later.

That’s it for the client.  Now we have a client configured to shout at ldap.bob.com using the search base of dc=bob,dc=com looking for password, shadow, and group information for POSIX compliant logins on your client host.

Next time, we’ll start setting up the server.