UbuntuHelp:OpenLDAPServer
来自Ubuntu中文
 |
点击翻译: |
English |
请不要直接编辑翻译本页，本页将定期与来源同步。 |
目录
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
Edit /etc/ldap/lapd.conf and add:
BASE dc=example,dc=com
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:
-
-xis because we do not use SASL authentication method (default) -
-LLLdisable 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 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.
2. Reconfigure the master server's slapd.conf to enable replication to the new slave server.
3. Export the database of the master server.
4. Configure the replica server's slapd.conf.
5. Import the database of the master server to the slaver server.
6. Re/Start the replica server's slapd process
7. 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
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.
Administration Tools
Links
- OpenLDAP website give you lot of informations
- LDAP HOWTO
- [1] Simple GUI to LDAP administration, available in repositories.
