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.
I'll see if I can dig up an old design 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?
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?
I don't know where AD
stores the ntlm hash. But if it is possible to
get it, we could change passsync to send it or, more likely, change
winsync to pull it from AD.
The freeipa pwd extop plugin will create the samba ntlm hash from the
clear text password, so that should just work with freeipa.
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.
You should never store a password to the userPassword attribute
pre-hashed. You should always store the clear text password and let the
server compute the hash.
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?
No.