Here is an example of the problem:
Oct 9 13:19:53 smtp-outgoing2 dovecot: auth: Debug: password(user@domain.tld,192.168.160.49): Generating NTLM from user 'user@domain.tld@', password 'IfBG6G3jykirE5r5vienC4w==' Oct 9 13:19:53 smtp-outgoing2 dovecot: auth: Debug: password(user@domain.tld,192.168.160.49): Credentials: f124dc24328ed3d90db035f0d5284636
The listed password is a base64 representation of its encrypted form which I need to somehow decrypt between the time LDAP returns it and these credentials are generated.
On Tue, Oct 9, 2012 at 1:16 PM, James Devine fxmulder@gmail.com wrote:
I don't think I understand. Right now the problem is the password retrieved from LDAP cannot be hashed to compare against what the user sent because it is encrypted. I have to perform my AES decryption before it can be hashed and compared.
On Tue, Oct 9, 2012 at 1:03 PM, btb btb@bitrate.net wrote:
On 2012.10.09 14.41, James Devine wrote:
We have an LDAP server that contains AES encrypted passwords. So far I've been able to use this by adding a passdb module that encrypts the user's password prior to ldap comparison. Now I am looking at supporting client-side encrypted passwords. To do this I need to decrypt the password returned by LDAP. Is there a way to insert a module to do this decryption between ldap returning and the auth mechanism?
that would be unwise, generally speaking. as a rule of thumb, in terms of security fundamentals, only the rootdn [or equiv] should be able to read the values in an ldap entry's password attribute. certainly the service account used by dovecot should not.
in the context of ldap, authentication should be accomplished by binding as the user, not by retrieving attribute values and performing string comparisons. among other things, this decouples the two components and allows applications [e.g. dovecot] to be unconcerned with whatever password hashing scheme the directory server might be using.
-ben