Directory Glitch Trips Authentication Efforts

Computerworld - I have had mixed success with a project to provide two-factor authentication access to our critical Unix and Windows NT servers. We want to set up a system that requires employees to use SecurID tokens for administrative access to our production Solaris, Windows NT and Windows 2000 servers, but we have run into a few snags.
The first problem occurred on the Solaris side. Our company uses Novell Inc.'s eDirectory for our corporate directory services. It's based on the Lightweight Directory Access Protocol (LDAP). But as we learned, LDAP compliance doesn't guarantee interoperability.
We wanted to configure all of our Solaris servers to point to the eDirectory server for authentication credentials. We considered using special software called the Pluggable Authentication Module (PAM) from Melbourne, Australia-based PADL Software Pty. This set of open-source libraries enables LDAP communication between Solaris 2.8 and eDirectory. But because of a lack of support from PADL and concerns about compatibility with future patches and software updates, we decided to stick with a supported methodology. In retrospect, perhaps we should have taken the risk.
The Solaris distribution includes a native LDAP client that's supposed to work with other LDAP-compliant directory servers. In theory, when an administrator logs in, eDirectory should compare the log-in information against its database. If the account has the proper authorization, credentials and a valid SecurID token, the eDirectory server should grant the administrator access to the resource. This setup should work well, since it lets us avoid maintaining local accounts on every Solaris system. We also could have used Solaris' Network Information Service, but we steered away from it because of known vulnerabilities.
Since our company is using eDirectory, it made sense to use the same repository and add an authorization mechanism to provide centralized access control to our production environment, which consists of 300-plus Solaris servers. Right away, we ran into a problem with the Solaris 2.8 native LDAP client. Apparently, it has problems negotiating with eDirectory. We contacted the support folks at Novell, and they have confirmed that such problems exist. So much for standards!
This won't be a problem once we upgrade all of our servers to Solaris 9, since its native LDAP client works fine. But it's going to be at least eight months before we can even start that upgrade. Between now and then, we have few options. We could use Novell's dirXML, a bidirectional metadirectory data-sharing service that will supposedly let us use eDirectory to distribute new and updated directory information to our Solaris servers. But if