On UNIX (Gnu-Linux) the standard server for LDAP is OpenLDAP (http://www.openldap.org). LDAP and its server are also an integral part of Windows Active Directory, which we use heavily. The question has come up, shouldn't we pick one of these LDAP servers and stick with it?
For UNIX a complete set of schemas is provided in
and by using
/usr/sbin/schema2ldif followed by
slapadd or ldapadd you
can import whichever ones you need. If you use
/etc/openldap/slapd.conf, it has an "include" statement for
The Windows LDAP server is stuffed with its proper schema out of the box. On Windows, ldapadd can probably be used to add a foreign schema to an already working server, given the needed authentication codes. Conversely, ldapsearch should deliver a complete dump of the Windows schema in a form that could be added to the OpenLDAP server, provided the UNIX side could authenticate itself to Windows A.D.
On Windows I'm not totally clear here but I believe that the host OS instance on each machine has a Kerberos secret key to authenticate itself ("joining the domain") and an authorization for fairly broad write access to the Windows portion of the LDAP database. Also there is probably a similar authorization for the global administrator. How to get such an authorization for a UNIX machine and/or the UNIX root user is not too obvious, particularly for unattended operation. However, there are rumors that a few people have made this work.
On UNIX, GSSAPI (Kerberos) can be used for authentication, but long-lived Kerberos authentication is considered to be a security hazard, making this form unpopular for unattended operation. Normally one uses an unencrypted password (secret key) protected by UNIX file permissions. In reality this is equivalent to what Windows does, both functionally and in security. If the UNIX LDAP server handled Windows as well, we would have to learn what Windows was going to present for authentication (e.g. which Kerberos principal name), and how Windows expects the LDAP server to believe in the authorization for this principal. There are rumors that this can be made to work.
On Windows the LDAP content is included in standard dumps, but I don't know what form it takes or how much you can hack it to repair corruption.
On UNIX you would use
to dump the database as LDIF,
LDAP Data Interchange Format, basically key-value pairs in ASCII or
UTF-8. With the normally used HDB and BDB backends for database
storage, this can be done safely with the server running. The output
would go in
master-site:/h1/backup and would end up in our regular
filesystem backups, similar to what we do for other UNIX databases.
LDIF can be hand-edited to repair corruption, and we can put back the
repaired stanzas with ldapmodify, or in case of a total loss we can
restore the whole database using slapadd, not requiring that the server
be functional (i.e. having schemas and authentication codes) before
Just like NIS, on UNIX the LDAP tables are basically representations of
the traditional UNIX directory flat files, e.g.
OpenLDAP does not include migration tools to translate between the flat
files and the tables, there is a simple flat to LDAP migration tool
available on the web, and I am writing a more complete one which will
also translate a table to a flat file, and it can do diffs. Both these
tools are independent of the vendor, that is, should work on a Windows
LDAP server, given the needed schema and authentication codes.
Given that we probably could figure out how to make Windows use UNIX LDAP, or UNIX use Windows LDAP, what should we do along these lines in the near term?
Our major goal is to have Zimbra working at the same time PSNet's Zimbra server comes on line, that is, well before the end of Summer. This is a political issue and cannot be delayed.
Zimbra requires LDAP for storing its mail alias information, and if we want to coordinate authenticaton and authorization with the host OS, which we definitely do, then that information has to be functional on LDAP as well.
To provide UNIX directory service to a UNIX OS from a UNIX LDAP server is well understood with a high probability of success and a low probability of delays. Similarly, the Windows LDAP server is already providing directory services to Windows. Learning to make this work across OS's seems difficult and subject to delays. I recommend that we should not pursue UNIX-Windows integration until after Zimbra is functioning and is satisfactory.
On the other hand, we have a long-term goal to use one identity and password for both UNIX and Windows, that is, Kerberos integration. To make that work properly, LDAP integration is probably essential. So we should not give up on LDAP integration, just defer it.