ZCS Administrator's Guide 7.2.3
ZCS Administrator's Guide 7.2.3
Open Source Edition


Zimbra LDAP Service > Account Authentication

Account Authentication
This section describes the following account authentication mechanisms and formatting directives that are supported:
*
*
*
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.
Internal Authentication Mechanism
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.
External LDAP and External Active Directory Authentication Mechanism
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.
Two additional domain attributes are required for the external mechanism: zimbraAuthLdapURL and zimbraAuthLdapBindDn.
zimbraAuthLdapURL Attribute and SSL
The zimbraAuthLdapURL attribute contains the URL of the Active Directory server to bind to. This should be in the form:
ldap://ldapserver:port/
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.
Examples include:
ldap://server1:3268
ldap://exch1.acme.com
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.
zimbraAuthLdapBindDn Attribute
The zimbraAuthLdapBindDn attribute is a format string used to determine which user name to use when binding to the Active Directory server.
During the authentication process, the user name starts out in the format:
user@domain.com
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.
zimbraAuthFallbackToLocal Attribute
The zimbraAuthFallbackToLocal attribute can be enabled so that the system falls back to the ZCS local authentication if external authentication fails. The default is FALSE.
Custom Authentication - zimbraCustomAuth
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 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}.
For example:
zmprov modifydomain {domain|id} zimbraAuthMech custom:sample.
In the above example, “sample” is the name under which a custom auth mechanism is registered.
Registering 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]
Note:
handlername is the name under which this custom auth handler is registered to Zimbra’s authentication infrastructure. This is the name that is set in the domain’s zimbraAuthMech attribute. For example, if the registered name is “sample”, than zimbraAuthMech must be set to custom:sample.
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 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 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. 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.
Copyright © 2013 VMware Inc.