18.104.22.168 - SASL CRAM-MD5 Authentication
The CRAM-MD5 SASL mechanism is defined by RFC 2195.
We will have an exchange between the client, which will send an empty Bind request (i.e., the username and credentials won't be sent the first time), and the server will return a challenge.
The client first send a BindRequest with no credentials:
MessageType : BIND_REQUEST Message ID : 1 BindRequest Version : '3' Name : 'null' Sasl credentials Mechanism :'CRAM-MD5' Credentials : null
The server will return a BindResponse with a SASL_BIND_IN_PROGRESS status :
MessageType : BIND_RESPONSE Message ID : 1 BindResponse Ldap Result Result code : (SASL_BIND_IN_PROGRESS) saslBindInProgress -- new Matched Dn : '' Diagnostic message : '' Server sasl credentials : '0x3C 0x2D 0x37 0x38 0x30 0x39 0x37 0x35 0x33 0x32 0x33 0x38 0x35 0x32 0x31 0x37 0x37 0x37 0x37 0x35 0x30 0x2E 0x31 0x33 0x36 0x35 0x34 0x31 0x31 0x39 0x32 0x37 0x30 0x33 0x30 0x40 0x6C 0x6F 0x63 0x61 0x6C 0x68 0x6F 0x73 0x74 0x3E '
and will accordingly send a new BindRequest with the appropriate credentials which have been hashed with the server's provided challenge token :
MessageType : BIND_REQUEST Message ID : 2 BindRequest Version : '3' Name : 'null' Sasl credentials Mechanism :'CRAM-MD5' Credentials : (omitted-for-safety)
In any case, the full exchange aims at transferring the user's credential encrypted instead of passing it in clear text. Once the server receives the password, it will check it against the stored password which must be stored in clear text.
When the server receives a SASL PLAIN bind request, it will look for the first entry which uid is equal to the provided value, starting from the server searchBaseDN position in the DIT.