UNIX and Windows LDAP Server

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?

Requirements for the LDAP Servers

We must be able to get the schemas (table format definitions) for both operating systems onto the server.

For UNIX a complete set of schemas is provided in /etc/openldap/schema, 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 schemas.

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.

Each operating system must be able to authenticate so as to read and write arbitrary table content, including for unattended operation (nightly housekeeping).

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.

Useable dumps must be made of the LDAP database.

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 /usr/sbin/slapcat 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 restoration.

We are going to have to transfer our NIS-based directory to LDAP. Our administrative tools (acctadmin) depend on UNIX directory flat files.

Just like NIS, on UNIX the LDAP tables are basically representations of the traditional UNIX directory flat files, e.g. /etc/passwd. While 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.

Near-Term Actions

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.