3.16 OpenLDAP implementation

 < 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 

Tip

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:

 #saslpasswd dummyuser 

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

graphics/03fig15.jpg

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:

  • /etc/security/pam_unix2.conf

     .... auth: use_ldap nullok account: use_ldap password: use_ldap nullok ... 
  • /etc/openldap/ldap.conf

     ... base    ou=user,dc=residency,dc=local host    192.168.100.81 ldap_version    3 ... 
  • /etc/nssswitch.conf

     ... passwd: files ldap group: files ldap shadow: files ldap ... 

Tip

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

graphics/03fig16.jpg

Another example is "LDAP Browser/Editor" written in Java by Jarek Gawor. You can download it from:

http://www.iit.edu/~gawojar/ldap/

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

graphics/03fig17.jpg

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:

  1. Generate a CA.

    If we do not have a certificate signed by an official certificate authority, we need to generate it. First we use a tool to generate a new certificate authority CA, so we can sign our own certificates:

     # /usr/share/ssl/misc/CA.sh newca 

    This tool generates the Certificate for our CA (demoCA/cacert.pem)and the private key (demoCA/private/cakey.pem).

  2. Generate a server certificate.

    Now we generate the server certificate:

     # openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem 
  3. Sign the server certificate.

    In order to sign our server certificate, we issue:

     # /usr/share/ssl/misc/CA.sh -sign 
  4. Copy certificates to LDAP.

    Now we need to copy certificates to /etc/openldap/cert directory and chown them to the Idap user.

     lpar7:~ # mkdir /etc/openldap/cert lpar7:~ # cp demoCA/cacert.pem /etc/openldap/cert/ lpar7:~ # cp demoCA/cacert.pem /etc/openldap/cert/cacert.pem lpar7:~ # cp newcert.pem /etc/openldap/cert/servercrt.pem lpar7:~ # cp newreq.pem /etc/openldap/cert/serverkey.pem lpar7:~ # chown -R ldap:ldap /etc/openldap/cert 
  5. Add the keys to slapd.conf.

    We add these lines to /etc/openldap/slapd.conf in order to utilize the created certificates:

     TLSCertificateFile    /etc/openldap/certificates/servercrt.pem TLSCertificateKeyFile /etc/openldap/certificates/serverkey.pem TLSCACertificateFile  /etc/openldap/certificates/cacert.pem 
  6. Start the server.

     # /usr/lib/openldap/slapd -d9 -f /etc/openldap/slapd.conf -h ldaps://192.168.100.83:636 -u ldap -g ldap 
  7. Configure the client.

    To configure the client, we need to change ldap.conf to use secure communication; see Example 3-37.

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 > 


Quintero - Deploying Linux on IBM E-Server Pseries Clusters
Quintero - Deploying Linux on IBM E-Server Pseries Clusters
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 108

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net