On Thu, Nov 13, 2008 at 01:45:09PM -0800, Howard Chu wrote:
I don't believe you need to write a special plugin to retrieve passwords from AD; MS already has a password sync plugin.
http://technet.microsoft.com/en-us/library/bb463208.aspx
All that's needed is to write a small module for slapd that reads these sync messages.
The unix-end code is available from Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyID=2BA5C443-D972-4B13-...
It includes source code so it can be built for whatever platform you want (in theory at least: the code is rather messy and has several problems).
Remember that you cannot get *current* passwords out of AD because it does not store them. All password-related stuff is delegated to Kerberos. What the SFU (Services For Unix) stuff gives you is a notification whenever a password is changed. This includes the first time it is set so you can use the notification as a trigger to go and fetch the data on new users.
As the messages contain cleartext passwords they are encrypted on the network. I have not analysed the protocol to see if this is done properly, but looking at the overall code quality I doubt that security researchers would approve. I do know that the encryption code fails on 64-bit SPARC machines (though it is OK if built in 32-bit mode).
The Unix-end daemon (ssod) has code to handle some passwd-file variants and it claims to work with PAM but the implementation is not complete enough to use.
I have modified versions of ssod running in a couple of customer sites. We changed it to call an external script to do the password update rather than adding LDAP code to the daemon itself. This makes it much easier to modify the update policy, and *much* easier to debug.
The Windows-end code is supplied in binary as part of the SFU package. It has to be installed on *every* AD Domain Controller in your domain in order to catch password changes. This fact was enough to prevent SFU/ssod from being used in another customer as they were not prepared to install new code on their very large number of domain controllers.
There is no test program to send simulated changes to the ssod. Testing has to be done by changing real passwords on a real AD domain.
Alternatives:
It would be worth looking at:
http://acctsync.sourceforge.net/ http://sourceforge.net/projects/passwdhk
Both seem to be relatively inactive but passwdhk claims to be production-ready.
Andrew