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, 1.41421@gmail.com 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 L I 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?