The Internal authentication method assumes the Zimbra schema running on the OpenLDAP directory server.
The External LDAP and
External Active Directory authentication methods attempt to bind to the specified LDAP server, using the supplied user name and password. These methods can be used if the email environment uses Microsoft Active Directory directory services for authentication and the Zimbra-LDAP directory services for all other Zimbra-related transactions. This requires that users exist in both OpenLDAP and in the Active Directory servers.
The authentication method type is set on a per-domain basis, using the zimbraAuthMech attribute, with other information also coming from the domain. If this attribute is not set, the default is to use the internal method as the authentication.
For accounts stored in the OpenLDAP server, the userPassword attribute stores a salted-SHA1 (SSHA) digest of the user’s password. This information is not used to connect to the directory server; it is only used to compare with the information on the OpenLDAP server, using a pool of re-usable administrator LDAP connections.
Unlike the internal authentication mechanism, the external authentication mechanism attempts to bind to the directory server using the supplied user name and password. If this bind succeeds, the connection is closed and the password is considered valid.
The zimbraAuthLdapURL attribute contains the URL of the Active Directory server to bind to. This should be in the form:
where ldapserver is the IP address or host name of the Active Directory server, and
port is the port number. You can also use the fully qualified host name instead of the port number.
For SSL connection, use ldaps: instead of
ldap:. If the SSL version is used, the SSL certificate used by the server must be configured as a trusted certificate.
The zimbraAuthLdapBindDn attribute is a format string used to determine which user name to use when binding to the Active Directory server.
The user name may need to be transformed into a valid LDAP bind dn (distinguished name). In the case of Active Directory, that bind dn might be in a different domain.
You can implement a custom authentication on your domain. Custom authentication allows external authentication to your proprietary identity database. When an AuthRequest comes in, Zimbra checks the designated auth mechanism for the domain. If the auth mechanism is set to custom auth, Zimbra invokes the registered custom auth handler to authenticate the user.
To register a custom authentication handler, invoke ZimbraCustomAuth.register [handlerName, handler] in the init method of the extension.
When an AuthRequest comes in, if the domain is specified to use custom auth, the authenticating framework invokes the authenticate method on the
ZimbraCustomAuth instance passed as the handler parameter to
ZimbraCustomAuth.register ().
The account object for the principal to be authenticated and the clear-text password entered by the user are passed to the
ZimbraCustomAuth .authenticate () method. All attributes of the account can be retrieved from the account object.
Kerberos5 Authentication Mechanism authenticates users against an external Kerberos server. To set up Kerberos5 auth set the domain attribute zimbraAuthMech to kerberos5. Then set the domain attribute zimbraAuthKerberos5Realm to the Kerberos5 realm in which users in this domain are created in the Kerberos database.
When users log in with an email password and the domain, zimbraAuthMech is set to
kerberos5, the server constructs the Kerberos5 principal by
{localpart-of-the-email}@{value-of-zimbraAuthKerberos5Realm} and uses that to authenticate to the kerberos5 server.
Kerberos5 can be supported for individual accounts. This is done by setting the account’s zimbraForeignPrincipal as kerberos5. Set the account's
zimbraForeignPrincipal as
kerberos5:{kerberos5-principal}. For example: kerberos5:user1@MYREALM.COM. If
zimbraForeignPrincipal starts with
“kerberos5:
”, the server uses {kerberos5-principal} as the Kerberos5 principal instead of the algorithm of grabbing the realm from the zimbraAuthKerberos5Realm as mentioned in the previous paragraph.
