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

Zimbra LDAP Service > Directory Services Overview

Directory Services Overview
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.
The following figure 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 Zimbra clients connect through the Zimbra server, which in turn connects to LDAP.
LDAP Directory Traffic
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.
LDAP Hierarchy
LDAP directories are arranged in an hierarchal tree-like structure with two types of branches, the mail branches and the config branch. Mail branches are organized by domain. Entries belong to a domain, such as accounts, groups, aliases, are provisioned under the domain DN in the directory. The config branch contains admin system entries that are not part of a domain. Config branch entries include system admin accounts, global config, global grants, COS, servers, mime types, and zimlets.
The following figure shows the Zimbra LDAP hierarchy. Each type of entry (object) has certain associated object classes.
Zimbra LDAP Hierarchy
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.
An entry’s object class 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. An entry with the structural object class zimbraServer would be a server in the Zimbra system that has one or more Zimbra packages installed.
For a complete listing of the Zimbra auxiliary object classes, see the Zimbra LDAP Schema.
Copyright © 2013 VMware Inc.