In this section you will find information about the Netscape Address Book, a LDAP client that can be used to query your Directory. Also presented are details on how to implement Roaming Access using the Netscape Navigator, version 4.5 or above and your LDAP server. There has been a lot of talk on the OpenLDAP mailing lists about Roaming Access, since this is a feature that is not totally implemented. Most of the people don't like the way Netscape Navigator operates with the LDAP server while making downloads and uploads to it. So, if after reading this you find that the Roaming Access is not working the way you would like, nevermind. A lot of people passed through this situation already. The purpose of introducing this feature here is more for giving people an idea about the capabilities of the LDAP protocol. To finish you will see some information about safely killing the slapd process and about slapd logs.
The goal of Roaming Access is that wherever you are on the Net, you can retrieve your bookmarks, preferences, mail filters, etc. using Netscape Navigator and a LDAP server. This is a very nice feature. Imagine that wherever you access the Web, you can have your own settings on the browser. If you will travel and you need to access that currency site that is stored on your local bookmarks, don't worry. Upload the bookmarks and other configuration files to a LDAP server and you can retrieve them all later, independent of the place you will be.
To implement Roaming Access you have to follow these steps:
- Changing the attributes file: You need to add new attributes on the attribute list present on the file slapd.at.conf (this is a file you include on your slapd.conf and it's normally located at /usr/local/etc/openldap):
attribute nsLIPtrURL ces
attribute nsLIPrefs ces
attribute nsLIProfileName cis
attribute nsLIData bin
attribute nsLIElementType cis
attribute nsLIServerType cis
attribute nsLIVersion cis
- Changing the objectclass file: You also have to add some new classes to your slapd.oc.conf (this is another file you include on your slapd.conf and it's normally located at /usr/local/etc/openldap) in order to enable Roaming Access:
objectclass nsLIPtr
requires
objectclass
allows
nsliptrurl,
owner
objectclass nsLIProfile
requires
objectclass,
nsliprofilename
allows
nsliprefs,
uid,
owner
objectclass nsLIProfileElement
requires
objectclass,
nslielementtype
allows
owner,
nslidata,
nsliversion
objectclass nsLIServer
requires
objectclass,
serverhostname
allows
description,
cn,
nsserverport,
nsliservertype,
serverroot
- Changing the LDIF file: Now you have to modify your LDIF file, adding profiles entries to each user that wish to try the Roaming Access feature of Netscape. Look an example of a simple LDIF file with profiles entries:
dn: o=myOrg,c=NL
o: myOrg
objectclass: organization
dn: cn=seallers,ou=People,o=myOrg,c=NL
cn: seallers
userpassword: myPassword
objectclass: top
objectclass: person
dn: nsLIProfileName=seallers,ou=Roaming,o=myOrg,c=NL
changetype: add
objectclass: top
owner: cn=seallers,ou=People,o=myOrg,c=NL
objectclass: top
objectclass: nsLIProfile
- Go to Menu Edit -> Preferences -> Roaming User
Now you have to first enable Roaming Access for this profile, clicking on the checkbox corresponding to this option.
- Fill the username box with an appropriate value, for instance john
Pull down the arrow of the Roaming User option on the left side of the Preferences Window to see the suboptions of Roaming Access.
- Click on Server Information and enable the option LDAP Server and fill the boxes with the following information:
Address: ldap://myHost/nsLIProfileName=$USERID,ou=Roaming,o=myOrg,c=NL
User DN: cn=$USERID,ou=People,o=myOrg,c=NL
IMPORTANT: Netscape automatically substitutes the $USERID variable for the name of the profile you selected before running the browser. So if you selected the profile seallers, it will substitute $USERID for seallers, if you selected profile gonzales, it will substitute $USERID for gonzales. If you are not familiar with profiles, run the Profile Manager application that comes on the Netscape Comunicator package. It's an application designed to satisfy the multiple users of a browser on the same machine, so each one can have their own settings on the browser.
The final step is to restart the server. Take a look on the section 4.2 to see how you do that safely and on section 4 to see how to start it again.
Once you have your LDAP server up and running, you can access it with many different clients (e.g. ldapsearch command line utility). A very interesting one is the Netscape Address Book. It's available from version 4.x of Netscape but you have to use the 4.5 or above version for a stable interoperation with your LDAP server.
Just follow the sequence:
Open Netscape Navigator -> Go to Communicator Menu -> Address Book
The Netscape Address Book will be launched with some default LDAP directories. You have to add your own LDAP directory too!
Go to File Menu -> New Directory
Fill the boxes with your server information. For example:
- Description: TUDelft
- LDAP Server: dutedin.et.tudelft.nl
- Server Root: o=TUDelft, c=NL
The default LDAP port is 389. Don't change it, unless you changed this option while building your server.
Now, make simple queries to your server, using the box Show Names Containing, or advanced queries, using the Search for button.
The LDAP Migration Tools are a collection of Perl scripts used to convert configuration files to the LDIF format. The scripts are provided by PADL Software Ltd. I recommend you to take a look at the license terms before using them, even being free. If you plan to use your LDAP server to authenticate users, this tools may be very useful. Use the Migration Tools to convert your NIS or password archives to the LDIF format, making these files compatible with your LDAP Server. Apply also these Perl Scripts to migrate users, groups, aliases, hosts, netgroups, networks, protocols, RPCs and services from existing nameservices (NIS, flat files and NetInfo) to the LDIF format. To download the LDAP Migration Tools and get more information, go to the following address:
http://www.padl.com/tools.html
The package comes with a README file and the name of the script files are intuitive. Take a first look on the README file and then start applying the scripts.
Your LDAP server can authenticate users using a mechanism called PAM (Pluggable Authentication Modules). Since the beginnings of UNIX, authenticating a user has been accomplished via the user entering a password and the system checking if the entered password corresponds to the encrypted official password that is stored in /etc/passwd.
That was in the beginning. Since then, a number of new ways for authenticating users became popular, including more complicated replacements for the /etc/passwd file and hardware devices called Smart cards. The problem is that each time a new authentication schema is developed, it requires all the necessary programs (login, ftpd etc...) to be rewritten to support it. PAM provides a way to develop programs that are independent of authentication scheme. These programs need "authentication modules" to be attatched to them at run-time in order to work.
The authentication module for LDAP is available as a tar ball on the following address:
http://www.padl.com/pam_ldap.html
Here I assume that your Linux distribution is already PAM prepared. If not take a look at this URL:
http://www.kernel.org/pub/linux/libs/pam. Various Linux distributions use different standard settings related to PAM. Usually, the PAM configuration files reside on the /etc/pam.d/ directory. There you can find a file for each service running on your box. As an example, if you want to use the LDAP server for logging users in after your Linux boot up, you should make your Linux PAM compatible (as described in the beginning of this paragraph), install the LDAP PAM module and edit a file called login in the PAM configuration directory (/etc/pam.d/) with the following content:
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_unix_auth.so try_first_pass
account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix_acct.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_ldap.so
password required /lib/security/pam_pwdb.so use_first_pass
session required /lib/security/pam_unix_session.so
Kldap is a graphical LDAP client written for KDE. Kldap has a nice interface and is able to show all the information tree stored on your Directory. You can check some screenshots from the application and download it at:
http://www.mountpoint.ch/oliver/kldap
GQ is another graphical LDAP client with a simpler interface. It was written for GNOME. It also runs under KDE, the same way Kldap runs under GNOME. The address for downloading and getting more information is:
http://biot.com/gq/
Slapd uses the syslog(8) facility to generate logs. The default user of the syslog(8) facility is LOCAL4, but values from LOCAL0, LOCAL1, up to LOCAL7 are allowed.
In order to enable the generation of logs you have to edit your syslog.conf file, usually located in the /etc directory.
Create a line like this:
local4.* /usr/adm/ldalog
This will use the default user LOCAL4 for the syslog facility. If you are not familiar with the sintax of this line, take a look at the man pages of syslog, syslog.conf and syslogd. If you want to change the default user or to specify the level of the logs generated, you have the following options while starting slapd:
-s syslog-level This option tells slapd at what level debugging statements should be logged to the syslog(8) facility. The level describes the severity of the message, and is a keyword from the following ordered list (higher to lower): emerg, alert, crit, err, warning, notice, info, and debug. Ex: slapd -f myslapd.conf -s debug
-l syslog-local-user Selects the local user of the syslog(8) facility. Values can be LOCAL0, LOCAL1, and so on, up to LOCAL7. The default is LOCAL4. However, this option is only permitted on systems that support local users with the syslog(8) facility.
Now take a look at the logs generated. They can help you tremendously in solving problems with queries, updates, binding, etc.