Cisco Cisco Email Security Appliance C170 Guia Do Utilizador

The convention in OpenLDAP, based on RFC 2307, is that the type of coding is prefixed in curly braces 
to the encoded passphrase (for example, “{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=”). In this 
example, the passphrase portion is a base64 encoding of a plain text passphrase after application of SHA.

The appliance negotiates the SASL mechanism with the MUA before getting the passphrase, and the 
appliance and the MUA decide on what method (LOGIN, PLAIN, MD5, SHA, SSHA, and CRYPT SASL 
mechanisms are supported). Then, the appliance queries the LDAP database to fetch a passphrase. In 
LDAP, the passphrase can have a prefix in braces.

If there is no prefix, the appliance assumes that the passphrase was stored in LDAP in plaintext. 

If there is a prefix, the appliance will fetch the hashed passphrase, perform the hash on the username 
and/or passphrase supplied by the MUA, and compare the hashed versions. The appliance supports 
SHA1 and MD5 hash types based on the RFC 2307 convention of prepending the hash mechanism 
type to the hashed passphrase in the passphrase field.

Some LDAP servers, like the OpenWave LDAP server, do not prefix the encrypted passphrase with 
the encryption type; instead, they store the encryption type as a separate LDAP attribute. In these 
cases, you can specify a default SMTP AUTH encryption method the appliance will assume when 
comparing the passphrase with the passphrase obtained in the SMTP conversation. 

The appliance takes an arbitrary username from the SMTP Auth exchange and converts that to an LDAP 
query that fetches the clear or hashed passphrase field. It will then perform any necessary hashing on the 
passphrase supplied in the SMTP Auth credentials and compare the results with what it has retrieved 
from LDAP (with the hash type tag, if any, removed). A match means that the SMTP Auth conversation 
shall proceed. A failure to match will result in an error code.