08 Jan Support queries shared: MailStore user authentication failing despite correct password

We have seen two separate issues recently where MailStore had been configured to use directory services to synchronise its user list with an external source. One being an MDaemon mail server and the other on a machine running Kerio Connect.

In both cases, even though the IMAP user account details were correct, the password check failed with an error that suggested a bad authentication result.

After some further investigation one thing both servers shared had in common was that even before MailStore was introduced, they were already synchronising to another external Active Directory Server.

The route of the problem

The problem stems from the fact that both mail servers supported the CRAM-MD5 secure password authentication type  This method of secure authentication was being offered to MailStore as a valid option to use when authenticating the IMAP account details.

Unfortunately because the users account details are not actually stored within MDaemon or Kerio when MailStore attempted to pass the MD5 hash of the password for the server to check against there was no local password it could use to create a similar MD5 hash and it was this that caused the failed authentication.

The communication looks something like this…

Step 1: User enters username and password into MailStore Client.

Step 2: The MailStore client passes username and password to mailstore server.

Step 3: The MailStore server opens up an IMAP session to the mail server ( MDaemon or Kerio) to verify password is correct.

Step 4: The mail server responds within the IMAP session to say it supports CRAM-MD5 as well as plain passwords.

Step 5: The MailStore server chooses the secure CRAM-MD5 encryption option over plain passwords and generates a hash of the user’s password to send to the mail server.

Step 6: To verify the passwords match, the mail server needs to generate a similar hash from a stored password. However as there is no stored password to use, it’s unable to do this and instead returns an error.

In both cases the mail server was also looking up the password live by checking an Active Directory server. To do this it needs to know the unencrypted version of the password to send and because it only has a hashed version to work with this fails. It can’t authenticate the IMAP sessions and is dropped.

This issue is not only related to MailStore sessions, any CRAM-MD5 encrypted  authentication attempts would fail in a similar way when Active Directory password lookup is used by the mail server in this way..

The workaround

To get authentication to work, the mail server must turn off support for CRAM-MD5 authentication, MailStore will then revert to using plain text passwords and this will work as expected.

Alternatively either Mailstore or the mail server must use local accounts and stored passwords rather than looking them up against an external user database such as Active Directory.

Hopefully that’ll save somebody banging their head against a brick wall – please feel free to let me know in the comments section below if there are any other topics you’d like me to cover.

.