Product SiteDocumentation Site

8.5. User Management with LDAP or Active Directory

The Zarafa-server features a system whereby the administrator of a server can specify an LDAP-based server to retrieve user, group and company information. This means that user management can be simplified for installations and standard LDAP administration tools can be used for user management. Also, using an LDAP server makes it possible to integrate Zarafa into an existing environment.
Various LDAP server systems are supported, and Zarafa will communicate with any standard LDAP protocol version 3 or later server. This means Zarafa works in combination with industry-standard solutions as Microsoft Active Directory, OpenLDAP and eDirectory.
This chapter describes loosely how Zarafa uses the LDAP server as a source for user, group, contact and company information. In most cases, the particular setup used will require other options and settings than those described in this document. It is therefore assumed that the reader has a good understanding of how LDAP trees work, and how they are configured in their network.
For more information, please refer to the example configurations and manual pages available on all systems on which Zarafa is installed.

8.5.1. The Zarafa user synchronization principle

In any Zarafa server, there is a database holding the actual data needed while running Zarafa. Apart from the actual folder and item data, the database also holds information on data access rights, user settings, and user meta-data set for users and groups. A lot of this data refers to a specific user ID. For example, an ACL (Access Control List) for the ‘inbox’ for user A will be stored in the database as a record in the ACL table. This record holds the actual access rights for the objects, and the user ID to whom the access control entry has been assigned.
The user ID stated above is therefore a reference to a user ID within the Zarafa database. This ID is stored in the ‘users’ table, along with a reference to the ID of the user in the external user database (in this case, an LDAP server). For example, user ‘A’ may have user ID 5 in the Zarafa system, and may refer to the item (dn=cn=user,dc=example,dc=com) on the LDAP server.
Keeping a list of users in this way also solves the problem of creating the store for a user; There is no way to trigger a store creation event on the Zarafa server whenever a user is added in the LDAP server. The ‘users’ table provides a convenient way to track which users are new to the system and therefore require a new store. The same goes for deleting users, as the user store needs to be removed when the user is deleted.
So, the ‘users’ table in Zarafa is almost exclusively a mapping between the user ID which is used internally in Zarafa, and an external reference to a user in the LDAP database. Naturally, when any new users are added or users are removed from the LDAP server, this table must be kept in-sync with the changes.
There are many ways of keeping the ‘users’ table synchronised with the LDAP server, but Zarafa has chosen by default for a ‘just-in-time’ approach. This means that any time a user is requested from the system, it is first checked in the LDAP server for existence, and then it is checked in the ‘users’ table for existence. If the user does not exist locally on the Zarafa server, then the user is created on-the-fly, before returning the information to the caller.
This means that for users and administrators, the synchronisation seems to be real-time; never will there be a delay between adding or removing users from the LDAP server and the users showing up in Zarafa.
Because all Zarafa components use the same MAPI interface to connect to the server backend, a situation can’t arise with any of the Zarafa tools where the user database is out-of-sync. For example, delivering an email to a user that was just created will never fail due to the user not existing in the Zarafa users table.
To optimise this synchronisation with very large Global Address Books in LDAP, there is a optional setting sync_gab_realtime in the server.cfg configuration file. When this option is set to no there is no real-time synchronisation between the LDAP directory and the Zarafa-server. In this case all Global Address Book entries will be retrieved from the cache of the Zarafa-server. This is especially useful for setups which have large addressbooks (more than 10000 entries in the addressbook).
Synchronisation between the LDAP and Zarafa server need to be forced with the following command:
zarafa-admin --sync
This command can be executed on daily or hourly basis from a cronjob.

8.5.1.1. Add/Remove events

The mechanism above creates a situation in which there are six events that can be signaled:
  • User creation
  • Group creation
  • Company creation
  • User deletion
  • Group deletion
  • Company deletion
These six events can be coupled to a script (which will be described later) so that system administrators can perform specific actions on their servers with these events. By default, Zarafa will only perform the absolute necessary actions during these events; ie store creation and removal. Any other events can be scripted by the system administrator. This means that by default, no actions are performed during group creation and group deletion.

8.5.1.2. Group membership

Zarafa synchronises users, groups and companies so that it can assign user ID’s to them, but the group membership for users is never stored on the Zarafa server. This means that group membership changes are real-time also, and the Zarafa server will query group membership for a user or a user list for a group directly from the LDAP server. How the mapping between group members and users is done will be discussed later.

8.5.1.3. LDAP server dependency

Due to the fact that the Zarafa ‘users’ database doesn’t actually hold the user or group information, but only a reference to the LDAP server, the Zarafa server cannot function without a running and accessible LDAP server. If the LDAP server goes down while Zarafa is running, Zarafa tools will not be able to perform any actions, as almost all server-side actions require some kind of interaction with the LDAP server. For example, just opening an email requires a query to the LDAP server for the groups that the current user has been assigned to. Only after fetching this information, can Zarafa determine whether the current user has the access rights to open the message.
When using OpenLDAP as an LDAP source, it’s recommended to use LDAP replication to guarantee that an LDAP server is available at all times by running an OpenLDAP server on the same machine as Zarafa. This will make sure that the local LDAP server will always be reachable, and Zarafa will always keep running as normal.

8.5.1.4. Setting up the LDAP repository

While in principle almost any LDAP repository can be used with Zarafa, this chapter describes how Zarafa requests the data from the server and how that data is used within the Zarafa server and tools.
The following information is required from the LDAP server:
  • User details (name, email address, etc)
  • Contacts (name, email address)
  • Group details (name of group)
  • Company details
  • User/Group relationships (group membership)
  • Company members (users and group membership)
  • Company relationships (cross-company view and administrator permissions)
The objects that are classified as users, contacts, groups, dynamic groups, addresslists or companies and the attributes that contain the data can be configured within the Zarafa configuration files, so Zarafa can meet the LDAP schema needs. However, here are some pointers to keep the LDAP repository clean and easy-to-manage:
  • Always use some sort of graphical user interface for user and group management. There are many LDAP configuration tools. (For example, phpLDAPadmin for OpenLDAP as a web based interface)
  • If there are users that will be using Zarafa, while other users will not, try to group these users into separate ‘folders’. An OU record or any other dc-type object can be used to create these folders.
  • If Microsoft Active Directory is run, make sure that the real users are in a separate LDAP folder so that Zarafa doesn’t need to import the standard users like ‘Administrator’ and ‘Guest’ into the database. It is also possible to filter the users using an LDAP search query, but these search queries can become unsatisfactorily large when using ADS.
As a general rule, always use the LDAPS (SSL) protocol while contacting the LDAP server. When SSL is not used, information will be transmitted clear-text over the wire. This opens possibilities to sniffing user (and administrator!) passwords from the network wire. Zarafa supports connecting through LDAP via SSL and a certificate specified in /etc/ldap/ldap.conf which is compatible with both Microsoft Active Directory as OpenLDAP servers. Zarafa does not yet currently support STARTTLS-type encryption. More information about setting up Active Directory with SSL support can be found on http://wiki.zarafa.com.

8.5.2. User management from ADS

8.5.2.1. Creating users using ADS

New users can be created by using the default user creation wizard of Active Directory. When creating the user make sure the default email address of the user is always unique.
To configure Zarafa specific information for the user, select the Zarafa tab of the user in Active Directory.
Zarafa user tab
Figure 8.1. Zarafa user tab

8.5.2.2. Creating groups using ADS

In Active Directory both security and distribution groups can be created. The security groups can be used for settings permissions and sending emails. Distributions groups can only be used for sending emails and will not be displayed when setting the security permissions on a folder.
ZCP 6.40 and higher versions have support for nested groups.
The groups can be created by using the default group creation wizard in Active Directory.

8.5.2.3. Creating contacts using ADS

The Global Address Book can be extended with contacts. Contacts are external SMTP addresses which are showed in the Global Address Book and can be used as members of distributionlist.
Contact creation
Figure 8.2. Contact creation wizard

8.5.2.4. Configuring sendas permissions using ADS

Sendas permissions can be configured both on users and contacts. The users or groups that should be able to sendas a specific address, need to be added in the sendas privilege list of the user or contact.
To check wether the permissions are correctly set, use:
zarafa-admin --list-sendas <username>
For example:
zarafa-admin --list-sendas helpdesk
Send-as list (1) for user helpdesk:
       Username        Fullname
       -----------------------------
       john            John Doe
The users that have the sendas permissions, should now be able to add the other address in the ‘FROM’ field and ‘sendas’ this account.
Since ZCP 6.40 the sendas system is changed:
  • Configuring the ‘sendas’ permissions is the other way around than previous Zarafa versions. ‘Sendas’ permissions now have to be configured on the user which is select as the FROM address.
  • See Section 3.5.1, “Pre 6.40 upgrade steps” for converting the sendas permissions.
  • Groups can now also be used for setting sendas permissions.

8.5.2.5. Sending as user alias

In Active Directory multiple email addresses can be added to each user via the Zarafa tab. These aliases will automatically be available for use with the send-as functionality of Zarafa.

8.5.2.6. Setup addresslists in ADS

Addresslists are subsets of the Global Address Book that match a specific criteria. For example, you can create an address list that contains all users in Manchester and another that contains all users in Stuttgart.
Addresslists in the Address book
Figure 8.3. Addresslists in the Address book

To setup an addresslist in Active Directory, it is required to have the Zarafa ADS plugin installed.
  1. Select a folder in the Active Directory tree from the Users and Group console
  2. Create the new addresslist by Action > New > Zarafa Addresslist
  3. Insert the name of the addresslist
  4. Open the properties of the new created addresslist
  5. Add a search filter for the address, see Section 8.6, “LDAP Condition examples” for example condition queries.

8.5.2.7. Hide information from Global Address Book with ADS

From ZCP 6.40, it is possible to hide users, contacts or groups from the Global Address Book. Hiding information from the Global Address Book can be done by the checkbox Hide from addressbook option in the Zarafa tab in Active Directory .
Hide a user from the Global Address Book using Active Directory
Figure 8.4. Hide a user from the Global Address Book using Active Directory

Note

The internal System user and the Everyone group can be made hidden in the /etc/zarafa/server.cfg.

8.5.3. User management from OpenLDAP

8.5.3.1. Creating users using OpenLDAP

Users and groups can be created by using a standard OpenLDAP administration for example phpldapadmin or the Windows tool ldapadmin.
To configure Zarafa specific information for the user, the objectClass zarafa-user has to be added to the user. Adding this objectClass enables you to add Zarafa attributes to the user, like quota settings, sendas permissions, mailbox type.

8.5.3.2. Creating groups using OpenLDAP

Created groups in OpenLDAP will be used by default as security groups in ZCP. The security groups can be used for settings permissions and sending emails. Distributions groups can only be used for sending emails and will not be displayed when setting the security permissions on a folder.
To switch a group to a distribution group the attribute zarafaSecurityGroup has to be set to 0.

8.5.3.3. Creating contacts using OpenLDAP

The Global Address Book can be extended with contacts. Contacts are typically external SMTP addresses and can be used as members of distributionlist.
Contacts must have the same unique attribute as users. Please check the ldap_unique_user_attribute in the ldap.cfg for the correct attribute.

8.5.3.4. Configuring sendas permissions using OpenLDAP

Sendas permissions can be configured both on users and contacts. The users or groups that should be able to sendas a specific address, need to be added in the sendas privilege list.
To check wether the permissions are correctly set, use:
zarafa-admin --list-sendas <username>
For example:
zarafa-admin --list-sendas helpdesk
Send-as list (1) for user helpdesk:
       Username        Fullname
       -----------------------------
       john            John Doe
The users that have the sendas permissions, should now be able to add the other address in the ‘FROM’ field and ‘sendas’ this account.
Since ZCP 6.40 the sendas system is changed:
  • Configuring the ‘sendas’ permissions is the other way around than previous Zarafa versions. ‘Sendas’ permissions now have to be configured on the user which is select as the FROM address.
  • See Section 3.5.1, “Pre 6.40 upgrade steps” for converting the sendas permissions.
  • Groups can now also be used for setting sendas permissions.

Note

When using groups for the sendas permissions, make sure the ldap_sendas_attribute_type is set to dn. See the following LDAP configuration:
ldap_sendas_attribute = zarafaSendAsPrivilege
ldap_sendas_attribute_type = dn
ldap_sendas_relation_attribute =

8.5.3.5. Setup addresslists in OpenLDAP

Addresslists are subsets of the Global Address Book that match a specific criteria. For example, you can create an address list that contains all users in Manchester and another that contains all users in Stuttgart.
To setup an addresslist in OpenLDAP, follow these steps:
  1. Create an Organisation Unit for all the addresslists in the LDAP tree.
  2. Create a new LDAP object and add the objectClass zarafa-addresslist
  3. Set the cn attribute to the unique name of the addresslist
  4. Create a condition query in the zarafaFilter attribute, see Section 8.6, “LDAP Condition examples” for example condition queries.
Addresslists in LDAP
Figure 8.5. Addresslists in LDAP

After restarting the zarafa-server, the addresslists should be visible in the global addressbook.

8.5.3.6. Hide information from Global Address Book with OpenLDAP

From ZCP 6.40, it is possible to hide users, contacts or groups from the Global Address Book.
Hiding information from the Global Address Book can be done by setting the zarafaHidden attribute in OpenLDAP to 1 on a specific object.

Note

The internal System user and the Everyone group can be made hidden in the /etc/zarafa/server.cfg.