I have a weird problem with an in-memory instance, started via Spring Boot.
The attached LDIF is used to initiate the server and I can connect to it
with "uid=admin" with ldapsearch and Apache Directory Studio. But when I
try using the user from the LDIF to bind, I receive an error 49 saying
the password was wrong. It definitely isn't. So I am a bit lost. Any hints?
The problem is that the user entry has a password encoded using a crypt-based format (and specifically one that involves many rounds of processing with a 512-bit SHA-2 digest), and the in-memory directory server does not provide native support for that format. By default, the in-memory directory server only supports passwords in the clear.
You can use the InMemoryDirectoryServerConfig.setPasswordEncoders method to add support for one or more password encodings, but the crypt-based scheme you're trying to use isn't one that is implemented in the LDAP SDK. If you want to use the in-memory directory server without alteration, I'd recommend either updating your test LDIF file to have the password in the clear, or to have them encoded in a way that the LDAP SDK does support (for example, salted or unsalted SHA-1 or SHA-2 digests). If you need to use passwords encoded in that specific crypt format, then your only option at present would be to write a custom InMemoryPasswordEncoder to handle it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is that the user entry has a password encoded using a
crypt-based format (and specifically one that involves many rounds of
processing with a 512-bit SHA-2 digest), and the in-memory directory
server does not provide native support for that format. By default,
the in-memory directory server only supports passwords in the clear.
Yep, that was the problem. Thanks so much.
You can use the InMemoryDirectoryServerConfig.setPasswordEncoders
method to add support for one or more password encodings, but the
crypt-based scheme you're trying to use isn't one that is implemented
in the LDAP SDK. If you want to use the in-memory directory server
without alteration, I'd recommend either updating your test LDIF file
to have the password in the clear, or to have them encoded in a way
that the LDAP SDK does support (for example, salted or unsalted SHA-1
or SHA-2 digests). If you need to use passwords encoded in that
specific crypt format, then your only option at present would be to
write a custom InMemoryPasswordEncoder to handle it.
In this scenario, it is absolutely fine to use clear text, as it is for
local development only. Thanks for the swift and spot on answer!
I have a weird problem with an in-memory instance, started via Spring Boot.
The attached LDIF is used to initiate the server and I can connect to it
with "uid=admin" with ldapsearch and Apache Directory Studio. But when I
try using the user from the LDIF to bind, I receive an error 49 saying
the password was wrong. It definitely isn't. So I am a bit lost. Any hints?
The problem is that the user entry has a password encoded using a crypt-based format (and specifically one that involves many rounds of processing with a 512-bit SHA-2 digest), and the in-memory directory server does not provide native support for that format. By default, the in-memory directory server only supports passwords in the clear.
You can use the InMemoryDirectoryServerConfig.setPasswordEncoders method to add support for one or more password encodings, but the crypt-based scheme you're trying to use isn't one that is implemented in the LDAP SDK. If you want to use the in-memory directory server without alteration, I'd recommend either updating your test LDIF file to have the password in the clear, or to have them encoded in a way that the LDAP SDK does support (for example, salted or unsalted SHA-1 or SHA-2 digests). If you need to use passwords encoded in that specific crypt format, then your only option at present would be to write a custom InMemoryPasswordEncoder to handle it.
On 06/09/2018 20:50, Neil Wilson wrote:
Yep, that was the problem. Thanks so much.
In this scenario, it is absolutely fine to use clear text, as it is for
local development only. Thanks for the swift and spot on answer!
Cheers,
Holger