On 07/10/2012 08:59 AM, Greg Kuchyt wrote:
First off, I'm sorry if I missed a document somewhere that covers
this, but after some searching I failed to find such a source that
explicitly spells this out. In order to verify my findings in testing,
I had a couple questions about the userPassword attribute and its
relationship to the password policy.
Is it accurate that the 389DS password policy only comes into effect
when the LDAPv3 password modify operation is used (i.e. via ldappasswd)?
or an ldap MODIFY operation of the userPassword attribute.
I noticed that setting a default password hashing algorithm does not
affect my ability to use any type of hash or clear text in the
userPassword attribute or bind.
We have historically managed the userPassword field like it is any
other field and are looking to switch the hash type we use to store
passwords. I was wondering what exactly switching the default password
algorithm "does". From my testing it appears that it does not affect
the existing data or manual changes to it. This leads me to believe it
only comes into play during the password modify extended operation.
or an ldap MODIFY operation of the userPassword attribute.
Thanks for any help, and again my apologies if this is covered
somewhere and I failed to find it.
There is some info here -
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management.html#User_Account_Management-Managing_the_Password_Policy
What you really want to do is only send cleartext passwords to the
directory server, use only LDAP MODIFY or the password extop to change
it, and use only the LDAP BIND operation to authenticate to the
directory server. This will allow the directory server to internally
hash it for storage and comparison.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
