Skip to content

Managing users via Directory Synchronization

Attention

This is a feature that currently requires a user with "System Administrator" privileges. This will be made available for other privilege levels in a later release.

With ad-connect users from a local user directory can be integrated seamlessly into Kopano Cloud.

Adding a new synchronisation configuration

A synchronisation configuration defines how to synchronise directory information such as users from an external source like an Active Directory or LDAP server. Select a name to identify the new set of synchronisation configuration settings. It is recommended that you choose something unique, such as the name of the synchronisation source server.

Add new synchronization configuration
Add new synchronization configuration

After a click on "Add synchonization" the Application ID and Secret Token are shown. Please take note of the secret, as it will only be shown once.

Synchronization configuration overview
Synchronization configuration overview

The synchronisation configuration overview page provides a download link for ad-connect and indicates whether a client is currently connected. The client download archive contains a binary for the selected platform, a sample configuration and a readme file with further details.

Synchronization configuration settings
Synchronization configuration settings

Configuring ad-connect

Modify the example adc.yaml to match your environment. It could for example look like this:

settings:
  dry-run: true
  no-update: false
  no-create: false
  no-delete: false
  delete-disables: true
  no-update-provider-mismatch: true
  create-as-disabled: false

backend:
  ldap:
    addr: ldap://your-ldap-server.local
    bind_dn: cn=readonly,dc=lg,dc=local
    bind_password: readonly
    base_dn: dc=lg,dc=local
    scope: sub

    sync:
      page_size: 20
      filter: (objectClass=inetOrgPerson)

    authentication:
      username_attribute: mail
      username_filter_template: (&(objectClass=inetOrgPerson)(mail=%s))
      timeout: 5

A note regarding the settings part in adc.yaml

As can be seen from the synchronization configuration settings, it is possible to define these settings both on the server side when adding the synchronization configuration and on the client side. In the case of conflicting configuration values, the server will override the client's settings, e.g. if the server only allows dry runs, the client will never be able to actually import users into the server.

Running ad-connect

ad-connect has two modes of operation. When called with the imp parameter it imports users from the configured LDAP source and when called with the run parameter it connects to Kopano Cloud. When password delegation is enabled the client must be connected at all times to allow users to sign in.

To run ad-connect with systemd first create service configuration file called adc.cfg in /etc/e4a-ad-connect with the following content:

AD_CONNECT_ADDR=address-of-server:443
AD_CONNECT_AUTH=application-id:secret-token
AD_CONNECT_CONFIG=/etc/e4a-ad-connect/adc.yaml

To create the actual service run sudo systemctl edit --force --full systeminfo.service and add the following content to the service file:

[Unit]
Description=ad-connect
After=network.target

[Service]
Type=simple
User=nobody
Group=nogroup
WorkingDirectory=/etc/e4a-ad-connect
ExecStart=/usr/local/bin/adc run
EnvironmentFile=/etc/e4a-ad-connect/adc.cfg
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
Restart=always
RestartSec=10
TimeoutStopSec=30
KillMode=process

[Install]
WantedBy=multi-user.target

Note

Other options for running the tool, such as a proper installer for Windows and Linux systems and an OCI container, will be available in a later release.

What kind of information can I import with ad-connect?

By default ad-connect with make use of the following attributes when creating/updating a user:

  • cn or displayname
  • title
  • description
  • mobile
  • telephonenumber
  • mail

If alias syncing is disabled mail has to be an unique attribute. If you have multiple mail attributes per user these need to be mapped as email aliases to the user.

Anchor attribute

The anchor attribute can be modified in the "synchronization configuration settings" and defines which attribute should be used as the unique identity of the user. If this attribute is already a valid email address it will be used as such, otherwise a domain can be mapped onto it depending on the location within the LDAP tree.

[..]
    domain_map:
      dc=lg,dc=local: ad-connect.local
[..]

On the server side the mail attribute has also been the anchor attribute up until version 6.1.2. From version 6.2.0 onwards the anchor attribute is uid.

Attribute mapping

In case the desired information are stored in differently named attributes it is possible to map these on the fly onto the proper value. In the below example the value of the kopanoAliases attribute is treated as the mail attribute.

[..]
    attributes_map:
        kopanoAliases: mail
[..]

Optionally it is also possible to transform attributes while reading data from the LDAP. This is useful when for example the LDAP contains a different domain name in the LDAP attribute.

[..]
    attributes_transformer:
        mail: 's/\(.*\)@.*/\1/'
        attributes_transformer_command: "sed --sandbox -e"
[..]