{"id":321,"date":"2009-12-28T11:18:00","date_gmt":"2009-12-28T11:18:00","guid":{"rendered":"https:\/\/questy.org\/?p=321"},"modified":"2024-09-26T19:13:07","modified_gmt":"2024-09-26T19:13:07","slug":"ldap-administration-part-ii","status":"publish","type":"post","link":"https:\/\/questy.org\/index.php\/2009\/12\/28\/ldap-administration-part-ii\/","title":{"rendered":"LDAP Administration \u2013 Part II"},"content":{"rendered":"\n

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

The Server<\/strong><\/p>\n\n\n\n

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<\/a> as a protocol\/standard.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\/etc\/openldap\/slapd.conf<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Let\u2019s start with a very simple slapd.conf file:<\/p>\n\n\n\n

\n

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

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

# bdb database definitions
database \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 bdb
suffix \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 “dc=bob,dc=com”
rootdn \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 “cn=admin,dc=bob,dc=com”
rootpw \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0secret
schemacheck \u00a0 \u00a0off

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

# Indexes to help speed up queries
index objectClass,uid,uidNumber,gidNumber,memberUid \u00a0 \u00a0
eq index cn,mail,surname,givenname \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0
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<\/p>\n<\/blockquote>\n\n\n\n

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\u2019ll add features and security as time goes on.<\/p>\n\n\n\n

\/etc\/ldap.conf<\/strong><\/p>\n\n\n\n

The \/etc\/ldap.conf file bills itself as the \u201cconfiguration file for the LDAP nameservice switch library and the LDAP PAM module\u201d.  While we just configured the operation of the server, we must now put the \u201cglue\u201d 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:<\/p>\n\n\n\n

\n

# 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<\/p>\n<\/blockquote>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Crank it Up!<\/strong><\/p>\n\n\n\n

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:<\/p>\n\n\n\n

\n

chkconfig –level 2345 ldap on<\/p>\n<\/blockquote>\n\n\n\n

And then use the RedHat tools to start the service up:<\/p>\n\n\n\n

\n

\/sbin\/service ldap start<\/p>\n<\/blockquote>\n\n\n\n

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.<\/p>\n\n\n\n

Populating the Database<\/strong><\/p>\n\n\n\n

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<\/em><\/strong> file in this location to match your environment like so:<\/p>\n\n\n\n

\n

$DEFAULT_MAIL_DOMAIN = “bob.com”
$DEFAULT_BASE = “dc=bob,dc=com”<\/p>\n<\/blockquote>\n\n\n\n

This file is sourced by all the migration scripts resident in this directory, and will automagically insert these values where necessary.<\/p>\n\n\n\n

Next, let\u2019s do a trial-run of converting our passwd file in \u201cLDAP-ese\u201d.  Since you\u2019ve already edited the migrate_common.ph, you can directly migrate your \/etc\/passwd and \/etc\/group files like so:<\/p>\n\n\n\n

\n

_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<\/p>\n<\/blockquote>\n\n\n\n

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

\n

> > 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<\/em><\/strong><\/p>\n<\/blockquote>\n\n\n\n

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\u2019ll come back to these later.<\/p>\n\n\n\n

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\u2019s hash.<\/p>\n\n\n\n

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\u2019ll be covering how I limit what users are allowed to access what systems in a later article.<\/p>\n\n\n\n

Importing the LDIF<\/strong><\/p>\n\n\n\n

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 <\/em>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.<\/p>\n\n\n\n

Once your LDIF file is how you want it to look, it\u2019s time to import.  Import it using the following command, modifying the search base and admin user to suit your configuration:<\/p>\n\n\n\n

\n

_ldapadd -W -x -D “cn=admin,dc=bob,dc=com” -W -f passwd.lif_<\/p>\n<\/blockquote>\n\n\n\n

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.<\/p>\n\n\n\n

Time to \u201cGet your GUI On\u201d<\/strong><\/p>\n\n\n\n

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

\n

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.<\/p>\n<\/blockquote>\n\n\n\n

Apache Directory Studio is available for Windows, Linux, and Mac OSX and is a freely-available Apache 2.0 licensed product.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Next time, we will tie PAM into LDAP, work with security and group-based access as well as cover a few \u201codds & ends\u201d to help you use your LDAP store in a variety of different ways.<\/p>\n","protected":false},"excerpt":{"rendered":"

Ok, so in our previous installment, we got LDAP all configured up from the client perspective.  I\u2019ll 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[8],"tags":[],"class_list":["post-321","post","type-post","status-publish","format-standard","hentry","category-open-source"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/comments?post=321"}],"version-history":[{"count":1,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/321\/revisions"}],"predecessor-version":[{"id":322,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/321\/revisions\/322"}],"wp:attachment":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/media?parent=321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/categories?post=321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/tags?post=321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}