Zimbra Directory Service

The Zimbra LDAP service is a directory service running a version of the OpenLDAP software that has the Zimbra schema already installed. This chapter describe how the directory service is used for user authentication and account configuration and management.

Note: Zimbra also supports integration with Microsoft’s Active Directory Server. Contact Zimbra support for more detailed information on specific directory implementation scenarios.

The LDAP server is identified when the Zimbra software is installed. Each server has its own LDAP entry that includes attributes specifying operating parameters. In addition, there is a global configuration object that sets defaults for any server whose entry does not specify every attribute.

A selected subset of these attributes can be modified through the Zimbra administration console; others can be changed through the CLI utility.

LDAP directory services provide a centralized repository for information about users and devices that are authorized to use your network. The central repository used for Zimbra’s LDAP data is the OpenLDAP directory server.

Figure 4 shows traffic between the Zimbra-LDAP directory server and the other servers in the Zimbra system. The Zimbra MTA and the Zimbra mailbox server read from, or write to, the LDAP database on the directory server. The edge MTA does not connect to the LDAP database; instead, it uses the DNS server’s MX entry to determine where to direct mail.

The Zimbra clients connect through the Zimbra server, which in turn connects to LDAP.

At the core of every LDAP implementation is a database organized using a schema. The schema specifies the types of objects that are stored in the database, and what types of attributes they have.

An LDAP directory entry consists of a collection of attributes and has a globally unique distinguished name (DN). The attributes allowed for an entry are determined by the object classes associated with that entry. The values of the object class attributes determine the schema rules the entry must follow.

The object classes determine what type of object the entry refers to and what type of data can be stored for that entry. An entry’s object classes that determines what kind of entry it is, is called a structural object class and cannot be changed. Other object classes are called auxiliary and may be added to or deleted from the entry.

Use of auxiliary object classes in LDAP allows for an object class to be combined with an existing object class. For example, an entry with structural object class inetOrgPerson, and auxiliary object class zimbraAccount, would be an account, either administrator or end-user. An entry with the object class zimbraServer would be a server in the Zimbra system that has one or more Zimbra software packages installed.

LDAP directories are arranged in an hierarchal tree-like structure. In the Zimbra system, the structure is arranged based on Internet domain names. LDAP entries typically include items such as user accounts, organizations, or servers.

Figure 5 shows the Zimbra LDAP hierarchy. Each type of entry (object) has certain associated object classes.

For a complete listing of the Zimbra auxiliary object classes, see the Zimbra LDAP Schema.

Every LDAP implementation has a schema that defines its domain structure, account attributes, and other data structures in use by the organization. Zimbra includes a custom LDAP schema that extends the generic schema included with OpenLDAP software and is designed to potentially coexist with existing directory installations. The Zimbra server, the Zimbra administration console, the command-line account provisioning, and the management utilities require the Zimbra schema.

All attributes and object classes specifically created for Zimbra are prefaced by "zimbra”, as in zimbraMailRecipient object class or the zimbraAttachmentsBlocked attribute.

The Zimbra schema assumes a baseline schema. In the OpenLDAP installer package included with the Zimbra system, the following schema files are included in the OpenLDAP implementation:

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 method 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.

Two additional domain attributes are required for the external mechanism: zimbraAuthLdapURL and zimbraAuthLdapBindDn.

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.

ldap://server1:389
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.

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:

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

Zimbra uses auxiliary object classes to add Zimbra-specific attributes to existing objects such as an account. The LDAP objects used in Zimbra include the following:

An account object represents an account on the Zimbra mailbox server that can be logged into. Account entrees are either administrators or user accounts that can be logged into. The object class name is zimbraAccount. This object class extends the zimbraMailRecipient object class.

The object class zimbraMailRecipient is a directory entry that represents an entity that can receives mail. This is a visible external mail address that is expanded through aliases or forwarding into one or more internal/external addresses.

All accounts have the following properties:

All user accounts are associated with a domain, so a domain must be created before creating any accounts.

For more about account provisioning, see the Managing User Accounts.

Class of Service is a Zimbra-specific object that defines the default attributes an email account has and what features are added or denied. The COS controls features, default preference settings, mailbox quotas, message lifetime, password restrictions, attachment blocking and server pools for creation of new accounts. The object class name is zimbraCOS.

Each account is assigned a class of service. COS is used to group accounts and define the feature levels for those accounts. For example, executives can be assigned to a COS that allows the Calendar application. By grouping accounts into specific type of COS, account features can be updated in block.

If the COS is not explicitly set, or if the COS assigned to the user no longer exists, values come from a pre-defined COS called "default”.

A COS is not restricted to a particular domain or set of domains.

A Domains object represents an email domain such as ace.com or zink.org. A domain must exist before email addressed to users in that domain can be delivered. The object class name is zimbraDomain.

Distribution Lists, also known as mailing lists, are used to send mail to all members of a list by sending a single email to the list address. The object class name is zimbraDistributionList.

Recipient object represents an entity that can receive mail. An external email address exists, and the recipient can be expanded through aliases or forwarding into one or more internal/external addresses. The object class name is zimbraMailRecipient. This object class name is only used in conjunction with zimbraAccount and zimbraDistributionlist classes.

The servers object represents a particular server in the Zimbra system that has one or more of the Zimbra software packages installed. During the installation, the software is automatically registered on the OpenLDAP server. The object class name is zimbraServer. Attributes describe server configuration information, such as which services are running on the server.

The server name is used by the Zimbra system to make a request for the server object in the directory. The server requested gets its configuration information and picks up any changes that might have been made by the administrator through the Zimbra Administrator Console.

The Global Configuration object specifies default values for the following objects: server, account, COS, and domain. If the attributes are not set for other objects, the values are inherited from the global settings. The object class name is zimbraGlobalConfig.

Global configuration values are required and are set during installation as part of the Zimbra core package. These become the default values for the system.

CalendarResource object defines a calendar resource such as conference rooms or equipment that can be selected for a meeting. The object class name is zimbraCalendarResource.

A company directory is a company-wide listing of users, usually within the organization itself, that is available to all users of the email system. Sometimes called "white pages” or global address list (GAL), Zimbra uses the company directory to look up user addresses from within the company.

For each domain used in Zimbra, you can choose from the following GAL search options:

The Zimbra client can search the GAL. The GAL search returns a list of directory entries that match the user’s search.

When the user supplies a name to search for, that name is turned into an LDAP search filter similar to the following example:

The string "%s” is replaced with the name the user is searching for.

Two possible sources for GAL information are the Zimbra server and the Active Directory server. The relevant LDAP/Active Directory fields are referenced in the Zimbra schema under the same names as listed in the Active Directory schema.

Table 1 maps generic GAL search attributes to their Zimbra contact fields.

Table 1 Attributes Mapped to Zimbra contact
Standard LDAP Attribute	Zimbra Contact Field
co	workCountry
company	Company
givenName/gn	firstName
sn	lastName
cn	fullName
initials	initials
l	workCity
physicalDeliveryOfficeName	office
ou	department
street, streetaddress	workStreet
postalCode	workPostalCode
telephoneNumber	workPhone
st	workState
title	jobTitle
mail	email
objectClass	Not currently mapped

Like authentication, GAL is configured on a per-domain basis. From the administration console, you can run the GAL Configuration Wizard to configure the domain’s attributes.

The OpenLDAP directory should not be modified directly. Any additions, changes and deletions are made through the Zimbra administration console or from the CLI utility for provisioning, zmprov.