Академический Документы
Профессиональный Документы
Культура Документы
com/developerworks/linux/library/l-openldap/
English
Technical topics
Evaluation software
Community
Events
Figure 1. Relationship between LDAP directory entry and Linux password file
The file /etc/openldap/schema/nis.schema defines all the attributes and the objectclass for an entry in the posixAccount object class. For
example, here is the uidNumber attribute description:
attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber'
DESC 'An integer uniquely identifying a user in an administrative domain'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
After all attribute types are defined, they are collected into the posixAccount objectclass. For example:
objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
DESC 'Abstraction of an account with POSIX attributes'
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
http://www.ibm.com/developerworks/linux/library/l-openldap/
The ldapuser entry has a distinguished name attribute, dn, which is used as a user name and which, along with the userPassword, is used to log
into, or bind, to the LDAP directory.
LDAP provides for special entries that act as containers to organize the entries into a tree structure. In the examples, you'll use a container,
for user account information and another container, Groups, for group account information. The resulting Directory Information Tree is
shown in Figure 2.
People,
Let's look at how to configure the OpenLDAP server, migrate information from the system files to the LDAP directory, and configure an
OpenLDAP client to authenticate users via LDAP. With a central authentication database, you should build in high availability by using
replication to have a second LDAP server that can respond to requests in the event of any problems reaching the server. As authentication data
such as passwords will be traveling over the network, you'll want to set up encrypted communications using the TSL protocol.
Our OpenLDAP servers and clients are Virtual Machines running Red Hat Enterprise Linux AS release 4 (Nahant Update 1). I used the systems
listed in Table 1 in my examples. Use values appropriate for your setup if you choose to duplicate these examples.
Host name
dhcp64-233.ibm.com
dhcp64-253.ibm.com
dhcp64-251.ibm.com
IP address
9.47.64.233
9.47.64.253
9.47.64.251
http://www.ibm.com/developerworks/linux/library/l-openldap/
The loglevel line sets logging options. Specify the level at which debugging statements and operation statistics should be logged to /var/log
/slapd.log. Log levels are additive: 296 = 256 log connections/operations/results + 32 search filter processing + 8 connection management:
loglevel 296
The information is logged to the syslogd LOG_LOCAL4 facility. Also add the following to /etc/syslog.conf and have syslogd reread its
configuration file:
local4.debug /var/log/slapd.log
The access line defines who has access to what in your directory. You want users to be able to change their passwords and update shadow
information reflecting the change. You want authentication routines to be able to retrieve users' passwords. You want users to be able to read all
of their other entries. Note that as the password entry is not readable, the only use of the shadow attributes is to manage password expiration.
access to attrs=shadowLastChange,userPassword
by self write
by * auth
access to *
by * read
Specify the DN suffix of queries that your backend will respond to. To ensure uniqueness, the root suffix should be built from your network's
domain name. In my case, this would be .dc=svc,dc=beaverton,dc=ibm,dc=com., but to save space I've abbreviated it in my example:
suffix "dc=ibm,dc=com"
Specify the administrative DN, which not subject to access control or restrictions for operations on this database. You need not have an entry in
your directory for the DN. Using the DN for the Manager with the rootpw password bypasses all access controls in the ACL rules:
rootdn "cn=Manager,dc=ibm,dc=com"
rootpw {MD5}ijFYNcSNctBYg
This concludes the options you'll want to set at this point. I'll return to the slapd.conf file later to configure replication and again to configure
security.
Now, you want to add data to your directory and verify that you can access the information. To do this, you configure the server to use the ldap
client tools such as ldapadd and ldapsearch. The configuration file for the ldap client tools is /etc/openldap/ldap.conf. The complete listing of the
file I used is shown in Listing 19 toward the end of this article. To run the tools from the ldap server, you need only change this line like so:
BASE dc=ibm,dc=com
Set the startup script to launch LDAP for run levels 2, 3, and 5:
http://www.ibm.com/developerworks/linux/library/l-openldap/
Starting slapd:
OK
The ldapsearch -x command, while not returning any data, should complete successfully.
Migrate the password and shadow information
The openldap-servers package provided by Red Hat includes MigrationTools from PADL Software Pty Ltd. You'll use them to migrate data from
the Linux system files such as /etc/group and /etc/password to the LDAP LDIF format, a representation of the database in a text format. The
format is line-delimited, colon-separated attribute-value pairs.
A collection of Perl scripts is installed in /usr/share/openldap/migration/ to perform the migration. The configuration information for these Perl
scripts is contained at the beginning of the include file migrate_common.ph. For your purposes, it is sufficient to modify the variable for the
naming suffix to use in entries' distinguished names, as follows:
$DEFAULT_BASE = "dc=ibm,dc=com"
After making this change, run the script migrate_base.pl, which creates the root entry and the next lower level organizational unit entries for
Hosts, Networks, Group, and People, among others:
Working from the LDAP server, insert the entries below into the database using the OpenLDAP client tool, ldapadd. Simple authentication must
be specified with the option -x. The Distinguished Name to authenticate, the rootdn specified in slapd.conf, is "cn=Manager,dc=ibm,dc=com".
For simple authentication, a password is required. The option -W forces a password prompt. This password is the value of the rootpw parameter
specified in the slapd.conf file. The LDIF file containing the entries is specified with the option -f:
http://www.ibm.com/developerworks/linux/library/l-openldap/
At this point, check the information that has been added to the database. Listing 9 shows the complete output:
extended LDIF
LDAPv3
base <> with scope sub
filter: (objectclass=*)
requesting: ALL
# ibm.com
dn: dc=ibm,dc=com
dc: ibm
objectClass: top
objectClass: domain
# People, ibm.com
dn: ou=People,dc=ibm,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit
# Group, ibm.com
dn: ou=Group,dc=ibm,dc=com
http://www.ibm.com/developerworks/linux/library/l-openldap/
ou: Group
objectClass: top
objectClass: organizationalUnit
# ldapuser, Group, ibm.com
dn: cn=ldapuser,ou=Group,dc=ibm,dc=com
objectClass: posixGroup
objectClass: top
cn: ldapuser
gidNumber: 500
# ldapuser, People, ibm.com
dn: uid=ldapuser,ou=People,dc=ibm,dc=com
uid: ldapuser
cn: ldapuser
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/ldapuser
gecos: test2
# search result
search: 2
result: 0 Success
# numResponses: 6
# numEntries: 5
http://www.ibm.com/developerworks/linux/library/l-openldap/
Enter your corresponding information as shown on the second screen displayed in Figure 4, and click OK.
The principal configuration file used by the PAM and NSS modules is /etc/ldap.conf. The host option specifies the LDAP server, the base option
specifies the DN for the directory and, initially, you want encryption turned off:
host dhcp64-233.ibm.com
base dc=ibm,dc=com
ssl off
http://www.ibm.com/developerworks/linux/library/l-openldap/
To have the NSS service consult the OpenLDAP server, add "ldap" to the passwd, shadow, and group lines in the /etc/nsswitch.conf lines, as
shown:
passwd: files ldap
shadow: files ldap
group: files ldap
To have the PAM authentication service consult the OpenLDAP server, add the pam_ldap lines to /etc/pam.d/system-auth after the
corresponding standard pam_unix.so entries. Although other variations lead to the same results, this is the file I used:
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so broken_shadow
account sufficient /lib/security/$ISA/pam_localuser.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid %lt; 100 quiet
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session optional /lib/security/$ISA/pam_ldap.so
At this point, the user account information can be removed from the client system and be obtained from the LDAP directory. When the user
attempts to log into the client system, the PAM authentication service gets the username, in our example ldapuser, from the user. PAM retrieves
the distinguished name (DN) entry, .dn: uid=ldapuser, ou=People, dc=ibm, dc=com. from the LDAP server. PAM next gets the password
from the user. PAM attempts to bind to the LDAP server using the DN and password. The DN and password are sent to the LDAP server in plain
text. If, after hashing the password, the server can log the user in, a successful bind is reported back to PAM. The successful bind fulfills the
PAM criteria for the pam_ldap module to report success, and if all other PAM criteria are met, the user is allowed to log in.
With authentication being handled by the LDAP server, you have two more issues to resolve to meet your goal of providing reliable and secure
authentication. At this point, any inability of your client systems to communicate with the LDAP server will prevent users from logging into the
client systems. You'll see how to remove this single point of failure in the next section, which shows how clients can access the LDAP directory
from backup servers. With users' passwords traveling over the network in plain text, you do not meet the requirement for secure authentication.
The section Configure TLS security addresses this.
Configure replication
To prevent problems with users' ability to log on to a client should the LDAP server experience any problems, you employ replication to achieve
your reliability goal. Replication is provided by the OpenLDAP replication daemon, slurpd, which periodically wakes up and checks a log file
on the master for any updates. The updates are then propagated to the slave servers. Read requests can be resolved by either server, whereas
updates can be performed only on the master. Update requests to a slave generate a referral message that gives the address of the master server.
It is the client's responsibility to retry the update at the referral address.
To configure replication, stop the OpenLDAP server's slapd daemon:
Add the following to the server's /etc/openldap/slapd.conf to enable replication to the new slave server. The replogfile line specifies the file
where the LDIF-like change will be written. The replica directive defines the host to which the change should be propagated:
#Replicas of this database
replogfile /var/lib/ldap/replog
http://www.ibm.com/developerworks/linux/library/l-openldap/
replica host=dhcp64-253.ibm.com:389
binddn="cn=Manager,dc=ibm,dc=com"
credentials=secret
bindmethod=simple
On the system that will run the slave OpenLDAP server, follow the steps given above in Configure the LDAP server. Then, copy the database
from the master server to the replica by exporting the information to an ldif file and adding it to the slave server database.
On the master server:
Add the following to the replica server's /etc/openldap/slapd.conf file. updatedn specifies the DN that the master slurpd daemon will use when
updating the slave directory. updateref points to the master directory server. When an LDAP client is asking the slave to update, the slave
points the client to this master server.
updatedn "cn=Manager,dc=ibm,dc=com"
updateref ldap://dhcp64-233.ibm.com:389/
Start the replica OpenLDAP server and, once it is running, start the master OpenLDAP server. On the master, both slapd and slurpd will start.
At this time, you can let the OpenLDAP client use the replica server in addition to the master server by either running authconfig and adding the
replica host name to the Server line on the second screen, or by changing the host attribute in /etc/ldap.conf to this:
host dhcp64-253.ibm.com dhcp64-233.ibm.com
To verify that replication is working correctly, observe what happens when the gecos attribute is updated. The replication log uses a format
similar to the LDIF. After reading the replogfile, slurpd copies the entry to its own replay log. The actual changes, in LDIF format, are located at
/var/lib/ldap/replica/ on the master LDAP server in a file called slurpd.replog.
With the change in the file user_mod, the client routine ldapmodify is used to apply the change:
http://www.ibm.com/developerworks/linux/library/l-openldap/
replace: modifyTimestamp
modifyTimestamp: 20051023235446Z
-
Next, generate the server certificate that will be signed by the Certificate Authority. The remaining steps are done once for the master LDAP
server, specifying CN=dhcp64-233.ibm.com, and then for the slave server, specifying CN=dhcp64-253.ibm.com. The nodes option is used so that
http://www.ibm.com/developerworks/linux/library/l-openldap/
the certificate will not need a pass phrase every time the OpenLDAP server daemon, slapd, is started. The signed public key is embedded in
certificate request slapd-req.pem; the private key that matches it is in slapd-key.pem:
Sign the certificate using the CA certificate you created in the first step:
The next step copies over all the required certificates to where slapd can find them. In addition, the correct permissions are enforced on each
file:
cp -p
cp -p
chown
chmod
chown
chmod
slapd-key.pem /etc/openldap/slapdkey.pem
slapd-cert.pem /etc/openldap/slapdcert.pem
ldap:ldap /etc/openldap/slapdcert.pem
644 /etc/openldap/slapdcert.pem
ldap:ldap /etc/openldap/slapdkey.pem
400 /etc/openldap/slapdkey.pem
#
#
#
#
mkdir /etc/openldap/cacerts/
cp /usr/share/ssl/misc/demoCA/cacert.pem /etc/openldap/cacerts/cacert.pem
chown ldap:ldap /etc/openldap/cacerts/cacert.pem
chmod 644 /etc/openldap/cacerts/cacert.pem
http://www.ibm.com/developerworks/linux/library/l-openldap/
On the OpenLDAP server, add the lines below to the global section of the /etc/openldap/slapd.conf file. The TLSCertificateFile and
TLSCertificateKeyFile specify the paths to the certificate file and private-key file. TLSCipherSuite specifies a list of OpenSSL ciphers from
which slapd will choose when negotiating TLS connections, in decreasing order of preference. HIGH means "all ciphers using key lengths greater
than 128 bits"; MEDIUM is short for "all ciphers using key lengths equal to 128 bits"; and +SSLv2 means "all ciphers specified in the SSL protocol,
Version 2, regardless of key strength."
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
TLSCertificateFile /etc/openldap/slapdcert.pem
TLSCertificateKeyFile /etc/openldap/slapdkey.pem
Add the following lines to the secondary configuration file for the LDAP server, /etc/openldap/ldap.conf:
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
To allow secure connections from the OpenLDAP client, add the following to the /etc/openldap/ldap.conf file:
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/openldap/cacerts/cacert.pem
Conclusion
By following these instructions, you have now built a centralized authentication system using the Lightweight Directory Access Protocol
(LDAP). You started by configuring the LDAP server to respond to queries with base "dc=ibm,dc=com". You used a set of Perl scripts to
migrate user account information into the LDAP directory. You modified the Linux user account services, PAM and NSS, to retrieve user
information from the LDAP server. You set up a replica of the LDAP server to respond as a backup server. Then, you used the TLS protocol to
securely encrypt communications between the LDAP client and server. Congratulations!
For reference, below are the complete listings of the configuration files used in this article.
256
/var/run/slapd.pid
/var/run/slapd.args
# The next three lines allow use of TLS for encrypting connections.
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile
/etc/openldap/cacerts/cacert.pem
TLSCertificateFile
/etc/openldap/slapdcert.pem
TLSCertificateKeyFile
/etc/openldap/slapdkey.pem
# access control policy:
# Restrict password access to change by owner and authentication.
# Allow read access by everyone to all other attributes.
access to attrs=shadowLastChange,userPassword
by self write
by * auth
access to *
by * read
#######################################################################
# database definition
#######################################################################
database
suffix
bdb
"dc=ibm,dc=com"
rootdn
rootpw
"cn=Manager,dc=ibm,dc=com"
{MD5}ijFYNcSNctBYg
http://www.ibm.com/developerworks/linux/library/l-openldap/
directory
/var/lib/ldap
eq,pres
eq,pres,sub
eq,pres
eq,pres,sub
eq,pres,sub
Resources
Learn
The OpenLDAP home page is the home of the OpenLDAP Project. It contains a wealth of information about configuring OpenLDAP as
well as a future roadmap and versions. Be sure to read the OpenLDAP Software 2.3 Administrator's Guide.
http://www.ibm.com/developerworks/linux/library/l-openldap/
Discuss
The OpenLDAP mailing lists are the primary forums for OpenLDAP discussions.
Check out developerWorks blogs and get involved in the developerWorks community.
Mike O'Reilly is a member of the Linux and VMware ESX product support teams within IBM and has been supporting the Linux product for the
better part of five years. In addition, he has been supporting VMware for more than two years and UNIX for more than ten.
Close [x]
IBM ID:
Need an IBM ID?
Forgot your IBM ID?
Password:
Forgot your password?
Change your password
Keep me signed in.
By clicking Submit, you agree to the developerWorks terms of use.
The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to
the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will
accompany the content that you post.
All information submitted is secure.
Close [x]
http://www.ibm.com/developerworks/linux/library/l-openldap/
The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name
accompanies the content you post on developerWorks.
Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not
be your email address for privacy reasons.
Display name:
1 star
2 stars
2 stars
3 stars
3 stars
4 stars
4 stars
5 stars
5 stars
Add comment:
Sign in or register to leave a comment.
Note: HTML elements are not supported within comments.
http://www.ibm.com/developerworks/linux/library/l-openldap/
Report abuse
1. cat passwd.ldif
dn: uid=ldapuser,ou=People,dc=ibm,dc=com
uid: ldapuser
cn: ldapuser
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt$1$TeOlOcMc$cpQaa0WpLSFRC1HIHW5bt1
......
After load the ldif files to LDAP, then make linux OS using LDAP as user authentication, but the user cannot logon with its original local
password, which is filled into LDAP with "{crypt$1$TeOlOcMc$cpQaa0WpLSFRC1HIHW5bt1"
Posted by sbjerry on 16 March 2011
Report abuse
Excellent article on openLDAP for beginners.
Posted by Meghanand on 26 May 2010
Report abuse
Print this page
Follow developerWorks
About
Report abuse
Faculty
Help
Newsletters
Terms of use
Students
Contact us
IBM privacy
Business Partners
Submit content
IBM accessibility