Page tree
Skip to end of metadata
Go to start of metadata

Import user data from your LDAP

Linchpin User Profiles will use the LDAP directories configured in Confluence to obtain the data for the user profiles. To update the LDAP data in the user profiles, a regularly scheduled Confluence job ("Bulk profile update (LDAP sync)") will try to connect to the configured LDAP and update the user profiles.

You can configure the execution time of that job as desired or even manually start the import there.

Please note

Confluence supports different kinds of directory connections, they are described here: Linchpin User Profiles does only support Delegated Authentication Directory and LDAP Directory Connector, so if you connect your user directory via one of the other types (e.g. JIRA) the synchronization will not be possible.

Write fields back to user directory (LDAP)

General idea: Usually an LDAP server is the information center of the company. This is where user information is stored and other systems can pull data like names or phone numbers. This means a lot of work for the IT crew who has to maintain this data and apply changes.

The Linchpin User Profiles app allows you to establish self service for user data for selected fields: Users can change their phone numbers or correct spelling mistakes themselves within their intranet profile. These changes are written back to the LDAP server, from where they are distributed to other systems.

Because the LDAP server is such a crucial part of every IT infrastructure, there is a two step process to enable this feature.

First you need to enable and configure the feature itself in the Data Sources. Use the Save and test connection button to open an interactive test. This test panel allows you to check if Confluence has write access to the LDAP attribute of a specific Confluence User in your configured user directory.

Check multiple user directories

If you have configured multiple user directories for your Confluence, you need to test at least one user per directory to check the write access.

Check multiple attributes

To check the access for multiple attributes just repeat the test for each attribute.

To enable and configure this feature your Confluence user needs the role System Administrator. All Confluence Administrators are also System Administrators by default, but you can use the different admin roles to prevent unintended modifications by your non-technical administrators.


Configure fields in the Profile Editor

After this first step still no profile field will write back to your LDAP. You have to enable this for each field individually. Or in other words: By default, no field is written back to your user directory although you enabled the feature globally.

To enable the feature for a selected field, just open the editor for the profile field, configure an LDAP attribute and enable the option below ("Write data entered by the user into the corresponding LDAP attribute.").

Supported field types

At this point this feature is only supported for the field type Text input, Multiline text, Select and the profile picture.

Supported user directories

Supported user directories are OpenLDAP and Active Directory.


If the test fails, please check the following things.

  1. Connection to the user directory (network, credentials, permission)
  2. Check configured LDAP Schema (Base DN, Additional User DN) in the Confluence administration (User Directories). The DN to search users sometimes can be less specific the DN for modification. Look up the actual DNs with ldapsearch, if you are not sure.
  3. Does the Confluence User belong to a user directory? Local users (like admin) won't work for the test.
  4. Does the LDAP Attribute exist in the Schema of your user directory?


How are conflicting field values handled?

There is a slight possibility for conflicting values.

Usually you'll have your users' data synchronized by the Scheduled Job "LUP: Bulk profile update (LDAP sync)".

As soon as someone starts to edit their own Confluence profile, the app quickly updates all the fields, so changes that have been made since the last sync will be transferred to the profile. The user simply has to click on the save button to accept these changes.

On rare occasions there might be a conflict, if the user opens the edit dialog and then lets it sit open for a while. If during this time there are changes to the LDAP server, clicking on the save button the user will overwrite these.

Incremental LDAP Synchronization

For a faster synchronization, use an incremental LDAP synchronization to only import modified user data..

Go to Data Sources in the administration panel and select the LDAP tab.

Enable the incremental synchronization if you want to reduce time and server load. The next run of the LDAP sync will use the date defined in the field versus "Last LDAP sync date" to synchronize only users who have been modified from that date up until now. Every time the sync job runs, it will reset this date and time. Usually you do not have to change anything here, except for two cases:

  • you want to force a complete synchronization once: empty the field.
  • you want to synchronize all users' data that has changed since a specific date: enter that date and time. 

The plugin internally uses the timestamp format dd-MM-yyyy HH:mm:ss
So if you want to manually enter a date, you have to use this format, e.g. 23-05-2016 15:00:00.

Workaround for newly added profile fields

 If you add new profile fields after you already activated the incremental sync, they won't be synchronized automatically. In this case simply clear the "Last LDAP sync date" field. This forces a full sync once, which will result in synchronizing all fields including the new ones.

Define the timestamp pattern of your LDAP resource

In order to make the synchronization work, the plugin needs the exact timestamp pattern your LDAP resource uses for storing the "last modified date" information. Please enter the pattern in the second input field.
Information for different timestamp patterns can be found here. 

yyyyMMddHHmmss.Z (known to work for a lot of AD installations)
yyyyMMddHHmmssZ (known to work for a lot of OpenLDAP installations)

(warning) Please make sure that all connected LDAP systems use the same timestamp pattern, otherwise no data will be synchronized.