LDAP Architecture: Difference between revisions
Line 26: | Line 26: | ||
=== OpenLDAP and MDB (ZCS8 and later) === | === OpenLDAP and MDB (ZCS8 and later) === | ||
== LDAP and Authentication == | == LDAP and Authentication == | ||
By default, Zimbra authenticates users against their user entry stored in LDAP via a custom Zimbra Authentication module. However, it is possible to configure Zimbra to authenticate users through an external directory server instead. | By default, Zimbra authenticates users against their user entry stored in LDAP via a custom Zimbra Authentication module. However, it is possible to configure Zimbra to authenticate users through an external directory server instead. Authentication is done any time it is necessary to validate the identity of the user. Some locations requiring authentication: | ||
* Web client login | |||
* POP connections | |||
* IMAP connections | |||
* SMTP(S) connections | |||
== OpenLDAP and Nginx == | == OpenLDAP and Nginx == |
Revision as of 21:29, 21 November 2013
Article Information |
---|
This article applies to the following ZCS versions. |
Zimbra LDAP Architecture
Zimbra uses OpenLDAP as one of its primary datastores. The LDAP database is used to store a wide variety of data, including but not limited to:
* Server configuration pieces * Software configuration pieces * User data * COS data
OpenLDAP Internals
OpenLDAP and BDB (ZCS7 and previous)
In ZCS 7 and prior releases, OpenLDAP uses Berkeley Database (BDB) as the storage engine. OpenLDAP has two database backends that rely on BDB, back-bdb and back-hdb. Zimbra uses the back-hdb backend due to its superior performance profile to back-bdb. There are a number of tuning pieces necessary to get optimal performance when using either back-bdb or back-hdb. Detailed specifics on tuning are documented at [OpenLDAP performance tuning for ZCS 7]. Here we will give an overview of the different pieces.
OpenLDAP Caches
Unfortunately, reading data directly out of the BDB database is quite slow. To work around this limitation, the OpenLDAP server process has 3 caches per BDB database that can be configured to hold data directly in memory while the process is running so that they do not have to be constantly pulled out of the BDB database. The larger the settings, the greater the total memory requirements for the slapd process. Caches release entries based on the [CLOCK Algorithm] These caches are:
- Entry cache -- This caches full entries up to the configured maximum in memory
- IDL cache -- This caches the results of the most frequent indexed queries in memory
- DN cache -- This caches the entry DNs for the entries in the database in memory. This should be left at unlimited if at all possible.
- Cache free -- This setting determines how many entries will be freed from a cache if its maximum size is less than the size of the entire database
BDB Caches
BDB operates with a BDB specific caching layer between the database and any application using BDB. This caching layer can either be on-disk or stored in memory via [Shared Memory]. For optimal performance, it is recommended to use a Shared Memory Key. For OpenLDAP, this has the largest impact on performance.
OpenLDAP and MDB (ZCS8 and later)
LDAP and Authentication
By default, Zimbra authenticates users against their user entry stored in LDAP via a custom Zimbra Authentication module. However, it is possible to configure Zimbra to authenticate users through an external directory server instead. Authentication is done any time it is necessary to validate the identity of the user. Some locations requiring authentication:
- Web client login
- POP connections
- IMAP connections
- SMTP(S) connections
OpenLDAP and Nginx
In the majority of installations, Nginx does not access LDAP directly. However, when cert auth or a SASL mechanism such as GSSAPI are used, nginx will auth against LDAP to log into the upstream server.
OpenLDAP and MTA
OpenLDAP and Postfix
OpenLDAP and Amavis
OpenLDAP and MBS