ZCS Administrator Guide 8.0
ZCS Administrator Guide 8.0
Network Edition


Zimbra LDAP Service > Account Authentication

Account Authentication
Supported authentication mechanisms are Internal, External LDAP, and External Active Directory. The authentication method type is set on a per-domain basis. If zimbraAuthMech attribute is not set, the default is to use internal authentication.
The internal authentication method uses the Zimbra schema running on the OpenLDAP server.
The zimbraAuthFallbackToLocal attribute can be enabled so that the system falls back to the local authentication if external authentication fails. The default is FALSE.
Internal Authentication Mechanism
The internal authentication method uses the Zimbra schema running on the OpenLDAP directory server. For accounts stored in the OpenLDAP server, the userPassword attribute stores a salted-SHA1 (SSHA) digest of the user’s password. The user’s provided password is computed into the SSHA digest and then compared to the stored value.
External LDAP and External Active Directory Authentication Mechanism
External LDAP and external Active Directory authentication can be used if the email environment uses another LDAP server or Microsoft Active Directory for authentication and Zimbra-LDAP for all other VMware Zimbra Collaboration Server-related transactions. This requires that users exist in both OpenLDAP and in the external LDAP server.
The external authentication methods attempt to bind to the specified LDAP server using the supplied user name and password. If this bind succeeds, the connection is closed and the password is considered valid.
The zimbraAuthLdapURL and zimbraAuthLdapBindDn attributes are required for external authentication.
*
zimbraAuthLdapURL attribute ldap://ldapserver:port/ identifies the IP address or host name of the external directory server, and port is the port number. You can also use the fully qualified host name instead of the port number.
For example:
ldap://server1:3268
ldap://exch1.acme.com
If it is an SSL connection, use ldaps: instead of ldap:. The SSL certificate used by the server must be configured as a trusted certificate.
*
zimbraAuthLdapBindDn attribute is a format string used to determine which DN to use when binding to the external directory server.
During the authentication process, the user name starts out in the format:
user@domain.com
The user name might need to be transformed into a valid LDAP bind DN (distinguished name) in the external directory. In the case of Active Directory, that bind dn might be in a different domain.
Custom Authentication
You can implement a custom authentication to integrate external authentication to your proprietary identity database. When an authentication request comes in, Zimbra checks the designated auth mechanism for the domain. If the auth mechanism is set to custom authentication, Zimbra invokes the registered custom auth handler to authenticate the user.
To set up custom authentication, prepare the domain for the custom auth and register the custom authentication handler.
Preparing a domain for custom auth
To enable a domain for custom auth, set the domain attribute, zimbraAuthMet to custom:{registered-custom-auth-handler-name}.
In the following example, “sample” is the name that custom authentication is registered under.
zmprov modifydomain {domain|id} zimbraAuthMech custom:sample.
Register a custom authentication handler.
To register a custom authentication handler, invoke ZimbraCustomAuth.register [handlerName, handler] in the init method of the
extension.
*
Class: com.zimbra.cs.account.ldap.zimbraCustomAuth
*
Method: public synchronized static void register [String handlerName, zimbraCustomAuth handler]
Definitions
handlerName is the name under which this custom auth handler is registered to Zimbra’s authentication infrastructure. This name is set in the domain’s zimbraAuthMech attribute of the domain.
handler is the object on which the authenticate method is invoked for this custom auth handler. The object has to be an instance of zimbraCustomAuth (or subclasses of it).
Example
How Custom Authentication Works
When an authentication request 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 ZimbraCustomAuth.authenticate (). All attributes of the account can be retrieved from the account object.
Kerberos5 Authentication Mechanism
Kerberos5 Authentication Mechanism authenticates users against an external Kerberos server.
1.
Set the domain attribute zimbraAuthMech to kerberos5.
2.
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.
To specify Kerberos5 for an individual account set the account’s zimbraForeignPrincipal as kerberos5:{kerberos5-principal}. For example: kerberos5:user1@MYREALM.COM.
Copyright © 2012 VMware Inc.