Category Archives: Directory/LDAP

Sun pam_ldap/pam_unix and correct subtree LDAP searches

Though addressed in the context JES Messaging this post is really about getting Sun’s pam_ldap or pam_unix to do what some might consider correct subtree searches. Read on:

If you’re using JES messaging with hosted domains you have an ldap tree that looks like this:,o=isp;,o=isp; etc.

so your user DNs look like this: uid=morgan,ou=people,o=firstdomain,o=isp; uid=matt,ou=people,o=seconddomain,o=isp; etc.

Under normal circumstances you would supply a basedn of “o=isp,” a scope of “sub,” and the application would search all of your hosted domains in search of the username.

Sun’s pam_ldap (and I believe pam_unix) prepend “ou=people” before doing a search. So if you specify “o=isp,” pam_ldap will search within “ou=people, o=isp” which either doesn’t exist or is empty.

After searching for a way to specify multiple base dns in the ldap profile (defaultSearchBase is SINGLE-VALUE in objectclass DUAConfigProfile) it turns out there is a straightforward work-around. From the ldapclient(1) man page:

           Override the default base DN for LDAP searches  for  a
           given  service.  The  format  of  the descriptors also
           allow overriding the default search scope  and  search
           filter  for  each  service. The syntax of serviceSear-
           chDescriptor is defined in  the  profile  IETF  draft.
           The  default value for all services is NULL. This is a
           multivalued attribute. In the example,


           the LDAP  client  would  do  a  one  level  search  in
           ou=people,dc=a1,dc=acme,dc=com       rather       than
           ou=people,defaultSearchBase for the passwd service.

So set serviceSearchDescriptor=passwd:o=isp and it will search under o=isp, allowing users in all of your hosted domains to authenticate. Of course this does open you up to problems where uids can conflict.

Zimbra LDAP Debugging

Multi-node Zimbra installs sometimes fail in mysterious ways.. We recently resolved what turned out to be a network problem but it was causing our Zimbra install to fail with what I originally suspected was an LDAP problem. I think the troubleshooting process may prove useful. This is Zimbra 5.0.4:

If a store doesn’t appear to be communicating with its ldap master, here’s how a I debugged it

On the ldap master:

# vi /etc/syslog.conf
    local4.debug          -/var/log/zimbra.log
# /sbin/service syslog reload
Reloading syslogd...                                       [  OK  ]
Reloading klogd...                                         [  OK  ]
# su - zimbra
$ zmlocalconfig -e ldap_log_level=800
$ zmcontrol stop && zmcontrol start

Now tail -f /var/log/zimbra.log for slapd logging

Now from the store:

yum install openldap-clients (RHEL5) or
up2date openldap-clients (RHEL4) if ldapsearch isn’t installed

$ ldapsearch -h zldap.morganjones.internal -W -x -LL -D cn=config
-b cn=zimbra objectclass=*
Enter LDAP Password:
version: 1 

dn: cn=zimbra
objectClass: organizationalRole
description: Zimbra Systems Application Data
cn: zimbra 

dn: cn=admins,cn=zimbra
objectClass: organizationalRole
description: admin accounts
cn: admins 


dn: cn=com_zimbra_convertd,cn=zimlets,cn=zimbra
zimbraZimletDescription: Convertd Extension for Admin UI
zimbraZimletVersion: 1.0
objectClass: zimbraZimletEntry
zimbraZimletIndexingEnabled: TRUE
zimbraZimletKeyword: com_zimbra_convertd
cn: com_zimbra_convertd
zimbraZimletIsExtension: TRUE
zimbraZimletPriority: 12
zimbraZimletEnabled: TRUE

side note: Zimbra users TLS for connections before stores and ldap servers. ‘-LL’ forces ldapsearch to use TLS, -x turns off ldaps.

Here’s the background that started me down this path:

Install ldap master with at least zimbra-ldap

Install a store, answer ‘n’ to zimbra-ldap and ‘y’ to zimbra-store. At the Main menu choose ‘1’ for Common Configuration.

Set Ldap master host and Ldap Admin password and when I typed ‘r’ it hung just like this:

Common configuration

   1) Hostname:                                store01.morganjones.internal
   2) Ldap master host:                      zldap.morganjones.internal
   3) Ldap port:                                389
   4) Ldap Admin password:                 set
   5) LDAP Base DN:                           cn=zimbra
   6) Require secure interprocess communications: yes
   7) TimeZone:
             (GMT-05.00) Easten Time (US & Canada)

Select, or 'r' for previous menu [r] r

A quick look at /tmp/zmsetup* revealed:

Couldn't bind to zldap.morganjones.internal as uid=zimbra,cn=admins,cn=zimbra
Checking ldap on zldap.morganjones.internal:389
Unable to startTLS: Resource temporarily unavailable
Couldn't bind to zldap.morganjones.internal as uid=zimbra,cn=admins,cn=zimbra
checking isEnabled zimbra-store

Aha.. an LDAP connectivity problem.

Hidden Download: JES4 or Messaging 2005q4

Or where do I download,, and

Sun has released Java Enterprise System 5 (JES5), comprised of Messaging 6.3 and Directory 6.0. The upgrade from JES4 or Messaging and Directory 2005q4 is pretty well documented.

What Sun does not document is where an integrator like myself would download a copy of 2005q4 to test upgrades in preparation for upgrading for a customer.

Their all downloads page lists iPlanet 5.2 (the version before 2005q4) and Java Enterprise System 5 or JES5 (the version after 2005q4).

It turns out it’s available on bigadmin.

mod_auth_ldap or mod_auth_ldap?

There are (at least) two Apache 2.0 modules that allow ldap authentication against ldap. This is of course not unusual. It is unusual that they have the same name. It would have saved me a lot of time if I’d read a post like this one before attempting to configure Apache’s mod_auth_ldap from an example that used Muhammad Muquit’s mod_auth_ldap.

Redhat AS4 and FC5 ship with Apache’s mod_auth_ldap.

Muhammad’s mod_auth_ldap seems to provide a few more options, notably ldap debugging.

Details here:

The syntax is different. The basic functionality is the same. Muhammad’s module seems a little more configurable. They both work fine. Here are examples of each:

Muhammad’s mod_auth_ldap:

    # ...
    AuthType Basic
    LDAP_Debug On
    LDAP_Port 389
    Base_DN "dc=morganjones,dc=org"
    LDAP_Protocol_Version 3
    LDAP_Port 389
    # I have not tried require valid-user with Muhammad's mod_auth_ldap but
    # I surmise it will work.
    # I have seen require user work like this:
    # require user user1 user2 user3
    require valid-user

Apache’s mod_auth_ldap:

    # ...
    AuthLDAPURL ldap://,dc=org
    Require valid-user

All upgrade channel, all the time

I recently completed a minor upgrade to a mid-sized messaging installation:

Java Messaging Server 6.1 to 6.2 (patch 118207-58)
Java Directory 5.2 (patch 115614-26)
Symantec Brightmail to 6.0.4

Java Admin Server 115610-23
LDAP JDK 118615-01

The infrastructure consists of 4 mtas (Sun 280Rs), 4 mail stores (v880s) clustered with Veritas. LDAP is on separate hosts, 280Rs.

Brightmail scanners are installed on the MTAs.

The upgrade consists mostly of reading the patch READMEs and following the instructions. It’s surprisingly complicated logistically.

Symantec support is broken out into at least 2 tiers: Gold and Platinum. Gold support knows nothing of their enterprise products. It is impossible to be passed to platinum support from gold. The gold support people are also unaware that Brightmail suports Sun Java Messaging Server.

We originally had a contract problem that prevented us from getting to platinum support. Once we resolved that it took Symantec platinum support the better part of a day to discover that we needed their Brightmail software development kit (SDK) to integrate with Java Messaging Server. In retrospect Sun documents the process pretty completely in their how-to. You will need to get the SDK from Symantec.

Be sure to read the release notes for Brightmail 6.0.4. The install guide indicates that you can upgrade from version 6.0.x. You cannot upgrade from 6.0.0.x. You can install 6.0.4 over but it will not scan properly. You need to completely uninstall, rm -r /opt/brightmail and install 6.0.4. from scratch. We probably re-installed about a dozen times until all the pieces were working properly. I do not think we did anything wrong.

The post-install instructions for 115610 call for running mpsadminserver sync-cds:

usr/sbin/mpsadmserver sync-cds
Admin Id: admin
Admin Password:
Error: Ldap authentication failed (151:Unknown error.).
Do you want to try again ? [y/n]:

A look at the LDAP logs indicated authentication problems. It turned out the admin server ldap configuration was misconfigured. It always takes me a long time to figure this out so I’m writing it down. The admin server ldap configuration is stored in 2 places:

Update those two files and the mpsadmserver sync-cds will complete correctly.

Have a happy thanksgiving weekend. I’m just about finished visiting family in the south. I found out that in Georgia ‘dressing’ isn’t something you put on salad and crazy family gatherings are much less fun sober. They should really consider serving liquor to the guests. We fly home early tomorrow. I’m sure the airline industry is carefully preparing a miserable trip for us both as I type..