|< Day Day Up >|
The OpenLDAP-Server and client package is included in the standard SuSE SLES installation on pSeries. Here we describe a simple LDAP configuration for user authentication in a networked environment. The benefits of using LDAP are centralized and simplified user management from anywhere in the network, hierarchical structure, and replication for availability.
In this section, we explain how to set up an LDAP server on SuSE and how to use it for common user authentication tasks. Once you have LDAP running in your network, it can be used for many different tasks : addressbook , hostname repository, assessment management, and so on.
3.16.1 Setting up an LDAP server
Setting up the LDAP server consists of two steps: configuring the server, and defining the users.
LDAP server configuration
The server configuration is managed by one file, /etc/openldap/slapd.conf.
We verify the openldap server package is installed:
p630sles:~ # rpm -qa grep openldap openldap2-client-2.1.4-43 openldap2-2.1.4-48
Next , we edit /etc/openldap/slapd.conf.
Example 3-4 on page 108 contains a very basic but working template for slapd.conf.
Example 3-34. /etc/openldap/slapd.conf
# First we describe schemata to be included include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema allow bind_v2 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # We define acls here: with default acs authentication will work, # but users will not be able to change their passwords access to attr=userPassword by dn="cn=admin,dc=residency,dc=local" write by self write by anonymous read by * auth access to * by dn="cn=admin,dc=residency,dc=local" write by anonymous read by self read database bdb suffix "dc=residency,dc=local" rootdn "cn=admin,dc=residency,dc=local" rootpw abc123 directory /var/lib/ldap # Indices to maintain index objectClass eq
Starting the LDAP server
Change the lines with keywords suffix, rootdn, and rootpw to your needs. If you comment out all ACL settings, the authentication will still work, but users will not be able to change their own passwords. This example LDAP configuration is not a secure one. In a production, we strongly recommend using TSL.
W we start the server:
# /etc/init.d/ldap start
(or by using the SuSE shortcut: rcldap start )
Look for error messages:
# tail -f /var/log/messages
You may see messages like: unable to open Berkeley db /etc/sasldb: No such file or directory . Do not be concerned ; you can avoid this by creating the /etc/sasldb database by issuing:
Now you have a file, /etc/sasldb, and you need to make it readable by the LDAP user:
# chmod o+r /etc/sasldb
Check the server status after a few minutes:
# /etc/init.d/ldap status
3.16.2 LDAP client configuration
Now we can set up the server to be an LDAP client of itself. We can use YaST, as follows :
Starting YaST2 with a shortpath:
# yast2 ldap
Figure 3-15. Using YaST to configure the LDAP client
Since our users are in the LDAP container dc=residency, dc=local, make it a base DN. The server address this case is: 192.168.100.110.
After pressing Finish, our LDAP client is ready for use.
YaST made changes in three files:
After changing these files, YaST calls the /sbin/SuSEconfig command. If you are going to distribute the files over manually, run this command afterwards.
You also need to run /sbin/SuSEconfig every time you change settings in the /etc/sysconfig directory.
3.16.3 Defining users in the LDAP directory
LDAP can import and export the contents of the database through ldif-files. In the next step, we create a user.ldif file and import the data into the LDAP directory.
This first ldif file contains the definition of the container (user) and one user; see Example 3-35 on page 156.
Example 3-35. /root/user.ldif file
dn: dc=residency,dc=local objectClass: organization o: residency dn: ou=user, dc=residency,dc=local ou: user objectClass: organizationalUnit dn: uid=lee,ou=user, dc=residency,dc=local sn: lee loginShell: /bin/bash userPassword: abc123 gidNumber: 100 uidNumber: 1203 shadowMax: 99999 objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: top uid: lee shadowLastChange: 11472 cn: lee homeDirectory: /tmp shadowWarning: 7
After we create the file, we import it to LDAP:
# ldapadd -c -x -D "cn=admin,dc=residency,dc=local" -W -x -f /root/user.ldif
The following output should be received:
Enter LDAP Password: adding new entry "dc=residency,dc=local" adding new entry "ou=user, dc=residency,dc=local" adding new entry "uid=lee,ou=user, dc=residency,dc=local"
Now we can search LDAP for entries we added; see Example 3-36:
Example 3-36. searching LDAP entries
# ldapsearch -x # extended LDIF # # LDAPv3 # filter: (objectclass=*) # requesting: ALL # # user, residency.local dn: ou=user,dc=residency,dc=local ou: user objectClass: organizationalUnit # prabs, user, residency.local dn: uid=prabs,ou=user,dc=residency,dc=local uid:: cHJhYnMg cn: prabs sn:: cHJhYnMg objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: top userPassword:: YWJjMTIz shadowLastChange: 11472 shadowMax: 99999 shadowWarning: 7 uidNumber: 1200 gidNumber: 100 homeDirectory: /tmp loginShell: /bin/bash
We can also try ssh with a new, added LDAP user:
# ssh lee@localhost
3.16.4 Managing users
There are various LDAP clients or browsers that can help you to understand the directory structure or fulfill administration tasks. One of them, which is available in the default SLES8 installation, is gq; see Figure 3-16 on page 159.
Figure 3-16. gq LDAP client
Another example is "LDAP Browser/Editor" written in Java by Jarek Gawor. You can download it from:
This browser works on Windows and Linux systems, and can be used to manage LDAP users; see Figure 3-17 on page 160.
Figure 3-17. LDAP browser/editor in Java
3.16.5 Using SSL/TLS with OpenLDAP
LDAP supports encryption and authentication using Transport Layer Security (TLS). LDAP passwords in our previously described setup will be sent in clear text over the network if the LDAP server is not a local machine. This is generally not a good idea. In order to secure LDAP traffic, we can use TLS as follows:
Example 3-37. /etc/openldap/ldap.conf
base dc=residency,dc=local uri ldaps://192.168.100.83:636 host 192.168.100.83 SASL_SECPROPS noactive #ssl start_tls TLS hard TLS_REQCERT allow
|< Day Day Up >|