特殊:Badtitle/NS100:OpenLDAPServer

{{#ifexist: :OpenLDAPServer/zh | | {{#ifexist: OpenLDAPServer/zh | | {{#ifeq: {{#titleparts:OpenLDAPServer|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:OpenLDAPServer|1|-1|}} | zh | | }}

Introduction

LDAP is a way to make certain kinds of information available across a network. In this example, the information is user logins- their passwords, user IDs, and various details.

If you NFS export /home on a large, protected machine to the local network, then use LDAP on that machine to decide who logs in, then all the machines on the local net become special. It's like every user has an account on all machines...and all their data is always there.

This is not only convenient, but can protect your data; when a machine dies, it won't take your hard work with it. This is remote authentication, or sometimes "Single Sign On" or just "SSO".

Kerberos is actually a better means to do this, but it's also more complicated. When you're ready, check SingleSignOn that describes it.

LDAP means Lightweight Directory Access Protocol, a simplified version of X500 protocol. You will find a more detailed presentation on Wikipedia.

The big picture

All information is stored in the "Directory Information Tree" or DIT. You have to decide upon a 'root' for that tree, then design it's branches.

Here's our simple tree:

• • "dc=example,dc=com" (your root)
  • "People" node where your users will be stored
  • "Groups" node where your groups will be stored

The packages will ask you for the 'root' while installing. It can be "mydomain.net" or "fred.local", but make it something clear and concise. LDAP separates the two parts; "fred.local" becomes dc=fred,dc=local. The "dc" means "domain component".

Then we teach the clients how to use this DIT to allow or deny access.

Installation

First, install the ldap server daemon (slapd) on the server ; install the following packages: slapd, ldap-utils, and db4.2-util (see InstallingSoftware).

Enter your domain as asked and the password that you want for the directory administrator. This isn't the same as the system's root password, and it should never be.

Few changes will be made during the default configuration. First set the DIT's root password in the configuration file (instead of in the directory) by editing the file /etc/ldap/slapd.conf.

Don't use a cleartext password however. Generate an encrypted password with slappasswd:

$ slappasswd
New password:
Re-enter password:
{SSHA}d2BamRTgBuhC6SxC0vFGWol31ki8iq5m

This example shows what happens when using "secret" for the password. (your result will vary)

Now edit /etc/ldap/slapd.conf and copy paste that string.

# Make sure you edit or add these directives after the first 'database' directive.

suffix          "dc=example,dc=com"
directory       "/var/lib/ldap"
rootdn          "cn=admin,dc=example,dc=com"
rootpw          {SSHA}d2BamRTgBuhC6SxC0vFGWol31ki8iq5m

Use /etc/init.d/slapd restart to start it.

Populating The LDAP Tree

The directory ready, let's populate it. This will be a 'classical' entry intended to be very compatible with Unix accounts (posix), directories (like addressbooks), and classical accounts (for web applications). But really it's just a starting point.

An LDAP directory can be fed with a ldif file ("ldap directory interchange format" file). Create this file init.ldif somewhere on your system:

dn: dc=example,dc=com
objectClass: dcObject
objectClass: organizationalUnit
dc: example
ou: Example Dot Com

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword: <password>

dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups

dn: uid=lionel,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: lionel
sn: Porcheron
givenName: Lionel
cn: Lionel Porcheron
displayName: Lionel Porcheron
uidNumber: 1000
gidNumber: 10000
userPassword: <password>
gecos: Lionel Porcheron
loginShell: /bin/bash
homeDirectory: /home/lionel
shadowExpire: -1
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax: 999999
shadowLastChange: 10877
mail: [email protected]
postalCode: 31000
l: Toulouse
o: Example
mobile: +33 (0)6 xx xx xx xx
homePhone: +33 (0)5 xx xx xx xx
title: System Administrator
postalAddress:
initials: LP

dn: cn=example,ou=groups,dc=example,dc=com
objectClass: posixGroup
cn: example
gidNumber: 10000

In the example above, the directory structure, a user and group have been defined. In other examples you might see the objectClass: top added in every entry, but that is default behavior so you don't have to add it explicitly.

As with the LDAP root password, these passwords can be generated with slappasswd using the MD5 or CRYPT hashing scheme. See man slappasswd).

When you're done, write and close the file.

Now, add your entries to the LDAP:

• • stop LDAP daemon: sudo /etc/init.d/slapd stop
  • delete the content that was automatically added at installation: sudo rm -rf /var/lib/ldap/*
  • add the new content sudo slapadd -l init.ldif
  • correct permissions on the database sudo chown -R openldap:openldap /var/lib/ldap
  • start LDAP daemon: sudo /etc/init.d/slapd start

Alternatively, to add the entries when you just installed the packages:

• • reconfigure your LDAP installation when needed: sudo dpkg-reconfigure slapd
  • start LDAP daemon when not running: sudo /etc/init.d/slapd start
  • load the initial data: sudo ldapadd -x -W -c -D "cn=admin,dc=example,dc=com" -f init.ldif

We can verify the content with the tools from the ldap-utils package. Here we search for the user we created:

$ ldapsearch -xLLL -b "dc=example,dc=com" uid=lionel sn givenName cn
dn: uid=lionel,ou=people,dc=example,dc=com
cn: Lionel Porcheron
sn: Porcheron
givenName: Lionel

Just a quick explanation:

• • -x is because we do not use SASL authentication method (default)
  • -LLL disable printing LDIF information

Optional: LDAP logging

Many times the "loglevel" value in /etc/ldap/slapd.conf can be confusing. It's meaning is encoded in binary. And usually it mentions things you don't recognize, or a flurry of meaningless things. But if you need to see what the server's actually doing, try "loglevel 424". It allows for many kinds of things, most of which will be very clear. For specific details so you can decide on your own numbers, see the man-page.

Put your LDAP server to use

Now that it is up and running you can:

• authenticate your users on the directory as explained in UbuntuHelp:LDAPClientAuthentication
• authenticate your users in a web application.
• use it as a shared address directory for your mail agent.

Use of LDAP are infinite !

Security

Since this will be the home of your user's passwords, we need to lock it down. LDAP has a mechanism designed to do just that: Acess Control Lists or ACLs.

Authentication requires access to password field, that should be not accessible by default. Also during password change, shadowLastChange needs to be accessible too. Here's how we do that:

access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=example,dc=com" write
by anonymous auth
by self write
by * none

Usually the installation of the OpenLDAP packages will create correct ACL settings in the slapd.conf configuration file. Taking the time to learn these would not be wasted.

LDAP replication

LDAP service often quickly becomes a highly critical service in an information system: all is depending of LDAP: authentication, authorization, mail system, etc. It can be a good idea to setup a redundant system. It is easy to setup, here is a quick HOWTO.

Introduction

With OpenLDAP 2.2 (on Breezy and Dapper), replication is based on a master-slave relation.

Before implementing LDAP replication consider the following steps:

• Stop the master server's slapd daemon.
• Reconfigure the master server's slapd.conf to enable replication to the new slave server.
• Export the database of the master server.
• Configure the replica server's slapd.conf.
• Import the database of the master server to the slaver server.
• Re/Start the replica server's slapd process
• Re/Start the master server's slapd process.

You will have to remember that modifications should ALWAYS be done on the master ! If you modifies the slave, modifications will get lost.

LDAP master

On the master, you have to modify the database section of the /etc/ldap/slapd.conf to add a replica instruction. The following example shows a replica on ldap-2.example.com with the Manager user with secret as password. The replication logfile is the place modifications are stored before they are send to the LDAP slave.

replica uri=ldap://ldap-2.example.com:389 binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret

replogfile      /var/lib/ldap/replog

Export the database of the master using slapcat. Then copy master.ldif to the slave using scp or other tools.

user@master:~$ sudo slapcat -l master.ldif

LDAP slave

On the slave, you have to authorize your master to update LDAP database. Add the following lines to your /etc/ldap/slapd.conf file in the database section:

updatedn        cn=Manager,dc=example,dc=com
updateref       ldap://ldap-1.example.com

Import the master.ldif using slapadd.

user@slave:~$ sudo slapadd -c -l master.ldif

Restart the master server.

user@master:~$ sudo /etc/init.d/slapd start

Restart the slave server.

user@slave:~$ sudo /etc/init.d/slapd start

Samba Integration

While there are lots of documents out there explaining how to do Samba integration with LDAP, the definitive guide, "Chapter 6 of the Samba-3 Guide", is a bit long and not for the faint of heart. Luckily, someone has taken the time and effort to make a script for you.

Matt Oquist created the smbldap installer that works well with Ubuntu (tested by MarkChang on dapper). Following the instructions there gives you a working server and client.

Related links

• Turn your world LDAP-tastic
• Host-based authentication

Host-based Authentication

Host based authentication allows you to restrict who can log into a machine that uses LDAP for authentication. The basic gist is you add an attribute to each LDAP user's record that includes hostnames that they are allowed to log in to. Each client system then checks this field against its own hostname and either allows or denies login based upon the attribute field.

On the LDAP server, you need to add an attribute that will hold hostnames. If your schema allows, you can use the host attribute. To add that attribute, you can use a web tool such as phpldapadmin, or you can create a modification LDIF such as:

dn: uid=user_to_change,ou=Users,dc=example,dc=com
changetype: modify
add: host
host: thehostname

and make the change using:

ldapmodify -H ldap://localhost -D "cn=admin,dc=example,dc=com" -x -W -f your_file.ldif

On the client side, simply modify /etc/pam_ldap.conf to include these lines:

pam_check_host_attr yes
pam_filter |(host=client_hostname)(host=\*)

"client_hostname" should match the output from the hostname command. When in doubt, check the slapd logs on the server.

Links

• OpenLDAP website give you lot of informations
• LDAP HOWTO
• [1] Simple GUI to LDAP administration, available in repositories.

---