Directory Service

Figure 1. Directory Service tab in Domains & Accounts - Management.

This option allows you to have IceWarp Serversynchronized with directory service via LDAP protocol. Active Directory or other kinds of LDAP servers are supported. However, we recommend using LDAP server that supports operational attributes modifyTimestamp and entryUUID such as OpenLDAP. IceWarp Server uses those attributes to identify entity even after email address is changed and to detect change of user data. Without these two attributes only email is left to be used as unique identifier of entity and all user data is processed on each synchronization which can cause serious performance problems. In such cases, synchronization of groupware (user) data should be disabled by setting the c_system_adsyncdisablevcardsync API variable to true.

IceWarp Server will synchronize on a regular basis and any changes to users within the directory server will be reflected within IceWarp Server . There is a limitation however, IceWarp Server stores most of user properties into its vCard handled by groupware, once change is done in vCard on IceWarp Server side, the change is preserved during synchronization (attributes in LDIF are not stored in IceWarp Server for the changed entity).

Synchronization schedule is set to every five minutes by default, but can be altered by changing numeric value of the c_accounts_global_activedirectorysyncinterval API variable.

Note: This is a one-way synchronization only, directory server to IceWarp Server . If you change user data within IceWarp Server , this change will NOT be reflected on the directory server and IceWarp Server will revert this change to match the state on the directory server. You can still define users within the domain who do NOT exist on your directory server. Such users will not be affected by the synchronization engine.

Exception: There is a way how users synchronized against a directory server can change their passwords via IceWarp WebClientThis option is available for AD and IceWarp Server version since 10.3.0, for generic LDAP servers since version 11.2.0. For more information, refer to the Changing Password via IceWarp WebClient chapter.

User template will be applied on newly created IceWarp accounts since version 11.3.0.

Figure 2. General section.

Field Description

Synchronize users and groups with directory service

This option is appeared for Cisco Integration enabled products only. Also when external synchronization library is presented in dedicated folder - {install_path}/externalsync.Its functionality is the synchronization of users and groups with an AD or other LDAP server.

Figure 3. Server section

Field Description


Specify the Hostname or IP of the directory server. To use LDAP over SSL in combination with windows.dll and AD, you should use FQDN of the directory server (the same value must be used in CN in certificate of that server).

Note: You can force secure communication with the LDAP server by specifying: ldaps://<your_ldap_server> (port can be specified using the :port suffix).
Example: ldaps://
or ldaps://

Backup hostname

Specify a backup directory server, if you have one.

Note: This setting may cause a problem with user login as IceWarp. It is not capable to store authentication string (user API variable u_authmodevalue) longer than 116 characters.
Fix scheduled to version 11.5.0.


Specify a user with access rights to user information on the directory server.

User with read-only rights can synchronize itself, however change password functionality require this user to have write allowed rights too.


Specify the password for the user above.

Synchronize Now

Click this button IceWarp Server to synchronize the domain immediately with the specified directory server.


This field is intended to be used for more precise control over the domain you access. DN can serve as an additional filter; it defines the scope of what is going to be read from directory server.

If you do need to enter anything here then it should be a complete DN, e.g.: cn=Users,dc=icewarp,dc=comordc=icewarp,dc=com for all accounts in all sub nodes.
Your directory server administrator should be able to help you with this.

Warning: BE AWARE. If a large scope needs to be searched, but only a little part of returned objects match sync configuration (usually have desired mail attribute value), then should be appropriate to limit the query results with filter.
For more information about this topic, refer to More Complex Scenario node, chapter Sync Accounts from Multiple Email Domains.

Test connection

Click this button to check that IceWarp Server can access the LDAP server. This test will reveal what is returned from your directory server to IceWarp Server . Basically, you can check your synchronization settings.

Figure 4. Advanced section.

Field Description

LDAP server type

Select from the list

  • Active Directory: choose this option for Microsoft Active Directory.
  • Generic LDAP: choose this option for other LDAP servers, e.g.: OpenLDAP.


(for both users and groups)

In this field, you can specify the full LDAP filter for users (groups respectively) to be synchronized. The syntax of the filter can be either simple or complex. For simple syntax, just enter the objectClass which represents a user (group respectively) on your directory service. e.g.: User  (Group respectively)

For complex syntax enter the full filter in the syntax supported by your directory service enclosed in brackets,


(userAccountControl=66048) - synchronizes users with the given userAccountControl.

Generally, use the right syntax expression that the directory service (OpenLDAP, AD, atc.) uses for the desired category. See the appropriate RFC.

Most typical objects types:

  • User: Typically used by AD.
  • Group: Typically used by AD.
  • inetOrgPerson:Objects typically used by LDAP.

(For more information, refer to RFC 2798 - or to RFC 2254 - - the later one describes LDAP search filter syntax.)
(For more information about this topic, refer to More Complex Scenario node, chapter Sync Accounts from Multiple Email Domains).

Directory service domain is different from this domain name

Check this option if the domain names in IceWarp Server and your directory server do not match or when the domain used in mail attribute in the directory server does not match domain in IceWarp Server or when both of the former is true.

See the AD Domain Different from IceWarp ServerDomain and Email Domain of AD Accounts is Different from IceWarp ServerDomain chapters.



If your LDAP domain name is different from your IceWarp Server domain name, you should specify it here. You can also specify a second AD domain name here, separated with a semi-colon, if required (this is an unusual case, your AD administrator will know whether it is necessary or not).
Example 1:
IceWarp Server domain =
AD server domain = ADDomain
email addresses in ADDomain are *
you should enter ADDomain
Example 2:
IceWarp Server domain =
AD server domain = ADDomain
email addresses in ADDomain are *
you should enter ADDomain;
Example 3:
IceWarp Server domain =
AD server domain = ADDomain
email addresses in ADDomain are * and  *
you should enter ADDomain;*

See the AD Domain Different from IceWarp Server Domain and Email Domain of AD Accounts is Different from IceWarp Server Domain chapters.

AD login source

Select which property is used as a source of login by onto your directory server. This setting controls what is put into the u_authmodevalue variable of a synchronized user:

  • Use userprincipalname: the authentication value should end with user@domain.
  • Use samaccountname: the authentication value should end just with NT user name.
  • Use DN: the authentication string should end with something like CN=TheOne,CN=Users,DC=example,DC=com.

Local username source, Basic property

This setting determines which LDIF attribute will be used by the IceWarp Server as username for IceWarp provided services:

  • Primary Alias of AD Account: alias taken from mail attribute is used.
  • Login of AD Account: the selected AD login source (see above) is used.
  • CN of AD account: the common name of directory server object is used.


Local username source,Custom AD property

Set a custom LDIF attribute that you want to use as a source for username of accounts in IceWarp Server. Setting a value into this field will override and disable what you set in the Basic property dropdown. This field displays content of the USERNAMEFROMSPECIALFIELD element of the syncad.dat config file.

For instance, if you wish to use LDIF attribute description as username in IceWarp Server, type description into this input.

Add AD login to local alias

Tick this box if you want the user's AD login name (only alias - not whole email address if used) to be added to the Alias field within the Management - <domain> - <user> - User tab.

Figure 5. Kerberos / GSSAPI / SSO section.

Field Description


Tick the box if you want to use Single Sign-On (SSO).

Service name

Fill in the service name.

Its syntax is: <site_name>@<ACTIVE_DIRECTORY_SERVER_DOMAIN>


(May be, but need not to be the FQDN or domain of your IceWarp Server instance.)

Note: SSO service name consists of two parts: vhost@ADSERVER
vhost can be the same as long ADSERVER is the same for multiple IceWarp domains. Thus when administrator wants to have multiple SSO enabled domains connected to multiple AD domains, he has to have different vhost parts.

Remote account matching

Select the way how IceWarp Server users will be matched with accounts in your directory server.

  • Match with username: user's IceWarp ServerUsername will be used.
  • Match with alias: user's IceWarp ServerAlias will be used.
  • Match with AD user's connection string: the Authentication field (when LDAP / Active Directory selected) will be used.
    See the user - Options tab - Account department.

Place keytab files under "config/_keytabs" directory

Click the Manage keytabs button to open a file manager. Into the <install_directory>/config/_keytabs/ folder, place files with keys generated by Active Directory for individual principals (SMTP, IMAP, POP, XMPP, HTTP) using the ktpass command.

Each file name has this format: <principal>#<server_name>@<ACTIVE_DIRECTORY_SERVER_DOMAIN>



The syncad.dat File

Besides of tags with self-explanatory names, this file (<install_directory> - config) includes ones that are not so clear:

<USERNAMEFROMADUSERNAME>1</USERNAMEFROMADUSERNAME> - if enabled (1), account name is imported from attributes givenname and sn, but only in the case both are not empty and vCard synchronization is disabled, otherwise the name is determined in a common manner - for more information refer to How AD Sync Determines User Full Name.

<ALLDATADELETION>0</ALLDATADELETION> - if enabled (1), emails and all other account bound data stored on mail storage are deleted when sync mechanism removes an account from IceWarp Server . This setting prevents accidental data loss (not all of them). On the other hand, it comes at a price as the mail storage has to be purged manually.

<VCARDMAP> - feature that allows control over import of LDIF attributes to IceWarp groupware - for more information refer to vCard Map Feature.

<GROUPSUPPORTREMOTEMEMBERS>0</GROUPSUPPORTREMOTEMEMBERS> - if enabled (1), groups can contain even members whose mail attribute value does not match sync settings (such members would not be accepted as users due to an email address from a different domain). If you want to synchronize a distribution group with email addresses that do not belong to any user synced to IceWarp, this is the option to allow it.

Hierarchical Address Book (HAB)

Synchronization can be configured to convert organization units on the directory server into IceWarp Server groups. These groups can then be a part of HAB. This functionality has to be set manually in the syncad.dat file (<install_directory>/config/).

There are three nodes to configure:


    This makes the AD/LDAP sync to create groups for all relevant organization units.

    E.g. when the following user is imported into IceWarp:

    dn: CN=Lukas Novak,OU=Client,OU=Webmail,OU=Devel,DC=icewarp,DC=in - four groups are created automatically: Client, Webmail, Devel and Contacts. Lukas is a member of the Client group. Client group is a member of the Webmail group etc. The Contacts group is the automatically created as the root group.

    Note: The alias of the group has to be plain ASCII and unique. In the order to follow this rule, group aliases are constructed as ou=<name>_<id>.


    This option allows skipping of some organization units from being converted into groups. You can specify which organization unit (must be in scope of DN) to use as the root one. Only units belonging under that unit will be converted into groups.

    On the contrary to the previous example, setting the root group like as follows:


    synchronization of the same user object:

    dn: CN=Lukas Novak,OU=Client,OU=Webmail,OU=Devel,DC=icewarp,DC=in

    would cause creation of only two groups - Client and Webmail. The default root folder of Contacts is not created, because we can determine the name of the root from <GROUPSFOROUSROOT>.


    This option can override the default name of the root folder.

    Examples (all cases require having CREATEGROUPSFOROUS set to 1):





    dn: CN=Lukas Dvorak,OU=Client,OU=Webmail,OU=Devel,DC=icewarp,DC=in

    Created groups: Units, Client





    dn: CN=Lukas Dvorak,OU=Client,OU=Webmail,OU=Devel,DC=icewarp,DC=in

    Created groups: Units, Devel, Webmail, Client.





    dn: CN=Lukas Dvorak,OU=Client,OU=Webmail,OU=Devel,DC=icewarp,DC=in

    Created groups: Contacts, Devel, Webmail, Client.





    dn: CN=Lukas Dvorak,OU=Client,OU=Webmail,OU=Devel,DC=icewarp,DC=in

    Created groups: Units, Webmail, Client.