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.
--
389-devel mailing list
389-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
