[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: MS AD <-> OpenLDAP
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-81EF-8AD20F779F51&displaylang=en
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------