This is the download page for Duke's code extensions to Jeremy Rumpf's original iPlanet 5.x Kerberos authentication plugin. As noted in the comments associated with the code below, this work incoroporates code written at OSU by Jeremy Rumpf, ideas derived from code written by Michael Gettes and copyrighted by Princeton University, and code written by Rob Carter at Duke University. The bulk of the code is released under the L-GPL.

Downloads

You can download the full source code for the Duke version of the krbdirp-1.4 plugin here.

A new (beta) version of the code is available for testing (version 1.5). The new version includes additional code intended to make the plugin compatible with the JES Directory Server version 6.2. The new code addresses interactions between the 6.2 DSCC and the plugin, and builds properly under Solaris 10 in 64 bit mode. The beta code is available here.

Please forward any questions or comments to the author at rob@oit.duke.edu or to the LDAP2PAM mailing list at ldap2map@georgetown.edu.

Additional supporting code (necessary for using the Solaris "door" mechanism described below to combat threadsafety problems in using various PAM libraries with the plugin) is also available. If you're planning on building the code to use the Solaris door mechanism, you'll need at least the add-in passauthd daemon, source to which is available here.

Likewise, if you're interested in using the passauthd daemon to integrate an LDAP with the Duke WebAuth web-based authentication mechanism, in addition to the WebAuth code (available here) you'll need the WebAuth Proxy Token PAM module.

Why extend the original krbdirp code?

The Duke extensions to the original krbdirp-1.1 code fall into two categories: Extensions which change the semantics of of plugin itself and extensions to support the use of PAM libraries as an alternative to direct Krb5 authentication for directory users. In the first category (enabled by compiling the code with with "-DDUKE" turned on in the Makefile) are a handful of changes designed to facilitate the use of the plugin in mixed Kerberos/non-Kerberos or PAM/non-PAM environments. Specifically, the extensions:

• Add support for runtime flags to control the default behavior of the plugin with respect to SSL and "traditional" LDAP authentication. The extensions add an "sslauthreq" runtime flag to the plugin which controls the default SSL behavior of the the plugin (sslauthreq=0 ==> plaintext authentication is allowed; sslauthreq=1 ==> binds must be performed over SSL-protected connections) and a "krb5default" runtime flag which controls the default behavior of the plugin itself (krb5default=0 ==> binds default to using "traditional" LDAP authentication, krb5default=1 ==> binds default to using the plugin).


• Add support for runtime flags to specify the names of two LDAP attributes which can then be used to control the behavior of the plugin with respect to SSL and "traditional" LDAP authentication on a per-user basis. The runtime flag "sslreqattr" specifies the name of an attribute which, if it exists for a given entry in the LDAP directory, explicitly controls the SSL behavior of the plugin for binds as that entity -- if the attribute is set to 0, the plugin allows plaintext binds; if the attribute is set to 1, the plugin requires SSL for all binds by that entity. Likewise, the runtime flag "krb5reqattr" specifies the name of an attribute which, if it exists for a given entry in the LDAP directory, explicitly controls the overall use of the plugin -- if the attribute is set to 0, binds as that entity follow the traditional LDAP authentication model (using "userpassword" values in the directory); if it's set to 1, binds as that entity use the Kerberos/PAM backend provided by the plugin.

In the second category (enabled by including -DPAM or -DDOOR along with -DDUKE in the Makefile) is a set of extensions which essentially replace the original Krb5 back-end with a PAM-based back-end. The extension merely replaces the underlying "verify()" routine in Jeremy's original code with a PAM-enabled version. It retains the plugin's authentication caching features, replacing only the back-end password verification routine and leaving the cache-checking wrapper routines intact.

In the "-DPAM" case, the code incorporates PAM support directly into the plugin. This has the advantage of being self-contained, but has disadvantages in situations where the PAM libraries used are not entirely threadsafe, or where they aren't relatively threadsafe in the context of the LDAP server processes. Specifically, since both the LDAP server code and the MIT Kerberos code make heavy use of thread-unsafe DNS resolver calls, and since the SunOne plugin API doesn't expose any of the mutexes used internally to do thread interlocking around DNS resolver calls, operating in "-DPAM" mode with Kerberos PAM libraries can be risky. In our experience at Duke, we've found that it's typically not an issue when running on a single-processor machine -- the plugin ensures that it's the only code running on a given processor. In multi-processor environments, however, the plugin isn't able to interlock with LDAP threads running on different processors, and frequently runs into thread collisions.

For this reason, we introduced the "-DDOOR" option. Built with "-DDOOR" rather than "-DPAM", the plugin expects to communicate through a Solaris door with an external daemon (passauthd) which incorporates all of the requisite PAM library calls, and simply reports success or failure back to the plugin through its door. We've been running this version of the plugin code at Duke in production for over two months, and have found performance to be at least as good with the "-DDOOR" version as with the "-DPAM" version, and since moving to the separate-daemon model, we've experienced no thread collisions. It is worth noting that the "door" mechanism is very Solaris-specific -- in future, we'd like to make available mods to also support using a named pipe or local unix-domain socket to exchange information between the plugin and the passauthd daemon, but for now, this feature is only available for Solaris servers.

Caveats

• This code has been thoroughly scrutinized by local staff and has been running in production on Duke's main campus directory servers for over two months, handling in excess of 100,000 requests per day at peak load. Thus far, we've had very good experiences with it in production. We believe the code to be essentially free of insects, but bugs may yet be uncovered. Your mileage may vary.


• New! Duke has tested this code with the SunOne 5.1p1, SunOne 5.1p2, and now SunOne 5.2 releases. Duke still doesn't operate a v4 iPlanet server, so although we expect that the original v4 code should still work, we're not terribly optimistic that the Duke extensions will work correctly in a v4 environment. If there are still any v4 installations out there that would like to try out the code, please let us know how it goes...


• New! There have been some reports of folks' beginning to run the SunOne 5.2 release in 64-bit mode on Solaris systems. Locally, we're running in 32-bit mode for the time being, but it's been suggested that some sites have had difficulty building the krbdirp plugin in 64-bit mode. The best recon we have at this point indicates that folks are having more luck using the Forte compiler suite rather than GCC when trying to build in 64-bit mode. We'll be testing 64-bit mode on our local servers at Duke in coming weeks, and hope to get a line on how best to get GCC to build the code properly in 64-bit mode, but in the meantime, the recommendation is to use the Forte compiler if you can.