SMTP Auth LDAP issue: Plain instead of MD5

rokeeffe265 · ‎11-27-2008

Hi all,

Just going through the mail_logs and I'm seeing the following.

SMTP Auth: (ICID 147196) succeeded for user: xxxxxx using AUTH mechanism: PLAIN with profile: SMTP Auth

I have set SMTP Auth to use the following LDAP query in System Administration>LDAP>our LDAP server>SMTP Authentication Query

Name: Our LDAP server.smtpauth
Query string: (&(uid={u})(services=imaps))

'Authenticate by fetching the password as an attribute' is ticked and....
'SMTP Authentication Password Attribute' is set to: userPassword

Then under Network>SMTP Authentication>Profile Name>SMTP Auth
the following is set.

Profile Name: SMTP Auth
LDAP Query: our LDAP server.smtpauth
Default Encryption Method: MD5

I'm thinking that instead of 'Plain' in the logs above I should be seeing 'MD5'.

One thing I should mention is that our LDAP server type is set to 'Unknown or Other'. If I set it to OpenLDAP (which it actually is) sending a mail works, but takes anything up to 20 seconds or more to send. A delay that no one is willing to live with.

Any ideas or am I barking up the wrong tree altogether..?

Douglas Hardison · ‎12-09-2008

The AUTH mechanism is negotiated between the email client and the IronPort, so I would deouble-check the settings of the client.

Also, make sure the email client is even capable of AUTH mechanisms other than PLAIN or LOGIN ( which are most common ).

rokeeffe265 · ‎12-10-2008

Cheers Whardison,

I was heading along those lines as I noticed that any user sending from Mail on their Macs were listed as 'PLAIN', whereas Outlook users were showing as 'LOGIN' for their AUTH Mechanism.

Regards.

Donald Nash · ‎12-10-2008

 I was heading along those lines as I noticed that any user sending from Mail on their Macs were listed as 'PLAIN', whereas Outlook users were showing as 'LOGIN' for their AUTH Mechanism.

Just FYI, the LOGIN method is deprecated, and has been replaced by PLAIN. Clients which use LOGIN simply haven't caught up with the standard.

Beyond that, whardison is right, you need to check the client settings. If the clients are properly configured to ask for CRAM-MD5, then the next step is to eavesdrop on a connection to see what actually transpires.

Incidentally, I'm not a big fan of CRAM-MD5. It requires keeping plaintext passwords on the server, which makes them more vulnerable to being stolen if the server is compromised. We use PLAIN and LOGIN over encrypted connections.