When APU was to deploy our first LDAP directory service, we were looking at running both OpenLDAP and Netscape/iPlanet Directory Server. The sole reason we were going to purchase the iPlanet directory server was because it had a password synchronization mechanism with NT 4. It was a major goal to have a single username and password for all major services running on windows and unix. However, when implementation time came around, we had moved to Windows 2000, which the iPlanet directory did not yet support sychronization with.
Much time has passed... and there are now several solutions to this heterogenious password problem. Binding to our OpenLDAP servers simply defers to AD via Kerberos. But the recent purchase and open sourcing of the iPlanet Directory by Red Hat caused me to be a little curious if the functionality was still there, so I did a little poking around. But first some history according to Red Hat:
The Directory Server project dates back to 1996, when Netscape hired the inventor of LDAP, Tim Howes, and his colleagues such as Mark Smith and Gordon Good from the University of Michigan. In 1999 AOL acquired Netscape and formed the iPlanet Alliance with Sun to jointly develop Netscape servers. From 1999 to 2001 the Netscape Directory Server team worked with Sun's Directory Server team, and later the Innosoft Directory Server (IDDS) team, in the U.S. in Santa Clara, CA and Austin, TX and in Grenoble, France on Directory Server and related products such as Meta Directory and Directory Access Router. The iPlanet alliance ended in October 2001, and Sun and Netscape forked the code base. From 2001 to 2004 the Netscape Directory Server team invested heavily on performance and multimaster replication. In December 2004, the Netscape Directory Server was acquired by Red Hat.
So I found that the product still includes the windows directory sync:
Identity Sync for Windows: This release allows administrators to set up bidirectional password synchronization between the following directories:
source: http://www.redhat.com/docs/manuals/dir-server/ds-eval-gdlns.html
- Red Hat Directory Server and Windows 2000 Active Directory
- Red Hat Directory Server and Windows NT SAM Registry
Here are some details from the Fedora Directory Server Architecture Wiki
Active Directory Sync
The server can synchronize users, groups and user passwords bidirectionally with Microsoft Active Directory and Windows NT4 Domain Controllers. For clarity we call changes made from the DS to Active Directory 'outbound' and changes propagated from Active Directory to the DS 'inbound'. All communication between the server and its Active Directory peer is via LDAP.
How Active Directory Sync Works
Active Directory Sync makes heavy use of the server's replication infrastructure. It uses the changelog for outbound changes in much the same way as regular multi-master replication does. However the process for inbound change propagation is different. Here the special Active Directory 'dirsync' feature is used to request the entries that have changed since the previous sync pass was completed.
Inbound Password Sync
There is no documented mechanism that allows retrieval of plain text passwords from Active Directory. Plain text password values are required because Active Directory and Directory Server use different incompatible one-way password hashing mechanisms. Therefore special steps must be taken to 'catch' password changes as they occur on the Active Directory machine, by means of a 'password hook' dll. This dll, along with its associated Win32 service, comprise the 'Password Sync Service'. The Password Sync Service is responsible for propagating password changes caught with the hook dll back to the peer Directory Server (via an SSL protected LDAP connection).
And I also found that they really haven't solved one of the problems that we have run into as well with our password reset application
Both Active Directory and Directory Server can enforce password policy that can enforce certain requirements upon passwords: minimum length, maximum age and so forth. Windows Sync does not synchronize the policies, nor does it ensure that the policies are consistent. This is something that the administrators of both systems must ensure is done. If password policy is not consistent, then password changes made on one system may fail when replayed on the other system.
source: http://www.redhat.com/docs/manuals/dir-server/ag/7.1/sync.html
It will be interesting to read more about how Red Hat / Fedora Directory differs from OpenLDAP. Having both in the Open Source community should improve each.
