These classnotes are depreciated. As of 2005, I no longer teach the classes. Notes will remain online for legacy purposes

LDAP01/Integration With MUAs

Classnotes | LDAP01 | RecentChanges | Preferences

User Representation

We've covered a variety of ways to respresent users thus far in this class. We've seen in our LDIF overview how you can create a contact directory for your organization and introduced directroy design. We showed how to represent UNIX users in a directory, which is fundimental for an OpenLDAP server to replace or augment NIS, SSH, FTP, etc.

However, we have not touched upon one problem which needs to now be addressed. Let's take a look at an entry similar to one we have in our directory:

 dn: cn=Frank Poole,ou=people,dc=odyssey,dc=com
 objectClass: inetOrgPerson
 cn: Frank Poole
 sn: Poole
 mail: frank@odyssey.com
 roomNumber: 420Q
 telephoneNumber: 358-1121

In our /Schemas For Information Services section, a user's entry with respect to IS may be:

 dn: uid=frank,ou=people,dc=odyssey,dc=com
 uid: frank
 cn: Frank Poole
 objectClass: account
 objectClass: posixAccount
 userPassword: {crypt}HS.99hjhs
 loginShell: /bin/sh
 uidNumber: 781
 gidNumber: 100
 homeDirectory: /home/frank
 gecos: Frank Poole

Looking at both examples side by side, some differences can be noted. The first is that the RDN used for each entry is different.

The second issue is more serious and shows why the initial directory design should not be rushed. Both the account and inetOrgPerson object classes are structural object classes (see /LDIF Attributes from the first day).

Remeber that you cannot have more than one structural object class and that once an entry is created, its structural class cannot be changed (okay, some LDAP servers do allow this, but do not rely on this behavior).

To solve this problem, initially create each entry with the inetOrgPerson class and then extend it using the posixAccount auxiliary class. This means that the account entry will have to be filtered from the output of PADL's migration scripts. The following grep will accomplish this:

 # ./migrate_passwd.pl /etc/passwd | \
  grep -iv "objectClass: account" > passwd.ldif

This will produce an LDIF ready for merger with our existing directory. This merger is fairly simple to do, but it is left as an excersize for the student (recall the section: /Searching And Modifying).

One final note before we leave this discussion, pay special attention to those feilds that are required in each object class. Here, we note that inetOrgPerson lists the attribute "mail" as optional, but that same attribute is required by posixAccount.

Email Clients and LDAP

We really aren't going to spend much time on Email client integration with LDAP. We will touch upon the basics, and spend some time talking about the default searches, but that will be it.

Firstly, it is important to note that some Email clients will only bind to LDAPv2 connections. So, for these clients you may wish to enable in your slapd.conf file:

 allow bind_v2

while this can cause troubles elsewhere, so enable this setting with caution.

Table 7-1 on page 128 of the book shows that Outlook Express was the only MUA capable of performing LDAPv3 binds when the book was written. This is no longer necessarily true for all of these clients.

For one, Mozilla (http://www.mozilla.org/) now supports it (it actually supports it in its SDKs, so Mozilla or Gecko-based apps will also support it). While the Mozilla LDAP C SDK supports LDAPv3, it "speaks" LDAPv2 by default. This means that the application developers have to enable it for it to be used.

For another, Outlook and Outlook Express do not actually support industry standard LDAPv3 authentication. But we will get to that shortly.

Mozilla Mail

Mozilla Mail, http://www.mozilla.org/mailnews/ (and the new Mozilla Thunderbird, http://www.mozilla.org/projects/thunderbird/) do support LDAPv3 binds and can search LDAP directories. Mozilla allows for a full gambit of LDAP authentication including simple binds, user authentication, and SSL (LDAPS).

Mozilla's search facilities query the cn, sn, givenName, and mail attributes for matches. For example, if you enter the text "sam" for the search, Mozilla uses this search filter:

 (|(mail=*sam*)(cn=*sam*)(givenName=*sam*)(sn=*sam))

Mozilla also provides an "Advanced Search" which allows additional attributes to be scanned and a more fine control of search results.

Pine

At the time of this writing, Pine does not support LDAPv3. It also does not support any encryption or security LDAP connection whatsoever.

When searching, Pine uses the cn, sn, givenName, and mail attributes just like Mozilla, however it only searches for attribute values starting with the search value.For our example above, the resultant filter is very similar to Mozilla:

 (|(cn=sam*)(mail=sam*)(sn=sam*)(givenName=sam*))

Eudora

Eudora's most interesting feature it has over the other MUAs listed here is that it has a rather rich editing tool for adding new entries in the directory. Naturally, this sort of behavior may not be desirable if you are integrating contact information with connection and authentication information.

Outlook and Outlook Express

Outlook and Outlook Express support LDAPv3 binds, and use a search that is nearly identical to Pine:
 (|(mail=sam*)(cn=sam*)(sn=sam*)(givenname=sam*))

Like Mozilla and Eudora, Outlook can perform authenticated binds when searching a directory. If you check "This server requires me to logon", Outlook asks for a user ID and password, which it uses when binding to the server. Outlook expects the logine name to be the DN used in the bind request. However, if the "Logon using Secure Password Authentication" box is checked, Outlook attempts to negotiate with the directory using something known as "NTLMv1". OpenLDAP does not presently support this not-quite standard feature, and Outlook will not be able to bind successfully if it is enabled.



Classnotes | LDAP01 | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited September 29, 2003 9:31 pm (diff)
Search:
(C) Copyright 2003 Samuel Hart
Creative Commons License
This work is licensed under a Creative Commons License.