Re: Bind Probs, slappaswd vs. LDAPAdmin Password value

[Max Merighi <mcmer@tor.at>]

Michael Ströder schrieb:
> Max Merighi wrote:
> 
>>
>> When I look at the Password Hashes it gets quite obvious, what is wrong:
>> the Hashes done by slappaswd for the Password supplied are 33 Bytes,
>> those by LDAPAdmin are 65 Bytes (just 'wc'-ing, without {SSHA}-Prefix,
>> same Password, both {SSHA}).
> 
> 
> Please post examples, e.g. password 'test' (without quotes) generated by
> LDAPAdmin.

I knew something wass going to be missing...

LDAPAdmin generates
{SSHA}AhJ/aUjwloRXbhUpzeAGTFSY3ZML3h6gBwC5FB2lVtwtffTGXWYPNg2OKm4O2KsMDoI=
when provided 'test' (w/o quotes)

ldappaswd generates
{SSHA}fm1NEL9CCIrQAQy1F3ba3flL6KbpjKNu
when provided 'test' (w/o quotes)


> 
>> It's clear that 'slappasswd' is 'the one'
> 
> 
> It's not clear since LDAPAdmin just could have chosen a longer salt.

according to 'man slapd.conf' & 'man slappasswd' 'salt' only applies to
'crypt' hashes?! Albeit, there's no option in LDAPAdmin to change the
hash string length, just the scheme (crypt, md5, ...)

Apart from that - if the length of the hash is variable, how is it
negotiated? And, if it is negotiated, what is going wrong?

One way or the other, when authenticating, both W32 Apps ought to
provide ldapd on $SERVER with the plain text password I type (no TLS
yet)..., right?! Strange enough, but when I change rootpw to plaintext
(*shudder*) in slapd.conf, it doesn't help at all.

It would be quite easy to blame it on LDAPAdmin (though actually if
LDAPAdmin was creating wrong Hashes, it shouldn't be able to
authenticate against its own Password Hashes - but it does), unless
there was Mozilla behaving equally strange.

> 
> See also:
> http://www.openldap.org/faq/data/cache/419.html

Thanks for the hint; what do I need these scripts for, when I got
slappasswd?

> 
> Ciao, Michael.
> 

To rule out the option of 'it's a network prob' I did a test from
another host with decent OS and ldapsearch... no Probs:

ldapsearch -D 'cn=Admin,dc=tor,dc=at' -x -W -b 'dc=tor,dc=at' -h axe
'(objectclass=*)'

lead to these log entries on the LDAP Server:

May 19 16:08:23 axe slapd[9955]: daemon: conn=14 fd=17 connection from
IP=192.168.3.1:16440 (IP=0.0.0.0:389) accepted.
May 19 16:08:23 axe slapd[9955]: conn=14 op=0 BIND
dn="CN=ADMIN,DC=TOR,DC=AT" method=128
May 19 16:08:23 axe slapd[9955]: conn=14 op=0 RESULT tag=97 err=0 text=
May 19 16:08:23 axe slapd[9955]: conn=14 op=1 SRCH base="dc=tor,dc=at"
scope=2 filter="(objectClass=*)"
May 19 16:08:23 axe slapd[9955]: conn=14 op=1 SEARCH RESULT tag=101
err=0 text=
May 19 16:08:23 axe slapd[9955]: conn=14 op=2 UNBIND
May 19 16:08:23 axe slapd[9955]: conn=-1 fd=17 closed



Thanks for your efforts,

Max