[389-devel] passsync

[Nathan Kinder]

On 11/16/2009 08:03 AM, John Dennis wrote:
> I looked, albeit it quickly, on the 389 web site for details on how 
> passsync works, but I didn't find any details only a how-to, so if the 
> answers to these questions are documented you could just point me to 
> the doc.
>
> The question arose in the context of one of our field people who wants 
> to use FreeRADIUS backed against a 389 LDAP server which is pulling 
> passwords from AD using passsync.
>
> FreeRADIUS needs ntlm hashes, but it can compute the ntlm hash from a 
> cleartext password if one is available (but it's better if the ntlm 
> hash is available in an attribute).
>
> My understanding is that passsync will update 389 with a cleartext 
> password only. Is that correct? Is it possible to have passsync also 
> update the ntlm hash by either pulling from AD or by computing it from 
> the cleartext at the moment it's writing the cleartext into the 389 
> attributes?
389 does not have any support for generating NTLM hashes.  I am not sure 
how easy it is to get the NTLM hash from AD.  It would be difficult to 
do this with the PassSync service since it simply uses a password filter 
DLL that is just handed the cleartext password.  It may be possible to 
have the sync agreement portion of winsync fetch the NTLM hash along 
with other non-password changes, but I'm not sure if AD exposes the hash 
over LDAPS.
>
> The next relevant issue is how password prefix's are handled. I don't 
> know if this is a standard or just a convention, but passwords can be 
> prefixed with their format enclosed in braces, e.g. {clear}, {crypt}, 
> {md5}, etc.
>
> It turns out that FreeRADIUS when it queries a password will only 
> recognize a clear text password vs. hash if it's prefixed with {clear} 
> or {cleartext}. Is passsync capable of prepending the password type 
> when it updates the password attribute?
Yes, the storage specifier is a standard defined in RFC 2307, but the 
userPassword attribute in LDAP was designed for cleartext password 
values only, so there is some ambiguity here.

Unless one is using a SASL authentication mechanism that requires a 
cleartext password to be stored (such as DIGEST-MD5), it is typically 
discouraged to have the cleartext password.  This means that the 
cleartext password sent to 389 by the PassSync service will be hashed by 
one of 389's password storage scheme functions before being stored in 
the database in most cases.  If cleartext is desired, the global 
password storage scheme (or a fine-grained password policy storage 
scheme) should be set to clear.  389 does not automatically add the 
"{clear}" storage specifier prefix as a password with no specifier 
should be interpreted as a cleartext password.