[389-devel] passsync

[Rich Megginson]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20091116/c897d8a0/attachment.bin>