LDAP: Difference between revisions

 
(71 intermediate revisions by 21 users not shown)
Line 1: Line 1:
{{BC|Community Sandbox}}
__FORCETOC__
<div class="col-md-12 ibox-content">
=LDAP=
{{KB|{{Unsupported}}|{{ZCS 8.0}}|{{ZCS 7.0}}|}}
{{WIP}}
== [[LDAP]] Overview ==
== [[LDAP]] Overview ==
=== [[LDAP]] uses in ZCS ===
=== [[LDAP]] uses in ZCS ===
[[LDAP]] is used in [[ZCS]] to store data for
[[LDAP]] is used in ZCS to store data for


* [[Global configuration]]
* Global configuration
* [[User|USER]] and [[Authentication]]
* USER and Authentication
* [[Server|SERVER]]
* SERVER
* [[Domain|DOMAIN]]
* DOMAIN
* [[COS]]
* COS


Additionally, information relating to:
Additionally, information relating to:
* External [[LDAP Authentication]]
* External [[LDAP Authentication]]
* [[External GAL]]
* External GAL


Most of this data can be viewed and configured via the [[Admin Console]] or with [[zmprov]].
Most of this data can be viewed and configured via the [[:Category:Administration|Admin Console]] or with [[zmprov]].


=== [[LDAP]] in the system architecture ===
=== [[LDAP]] in the system architecture ===
Line 24: Line 30:
== [[LDAP]] troubleshooting ==
== [[LDAP]] troubleshooting ==


==="no objectClass attribute" and "index_param failed" warnings in zimbra.log===
You may see lines like below in /var/log/zimbra.log. Lines are informational, reporting that certain attributes are not indexed. This is not a problem. This logging has been removed for ZCS 4.5.7 and later.
Aug 29 19:07:22 host slapd[30824]: is_entry_objectclass("", "2.5.6.1") no objectClass attribute
Aug 29 19:07:22 host slapd[30824]: <= bdb_equality_candidates: (zimbraDomainType) index_param failed (18)
=== Installation Problems ===
If you're seeing '''ERROR: service.FAILURE (system failure: getDirectContext) (cause: javax.naming.CommunicationException localhost.localdomain:389)''' on installation, you're in the right place.
If you're seeing '''ERROR: service.FAILURE (system failure: getDirectContext) (cause: javax.naming.CommunicationException localhost.localdomain:389)''' on installation, you're in the right place.


=== Installation Problems ===


[[LDAP]] initialization generally fails due to the following
[[LDAP]] initialization generally fails due to the following
Line 46: Line 58:


==== Detecting startup failure ====
==== Detecting startup failure ====
After the initialization script exits (successfully or otherwise) [[slapd]] should be running.  To verify that the [[slapd]] process is running:
After the initialization script exits (successfully or otherwise) slapd should be running.  To verify that the slapd process is running:


   <tt>ps auxww | grep zimbra | grep slapd</tt>
   <tt>ps auxww | grep zimbra | grep slapd</tt>
Line 61: Line 73:
is successful.
is successful.


If you get no such response from the <tt>ldap status</tt> command, it's likely that the running [[slapd]] process is hanging around from a previous installation.  To kill it manually:
If you get no such response from the <tt>ldap status</tt> command, it's likely that the running slapd process is hanging around from a previous installation.  To kill it manually:


   <tt>killall -TERM slapd</tt>
   <tt>killall -TERM slapd</tt>
Line 68: Line 80:
   <tt>kill -9 ''PID''</tt>
   <tt>kill -9 ''PID''</tt>


After cleaning up old [[LDAP]] processes, you should re-attempt the initialization by re-running [[zmsetup.pl]]
After cleaning up old [[LDAP]] processes, you should re-attempt the initialization by re-running zmsetup.pl.


==== Ubuntu 6.10 LDAP Startup Solution ====
==== Ubuntu 6.10 LDAP Startup Solution ====
Line 126: Line 138:
== Integration with external [[LDAP]] servers ==
== Integration with external [[LDAP]] servers ==
=== External Authentication ===
=== External Authentication ===
Please see [[King0770-Notes#External_Authentication_with_LDAP]] for information on this.
=== External GAL ===
=== External GAL ===
== Connecting to an external LDAP server with SSL ==
== Connecting to an External LDAP Server with SSL ==
 
If the external LDAP server has a self-signed certificate, you will need to add the cert to the Zimbra keystore(s). Use the following command (substitute your chosen alias and the path to your cert file; all on one line):


If the external ldap server has a self-signed certificate, you will need to add the cert to the zimbra tomcat keystore(s). Use the following command (substitute your chosen alias and the path to your cert file; all on one line):
<pre>
sudo /opt/zimbra/java/bin/keytool -import \
  -alias EXTERNAL-LDAP \
  -keystore /opt/zimbra/java/jre/lib/security/cacerts \
  -storepass changeit \
  -file EXTERNAL-LDAP-CERT-FILE
</pre>


<tt>
After adding the cert to the keystore, you'll need to restart Tomcat.  As the zimbra user, do this:
:keytool -import -alias EXTERNAL-LDAP -keystore /opt/zimbra/java/jre/lib/security/cacerts -storepass changeit -file EXTERNAL-LDAP-CERT-FILE
<pre>
</tt>
tomcat stop && tomcat start
</pre>


Make sure that you have selected SSL when configuring use of the external ldap server in the admin console. You can verify on the command line that this returns an "ldaps" url:
Make sure that you have selected SSL when configuring use of the external ldap server in the admin console. You can verify on the command line that this returns an "ldaps" url:
Line 146: Line 170:


You just have to clean the resulting file a bit...
You just have to clean the resulting file a bit...
===Find out if your external auth cert had expired===
If your users cannot access their accounts from the web-client, check to see if the external authentication server's ssl cert expired.<br>
If the external authentication's ssl cert expired, you may see errors in the /opt/zimbra/log/mailbox.log file.
<tt>
'''Caused by: javax.naming.CommunicationException: simple bind failed: 192.168.2.15:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed]'''
</tt>
To check to see the the external authentication's ssl cert expired, run the following commands:
<code><pre>
openssl s_client -connect EXTERNAL-LDAP:636 > EXTERNAL-LDAP-CERT-FILE.crt
openssl x509 -in EXTERNAL-LDAP-CERT-FILE.crt -noout -text
</pre></code>
Near the top of the output, you should see Validity dates.<br>
Example:<br>
Not Before: Apr 23 13:54:47 2008 GMT<br>
Not After : Apr 23 13:54:47 2009 GMT<br>
Tip: For a short-term workaround, set localconfig key '''''ssl_allow_untrusted_certs''''' to ''true'' from ''false''.
<pre>zmlocalconfig -e ssl_allow_untrusted_certs=true</pre>


== Provisioning users in [[LDAP]] ==
== Provisioning users in [[LDAP]] ==
Line 154: Line 203:
   [[zmprov]] ca ''username@domain'' ''password'' ''attribute'' ''value'' ''attribute'' ''value''
   [[zmprov]] ca ''username@domain'' ''password'' ''attribute'' ''value'' ''attribute'' ''value''


For creation of a single user, the [[admin console]] is the preferred method.  If you need to bulk provision users, during initial installation, it can be easier to create a script.
For creation of a single user, the admin console is the preferred method.  If you need to bulk provision users, during initial installation, it can be easier to create a script.


EXAMPLE - creating several users at once:
EXAMPLE - creating several users at once:
Line 178: Line 227:
=== Installation ===
=== Installation ===
Your [[LDAP]] Master server (machine 1) should be installed using normal ZCS installation options. The replica will be installed on a separate server (machine 2).
Your [[LDAP]] Master server (machine 1) should be installed using normal ZCS installation options. The replica will be installed on a separate server (machine 2).
=== Replica Configuration ===
After the master server is up, enable replication on the '''master''' with the command <tt>/opt/zimbra/libexec/zmldapenablereplica</tt>
===Install Replica Server===


To install the replica server:
To install the replica server:
* Make sure the master is up and running before you apply the configuration to machine 2 and complete the installation.  
* Make sure the master is up and running before you apply the configuration to machine 2 and complete the installation.  
* Use standard install.sh options, including the zimbra-ldap server.
* Use standard install.sh options, including the zimbra-ldap server.
* Set the zimbra-ldap server to DISABLED. This is very important, as if you leave it set to Enabled, it will just create a new directory server and you'll have two separate mail systems.
* Set the master [[LDAP]] server for machine 2 to be machine 1.
* Set the master [[LDAP]] server for machine 2 to be machine 1.
* Set the master [[LDAP]] password to the correct value (run zmlocalconfig -s ldap_root_password on the master to determine this value)
* Set the [[LDAP]]root password to the correct value (run zmlocalconfig -s ldap_root_password on the master to determine this value)
* Set the [[LDAP]] replication password to the correct value (run zmlocalconfig -s ldap_replication_password on the master to determine this value)
* Installation will complete as normal, and both servers will have their ZCS servers up, except for slapd on machine 2.
* Installation will complete as normal, and both servers will have their ZCS servers up, except for slapd on machine 2.
'''''Note:''' In order to install an LDAP replica server with no MBS (Mailbox Server), set '''zimbra_zmprov_default_to_ldap''' to '''true''', using the following command: '''zmlocalconfig -e zimbra_zmprov_default_to_ldap=true'''. If you later add an MBS to your LDAP replica server, set '''zimbra_zmprov_default_to_ldap''' to '''false.'''''


If you want to install an [[LDAP]] replica on a previously existing Zimbra server, you will need to use install.sh to install zimbra-ldap on the server.  When install.sh asks if you wish to perform an upgrade, select Yes, then select Yes when it asks to install zimbra-ldap.  The rest of the install will be similar to installing a disabled [[LDAP]] server on a new box.
If you want to install an [[LDAP]] replica on a previously existing Zimbra server, you will need to use install.sh to install zimbra-ldap on the server.  When install.sh asks if you wish to perform an upgrade, select Yes, then select Yes when it asks to install zimbra-ldap.  The rest of the install will be similar to installing a disabled [[LDAP]] server on a new box.
=== Replica Configuration ===
After the servers are up, you need to set up a few things before
the replica can be brought up.
* Enable replication on the '''master''' with the command <tt>/opt/zimbra/libexec/zmldapenablereplica</tt>
* Run <tt>/opt/zimbra/libexec/zmldapenablereplica</tt> on the '''replica'''. This will set up the replication account in the directory and will make a copy of the '''master''' on the '''replica'''. This should run cleanly.
* You may have to run zmcreatecert on machine 2 to create the conf/slapd.crt file. Just run it with no command line options.  If this file is not present, slapd will not start.


When this is complete, you're done. You can test the replica by creating a few accounts
When this is complete, you're done. You can test the replica by creating a few accounts
Line 201: Line 249:
immediately with an [[LDAP]] search run against machine 2.
immediately with an [[LDAP]] search run against machine 2.


Increasing the [[LDAP]] logging level from 0 to 1 on the replica will allow you to see replication activity as wellTo enable, run:
[[LDAP]] logging will appear in /var/log/zimbra.logIt is recommended this setting be enabled only for testing and troubleshooting.
[[zmlocalconfig]] -e ldap_log_level=1
ldap stop; ldap start


[[LDAP]] logging will appear in /var/log/zimbra.log. It is recommended this setting be enabled only for testing and troubleshooting.
===Running LDAP replica===
Any services running on the '''replica''' server itself will automatically query the '''replica''' first.)
 
The order for the <tt>ldap_url</tt> key on the hosts using the '''replica''' should be '''replicas''' first, with the '''master''' listed last.  The '''master''' must always be included!
 
== Promoting LDAP Replica to be LDAP Master ==
To see instructions for promoting a replica to LDAP master, go to [[Promoting_Replica_to_LDAP_Master]].  This procedure shows how to move the [[LDAP]] Master from one host to another.  This is not recommended for use by those without at least some LDAP expertise.
 
 
== LDAP Logs ==
For /var/log/zimbra.log
 
===Change Levels===
There are two methods.<br>
 
1)<br>
 
<code><pre>
 
zmlocalconfig -e ldap_log_level=256
 
ldap stop
 
ldap start
 
</pre></code>
 
2)<br>
 
<code><pre>
**this method does not require ldap stop/start**
 
ldapmodify -x -h <host> -D "cn=config" -W <hit enter>
<enter ldap_root_password>
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: 256 **if you want to disable ldap log, type in 'none'**
<enter> <enter>
 
</pre></code>
 
 
 
=== Levels ===
<pre>
Default: 32768 (OR 0x8000 OR none) would just log critical stuff
 
zmlocalconfig -e ldap_log_level=32768
zmcontrol stop/start
 
Note that in ZCS 6+ ldap_log_level has been replaced by ldap_common_loglevel.
 
We tried 16640 = stats + sync for a few releases and found it overhwelming - but it's good for debug.
 
LDAP
Master: 32768 none (critical only)
Replicas: 49152 = none + sync = 32768 + 16384 (no stats but syncrepl entries
are logged)
 
For instance to set that replica value it would be:
zmlocalconfig -e ldap_log_level=49152
OR
zmlocalconfig -e ldap_log_level="none sync"
 
You can define it several ways (single interger in decimal or hexadecimal, or keywords) and then you can combine them - for instance these are equivalent:
loglevel 129
loglevel 0x81
loglevel 128 1
loglevel 0x80 0x1
loglevel acl trace
 
hexadecimal <> decimal conversion tool
 
The keyword any can be used as a shortcut to enable logging at all levels (equivalent to -1).
 
The keyword none, or the equivalent integer representation (32768 or 0x800), causes those messages that are always logged regardless of the configured loglevel to be output (specified & critical stuff). In fact, if no loglevel (or a 0 level) is defined, no logging occurs, so at least the none level is required to have high priority messages logged.


=== Using the Replica ===
In short, 32768 (OR 0x8000 OR none) = only messages that get logged whatever log level is set, thus you get critical stuff.
To use the '''replica''' [[LDAP]] server after you've tested it, you now need to update the ldap_url value on the Zimbra servers you wish to have query the '''replica''' instead of the '''master'''. (Any services running on the '''replica''' server itself will automatically query the '''replica''' first.)
</pre>


Use the ldap_url value set on the replica server as a template value (zmlocalconfig ldap_url). For each server you want to change:
== ZCS 6.0+ ==
* Stop the zimbra services on that server
<pre>
* Update the ldap_url value (zmlocalconfig -e ldap_url="url url url") (quotes needed because of the space)
When the GnR ZCS 6.0 release comes out, our entire OL setup has changed with our move to OpenLDAP 2.4.
* Then start the services again


The order for the <tt>ldap_url</tt> key on the hosts using the '''replica''' should be '''replicas''' first, with the '''master''' listed last.  The '''master''' must always be included!


== Moving an [[LDAP]] Master ==
OpenLDAP DB is now in /opt/zimbra/data/ldap/{config,hdb,accesslog}/
This procedure shows how to move the [[LDAP]] Master from one host to another.  This is not recommended for use by those without at least some LDAP expertise, and could result in trouble for your system.  It should be performed only if it is necessary to move the Master [[LDAP]] server from its current server to another.


To move the master [[LDAP]] directory:
We've moved to using the cn=config backend rather than text files for configuration. This means that any changes made to the configuration
* Create a replica on the machine that will become the new master using the instructions from [[LDAP#LDAP replication|LDAP Replication]].
database are preserved across restarts and upgrades. As a part of this, I've made it so many more portions of the OL configuration can be
* Start services on all servers and ensure that the replica is picking up [[LDAP]] updates from the master.
controlled (See bug#20972).  This means that sites will no longer have to modify slapd.conf by hand every release for changes they want to see
* If everything is running correctly, shut down all servers again.
persist. In particular, note that ldap_log_level is no longer an LC key, it has been replaced by ldap_common_loglevel.
* On the new [[LDAP]] master, make a backup copy of $ZIMBRA_HOME/conf/slapd.conf.in.  Remove the replication-related lines at the end of the file.  This will be everything below TLSCACertificateFile /opt/zimbra/conf/ca/ca.pem.
* Edit zmlocalconfig on all hosts so that ldap_master_url and ldap_url now point to the new directory master.
* Edit zmlocalconfig on the new directory master so that ldap_is_master is set to true.
* Edit zmlocalconfig on the old directory master so that ldap_is_master is set to false.
* Start up services on all servers, starting with the new directory master.


At this point, services should be up and running on all hosts, and they should all be working off the new [[LDAP]] master.  The old [[LDAP]] master can be disabled, or it can be converted into a replica by shutting it down, removing the contents of its openldap-data directory, and running zmldapenablereplica.
Modfications to the ldap_{commmon,db,accesslog,overlay}_* LC keys are monitored by zmmtaconfig, and will push the those changes to the LDAP
server within 2 minutes or less.  This means easy on-the-fly loglevel changes, for example.  A few options (ldap_common_require_tls) currently
require a restart to take effect, but may not in the future.  Some (ldap_common_threads) always will.
</pre>
{{Article Footer|Zimbra Collaboration 8.0, 7.0|04/16/2014}}
[[Category:Architecture and Components]]
[[Category:LDAP]]
[[Category:Pending Certification]]

Latest revision as of 05:11, 17 May 2018

LDAP

   KB 1308        Last updated on 2018-05-17  




0.00
(0 votes)

LDAP Overview

LDAP uses in ZCS

LDAP is used in ZCS to store data for

  • Global configuration
  • USER and Authentication
  • SERVER
  • DOMAIN
  • COS

Additionally, information relating to:

Most of this data can be viewed and configured via the Admin Console or with zmprov.

LDAP in the system architecture

In every ZCS installation, there will be one and only one Master LDAP server. This server is authoritative for user information, server configuration, etc.

Additionally, one or more Replicas may be defined, to improve performance and reduce the load on the Master.

During installation in a multi-server environment, the LDAP server must be the first installed and configured, and must be running during any subsequent installations. The LDAP server must also be the first started in a multi-server environment.

LDAP troubleshooting

"no objectClass attribute" and "index_param failed" warnings in zimbra.log

You may see lines like below in /var/log/zimbra.log. Lines are informational, reporting that certain attributes are not indexed. This is not a problem. This logging has been removed for ZCS 4.5.7 and later.

Aug 29 19:07:22 host slapd[30824]: is_entry_objectclass("", "2.5.6.1") no objectClass attribute
Aug 29 19:07:22 host slapd[30824]: <= bdb_equality_candidates: (zimbraDomainType) index_param failed (18)

Installation Problems

If you're seeing ERROR: service.FAILURE (system failure: getDirectContext) (cause: javax.naming.CommunicationException localhost.localdomain:389) on installation, you're in the right place.


LDAP initialization generally fails due to the following

  • Failure to start the LDAP server
  • Failure to resolve the LDAP server
  • Failure to connect to the LDAP server

Startup failures

The startup of the LDAP server during installation happens when the initialization script calls the ldap start script.

If this startup fails, all further initialization fails.

If you see something like the following when upgrading, verify that the sudoers file contains the proper allowances for the zimbra user.

[zimbra@mailhost ~]$ zmcontrol start
Host mailhost.domain.com
        Starting ldap...Password:


Detecting startup failure

After the initialization script exits (successfully or otherwise) slapd should be running. To verify that the slapd process is running:

 ps auxww | grep zimbra | grep slapd
 Should return a line containing:
 /opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldaps:// ldap://:389/ -f /opt/zimbra/conf/slapd.conf

If there is no output, LDAP is not starting. See the next section

If this line is present, verify that the zimbra system is detecting it (run as the zimbra user):

 ldap status

A return of:

 slapd running pid: 7568  (your PID will vary)

is successful.

If you get no such response from the ldap status command, it's likely that the running slapd process is hanging around from a previous installation. To kill it manually:

 killall -TERM slapd
 ps auxww | grep zimbra | grep slapd

If the process is still there, determine it's PID (second column in the ps output) and

 kill -9 PID

After cleaning up old LDAP processes, you should re-attempt the initialization by re-running zmsetup.pl.

Ubuntu 6.10 LDAP Startup Solution

This applies to running the Debian build on Ubuntu, not the Ubuntu build

If you are getting the dreaded:

LDAP startup ... FAILED (256) on UBUNTU, I solved my problems with 2 changes:

1 UBUNTU by default symlinks /bin/sh to /bin/dash which does not support the 'source' command.

    To fix
         rm /bin/sh
         ln -s bash /bin/sh

2 UBUNTU Server distro does not have a Java runtime, the certification startup

    The zimbra installer requires the java runtime in the /jre directory.  
    Zimbra has a JRE available so simply a second symlink will solve the problem
    To fix:
          ln -s /opt/zimbra/jdk1.5.0_08/jre /jre

Correcting startup failure

If the previous section indicates that ldap is not starting at all, attempt ldap startup manually (as the zimbra user);

 sh -x bin/ldap start

output from this should indicate the source of the problem

The problem may not be indicated in the command above. Instead, you should check your syslog, for logs originating from local0.

An alternative method is to execute the command executed by "ldap start", in my case, this was:

sudo /opt/zimbra/openldap-2.3.21/libexec/slapd -d7 -l LOCAL0 -4 -u zimbra -h ldap://localhost:389/ -f /opt/zimbra/conf/slapd.conf

Note the -d7 in the middle is used to troubleshoot and read debug logs on the screen.

LDAP and DNS

LDAP uses DNS to resolve the ldap host, even if it's localhost

To verify that you're able to resolve the ldap host:

host ldap-hostname

Make sure you understand DNS.

Failure to Connect

To detect connection failure (using the hostname configured for the ldap server):

 telnet ldaphostname 389

If this times out, or the connection is refused, there could be several causes.

If resolution succeeds, the initialization may fail because the LDAP server failed to start

Firewall problems

If the server is running a local firewall, make sure it's allowing port 389 connections.

If the ldap hostname resolves to a public IP on an external firewall, make sure that firewall is allowing connections through on port 389.

Integration with external LDAP servers

External Authentication

Please see King0770-Notes#External_Authentication_with_LDAP for information on this.

External GAL

Connecting to an External LDAP Server with SSL

If the external LDAP server has a self-signed certificate, you will need to add the cert to the Zimbra keystore(s). Use the following command (substitute your chosen alias and the path to your cert file; all on one line):

sudo /opt/zimbra/java/bin/keytool -import \
  -alias EXTERNAL-LDAP \
  -keystore /opt/zimbra/java/jre/lib/security/cacerts \
  -storepass changeit \
  -file EXTERNAL-LDAP-CERT-FILE

After adding the cert to the keystore, you'll need to restart Tomcat. As the zimbra user, do this:

tomcat stop && tomcat start

Make sure that you have selected SSL when configuring use of the external ldap server in the admin console. You can verify on the command line that this returns an "ldaps" url:

zmprov gd DOMAIN.COM | grep zimbraAuthLdapURL

PS : in order to download the certificate, you can use openssl from the zimbra server :

openssl s_client -connect EXTERNAL-LDAP:636 > EXTERNAL-LDAP-CERT-FILE

You just have to clean the resulting file a bit...

Find out if your external auth cert had expired

If your users cannot access their accounts from the web-client, check to see if the external authentication server's ssl cert expired.

If the external authentication's ssl cert expired, you may see errors in the /opt/zimbra/log/mailbox.log file.

Caused by: javax.naming.CommunicationException: simple bind failed: 192.168.2.15:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed]

To check to see the the external authentication's ssl cert expired, run the following commands:

openssl s_client -connect EXTERNAL-LDAP:636 > EXTERNAL-LDAP-CERT-FILE.crt

openssl x509 -in EXTERNAL-LDAP-CERT-FILE.crt -noout -text

Near the top of the output, you should see Validity dates.
Example:
Not Before: Apr 23 13:54:47 2008 GMT
Not After : Apr 23 13:54:47 2009 GMT

Tip: For a short-term workaround, set localconfig key ssl_allow_untrusted_certs to true from false.

zmlocalconfig -e ssl_allow_untrusted_certs=true

Provisioning users in LDAP

The basic form for this is:

 zmprov ca username@domain password 

Additional attributes can be specified on the same command:

 zmprov ca username@domain password attribute value attribute value

For creation of a single user, the admin console is the preferred method. If you need to bulk provision users, during initial installation, it can be easier to create a script.

EXAMPLE - creating several users at once:

Create a file containing all of the zmprov commands that you wish to run:

 ca user1 user1pass
 ca user2 user2pass
 ca user3 user3pass
 ca adminuser adminuserpass zimbraIsAdminAccount TRUE
 ca user4 user4pass zimbraMailAlias user_4 zimbraMailAlias user_four zimbraMailAlias user.four
 ca nopassuser 

Save this file (eg, usercreate.txt ). Then, run zmprov, redirecting standard input from this file:

 zmprov < usercreate.txt

With this method, it's relatively straightforward to dump an existing ldap directory into a text file, format it for zmprov, and bulk-provision the users in the ZCS LDAP instance.

If you are using external LDAP authentication you can create the users with no local password by supplying the empty string "" after the username

LDAP replication

Installation

Your LDAP Master server (machine 1) should be installed using normal ZCS installation options. The replica will be installed on a separate server (machine 2).

Replica Configuration

After the master server is up, enable replication on the master with the command /opt/zimbra/libexec/zmldapenablereplica

Install Replica Server

To install the replica server:

  • Make sure the master is up and running before you apply the configuration to machine 2 and complete the installation.
  • Use standard install.sh options, including the zimbra-ldap server.
  • Set the master LDAP server for machine 2 to be machine 1.
  • Set the LDAProot password to the correct value (run zmlocalconfig -s ldap_root_password on the master to determine this value)
  • Set the LDAP replication password to the correct value (run zmlocalconfig -s ldap_replication_password on the master to determine this value)
  • Installation will complete as normal, and both servers will have their ZCS servers up, except for slapd on machine 2.

Note: In order to install an LDAP replica server with no MBS (Mailbox Server), set zimbra_zmprov_default_to_ldap to true, using the following command: zmlocalconfig -e zimbra_zmprov_default_to_ldap=true. If you later add an MBS to your LDAP replica server, set zimbra_zmprov_default_to_ldap to false.

If you want to install an LDAP replica on a previously existing Zimbra server, you will need to use install.sh to install zimbra-ldap on the server. When install.sh asks if you wish to perform an upgrade, select Yes, then select Yes when it asks to install zimbra-ldap. The rest of the install will be similar to installing a disabled LDAP server on a new box.

When this is complete, you're done. You can test the replica by creating a few accounts through the administrative interface on the master server. You should be able to see them immediately with an LDAP search run against machine 2.

LDAP logging will appear in /var/log/zimbra.log. It is recommended this setting be enabled only for testing and troubleshooting.

Running LDAP replica

Any services running on the replica server itself will automatically query the replica first.)

The order for the ldap_url key on the hosts using the replica should be replicas first, with the master listed last. The master must always be included!

Promoting LDAP Replica to be LDAP Master

To see instructions for promoting a replica to LDAP master, go to Promoting_Replica_to_LDAP_Master. This procedure shows how to move the LDAP Master from one host to another. This is not recommended for use by those without at least some LDAP expertise.


LDAP Logs

For /var/log/zimbra.log

Change Levels

There are two methods.

1)


zmlocalconfig -e ldap_log_level=256

ldap stop

ldap start

2)

**this method does not require ldap stop/start**

ldapmodify -x -h <host> -D "cn=config" -W <hit enter>
<enter ldap_root_password>
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: 256 **if you want to disable ldap log, type in 'none'**
<enter> <enter>


Levels

Default: 32768 (OR 0x8000 OR none) would just log critical stuff

zmlocalconfig -e ldap_log_level=32768
zmcontrol stop/start

Note that in ZCS 6+ ldap_log_level has been replaced by ldap_common_loglevel.

We tried 16640 = stats + sync for a few releases and found it overhwelming - but it's good for debug.

LDAP
Master: 32768 none (critical only)
Replicas: 49152 = none + sync = 32768 + 16384 (no stats but syncrepl entries
are logged)

For instance to set that replica value it would be:
zmlocalconfig -e ldap_log_level=49152
OR
zmlocalconfig -e ldap_log_level="none sync"

You can define it several ways (single interger in decimal or hexadecimal, or keywords) and then you can combine them - for instance these are equivalent:
loglevel 129
loglevel 0x81
loglevel 128 1
loglevel 0x80 0x1
loglevel acl trace

hexadecimal <> decimal conversion tool

The keyword any can be used as a shortcut to enable logging at all levels (equivalent to -1).

The keyword none, or the equivalent integer representation (32768 or 0x800), causes those messages that are always logged regardless of the configured loglevel to be output (specified & critical stuff). In fact, if no loglevel (or a 0 level) is defined, no logging occurs, so at least the none level is required to have high priority messages logged.

In short, 32768 (OR 0x8000 OR none) = only messages that get logged whatever log level is set, thus you get critical stuff.

ZCS 6.0+

When the GnR ZCS 6.0 release comes out, our entire OL setup has changed with our move to OpenLDAP 2.4.


OpenLDAP DB is now in /opt/zimbra/data/ldap/{config,hdb,accesslog}/

We've moved to using the cn=config backend rather than text files for configuration.  This means that any changes made to the configuration
database are preserved across restarts and upgrades.  As a part of this, I've made it so many more portions of the OL configuration can be
controlled (See bug#20972).  This means that sites will no longer have to modify slapd.conf by hand every release for changes they want to see
persist.  In particular, note that ldap_log_level is no longer an LC key, it has been replaced by ldap_common_loglevel.

Modfications to the ldap_{commmon,db,accesslog,overlay}_* LC keys are monitored by zmmtaconfig, and will push the those changes to the LDAP
server within 2 minutes or less.  This means easy on-the-fly loglevel changes, for example.  A few options (ldap_common_require_tls) currently
require a restart to take effect, but may not in the future.  Some (ldap_common_threads) always will.
Verified Against: Zimbra Collaboration 8.0, 7.0 Date Created: 04/16/2014
Article ID: https://wiki.zimbra.com/index.php?title=LDAP Date Modified: 2018-05-17



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Jump to: navigation, search