I have been experimenting further and noticed that the reason why the
authentication failed when the userPassword attribute had the value
{SHA}3DRF4FXpG8r+Ki8i8azuZh7KwO8= was because I did not have {SHA}, but {
SHA }. The embedded space characters muck up everything.
After fixing this the authentication succeeds - but not in the way I want.
With this setup the client still has to send the original
password "ThisIsthePassword" in the clear. What the OpenLDAP server seems
to be doing is to process the received password according to the
stipulation in the userPassword attribute for the relevant user, and
compare the output with the value of this attribute (after Base64-decoding
this value.)
I would actually need the opposite. That is, the target password may be
stored in the LDAP server in the clear, and the client should send not the
password, but its Base64-encoded SHA-1 digest. On receiving this the LDAP
server ought to compute the SHA-1 digest of the value of the userPassword
attribute for the relevant user, Base64-encode it and compare it with the
data received from the client in order to carry out the authentication.
How can this be done in OpenLDAP and within the LDAP standards? The goal
here is to make sure that the password gets never transferred in the clear.
I would agree that this really adds much in the way of security, and that
the right way to do it would be to establish a TLS channel between client
and server, but that's a different story.
what I would need is for the password to be sent by the client as a SHA-1
hash (Base64-encoded, if necessary)
On Sep 10, 2010 9:54am, [email protected] wrote:
I have an OpenLDAP 2.4.23 server up and running in a Linux box L against
which I can carry out password authentication on behalf of users logging
into an embedded system E. To accomplish this, in LI have an LDIF file
with entries along the following lines:
dn: uid=xxx,ou=yyy,dc=zzz,dc=com
uid: xxx
cn: xxx
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: ThisIsthePassword
shadowLastChange: 14014
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1003
gidNumber: 1003
homeDirectory: /home/xxx
gecos: ,,,
I would like to change this so that, when sending password information
from my LDAP client in E to the LDAP server in L, the password itself is
never sent in the clear. So I thought to change the value of the
userPassword attribute to read
{SHA}3DRF4FXpG8r+Ki8i8azuZh7KwO8=
instead, where the string above was obtained by means of
slappasswd -v -s ThisIsthePassword -h "{SHA}"
in L.
After restarting the LDAP server in L, when user xxx logs into E with
password "ThisIsthePassword" I can verify in the traces of the LDAP
server (I am running it as slapd -d 255) that the client in E is sending
the "3DRF4FXpG8r+Ki8i8azuZh7KwO8=" string, exactly as specified in the
value of the userPassword attribute. However, the authentication is
failing.
What is it exactly that the LDAP client in L is supposed to be sending to
the LDAP server in this case? I noticed that if the client sends the
actual "ThisIsthePassword" string instead the authentication also fails.
I am obviously missing something here but, what is it?
