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.
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.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?
No.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
