The current behavior is that if a user password is stored one way
encrypted in the partition, and a client uses the clear text value
during a bind request, he is authenticated (if the hash value of the
clear text password corresponds to the stored value for the user). This
is independent from enabling/using LDAPS.
Providing the hashed value of the userpassword attribute instead of the
original value will be rejected by ApacheDS. This is intended. If
someone was able to catch this value (from an LDIF export for instance),
s/he must still provide the password itself in order to get authenticated.
From the client point of view, both is described with samples here:
http://cwiki.apache.org/DIRxSRVx10/authentication-options.html#Authenticationoptions-Passwordsstoredonewayencrypted
I hope this helps,
Greetings, Stefan
Thanks, that clears things up for me...and congrats on the wiki
documentation you pointed me at, it is most impressive!
My only remaining concern is that the clear text admin password is
stored in server.xml (which motivated my change), in case this file is
compromised somehow (i.e. installed with wrong permissions etc) in
which case the admin password becomes known regardless of whether the
version stored in the partition itself is one-way hashed.
So my understanding is that (even with my change to support one-way
hash in server.xml) users must choose between exactly one of these
options:
a) use one-way hashes for passwords persistently stored in AD partitions OR
b) use one-way hash for admin password stored in server.xml
It seems a shame that a user can't have both a) and b) at the same
time. I currently have to choose b) because of my company's installer
standards but I can see that not having a) raises an even more serious
security hardness problem.
