chirp.syxyz.net

Simple LDAP authentication domain server and client

Here, I’ll admit it. One of the things I’ve always been a little scared of, in terms of Linux server administration, is LDAP. It’s obviously incredibly useful in many ways, not the least of which, it’s the most current and secure way of centralizing user, group and system configuration information, even across the web. And it offers great inter-operability with other types of systems, whether big-blue Unices, things that Came from Redmond, or even those slick little units that are Designed in California.

But, the nomenclature and concepts can be rather slippery at first, to the young mind (but here is a good intro). And while there is tons of documentation out there, it is not easy reading in general. In fact, it will guarantee to cure insomnia.

This guide is the result of an attempt to get user authentication sharing working via LDAP. After many false starts, it boils down to something pretty simple really. This won’t really be useful in a enterprise production system, but is a good way to get your feet wet.

This guide complements and supersedes my recent one on doing the equivalent thing with NIS. If you want info on that too, be my guest.

My LDAP domain will be syxyz.net, and my LDAP server is known as xulu. The server runs Fedora 11 and the clients are CentOS 5.

Server Side:

You’ll need 4 packages, as follows

# yum install openldap openldap-servers openldap-clients nss_ldap

Edit slapd.conf

To use the slapd LDAP server, modify its configuration file, /etc/openldap/slapd.conf, to specify the correct domain and server. Change the ’suffix’ and ‘rootdn’ settings:

suffix          "dc=syxyz,dc=net"
rootdn          "cn=root,dc=syxyz,dc=net"
rootpw          secret

We do need a ‘rootpw’ to query the database. Not sure why this is so, but ‘root’ does not refer to the system root user at all, it’s another root that applies only to the LDAP directory (in many examples it’s called ‘manager’ or something else to differentiate). We use a plain-text password here for simplicity, since this is only a test. There is also a way to use the slappasswd command to create an encrypted hash. RH docs have a more complete guide on this edit process.

Start slapd

# /etc/rc.d/init.d/ldap start

Migrate server’s flat-file data to LDAP Database.

Use migration tools to bring local server data into LDAP database.

The MigrationTools are a set of Perl scripts for migrating users, groups, aliases, hosts, netgroups, networks, protocols, RPCs, and services from existing nameservices (flat files, NIS, and NetInfo) to LDAP.

In RHEL 4 and 5, they are already installed as part of openldap-servers, and are found in /usr/share/openldap/migration. In Fedora 11, these are found in the migrationtools package and are installed at /usr/share/migrationtools. I’m using F11 for a server, so, adjust as needed for your system.

Follow the RH Knowledgebase guide exactly, editing migrate_common.ph to contain the proper domain information, and commenting out lines in migrate_all_online.sh until only lines pertaining to users and groups are left.

Now run the migration. It is very convenient as it creates all the top-level nodes and container hierarchy, which is one thing that is hard for people new to LDAP (like me) to grok at first:

# ./migrate_all_online.sh 
Enter the X.500 naming context you wish to import into: [dc=syxyz,dc=net]
Enter the hostname of your LDAP server [ldap]: xulu
Enter the manager DN: [cn=manager,dc=syxyz,dc=net]: cn=root,dc=syxyz,dc=net * rootdn from above
Enter the credentials to bind with: * [secret from rootpw above]
Do you wish to generate a DUAConfigProfile [yes|no]? no                    

Importing into dc=syxyz,dc=net...

Creating naming context entries...
Migrating groups...
Migrating users...
adding new entry "dc=syxyz,dc=net"

Importing into LDAP...
adding new entry "ou=Hosts,dc=syxyz,dc=net"

adding new entry "ou=Rpc,dc=syxyz,dc=net"

adding new entry "ou=Services,dc=syxyz,dc=net"

adding new entry "nisMapName=netgroup.byuser,dc=syxyz,dc=net"

adding new entry "ou=Mounts,dc=syxyz,dc=net"

adding new entry "ou=Networks,dc=syxyz,dc=net"
[...snip...]
adding new entry "uid=ldap,ou=People,dc=syxyz,dc=net"

/usr/bin/ldapadd: succeeded

Now your LDAP server should be ready to serve user and group information to clients. (It looks like we also brought in all groups and users, even the system ones below UID/GID 500 - ideally this would not be the case. There should be an easy way to constrain this)

A quick test

The following will check to make sure slapd is running and serving as it should:

# service ldap status
slapd (pid  4836) is running...
# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=syxyz,dc=net

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
# ldapsearch -x -b 'dc=syxyz,dc=net' '(objectclass=*)'
[... dump of all objects in the LDAP DB, should look like your users and groups ...]

Perforate firewall

If you are running iptables filters on the server (which you should be), you’ll need to open up port 389 UDP and TCP.

Add to /etc/sysconfig/iptables, above the REJECT lines

# ldap
-A INPUT -m state --state NEW -m udp -p udp --dport ldap -s 192.168.0.0/16 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport ldap -s 192.168.0.0/16 -j ACCEPT

then, in the shell

# service iptables restart

Client side

OK, on to the client side. This will be really simple, if you use the RH GUI tool.

You will need the ‘openldap’ package installed.

# yum install openldap

As root, run the GUI ’system-config-authentication’

# system-config-authentication

Look, isn’t it gooey? In both the ‘User Information’ and ‘Authentication’ tabs, check ‘Enable LDAP support’. Then in the ‘Configure LDAP’ dialog, enter the information about your server- the Search DN in my case is ‘dc=syxyz,dc=net’ and the server is ‘ldap://xulu/’ (you could use the IP addr if your server’s hostname won’t resolve from the client)

ss-16

Test

So, give it a whirl. Try to log in on the client as one of your users that exists on the server. You should be able to. Check the syslog on both systems in case of error.

Time for a beer

Now, you have a lightly secured LDAP-based authentication system on your network. Next steps would be to consider enabling TLS and encrypted passwords all around.

You can (and probably should) also set up autofs so that the user’s home directories are centralized as well. Since this is the same as the autofs-related steps in my previous NIS post, I won’t go into that. I actually used the same systems and left the autofs part alone, so had to do nothing.

Server Side:

Edit slapd.conf

Migrate server’s flat-file data to LDAP Database.

A quick test

Perforate firewall

Client side

Test

Time for a beer

See also