Documentation's navigation
On this page
How does LDAP work for Linchpin User Profiles?
By default, user directories configured in Confluence are used to fill the user profiles.
But you can also let Linchpin User Profiles (LUP) use LDAP directories to obtain user profile data.
General idea
Usually, the LDAP server is the information center of the company. User information is stored here and other systems can pull data like names, positions or phone numbers from it. This translates to a lot of work for the IT crew who has to maintain all this data and apply changes manually.
Linchpin User Profiles allows you to establish self service for user data. 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.
Synchronization
The profile data is updated by a regularly scheduled Confluence job named Bulk profile update (LDAP sync) which connects to your LDAP server and updates the profiles then. You can of course configure when the LDAP sync happens or trigger it manually, too.
Navigate to Confluence administration → Administration → Scheduled Jobs to find the LDAP sync feature.
Please note: Confluence supports different kinds of directory connections. For more info, click here.
Linchpin User Profiles does only support Delegated Authentication Directory and LDAP Directory Connector. If you connect your user directory via one of the other types (e.g. JIRA), the synchronization will not be possible.
If the individual profile sync works, but the scheduled synchronization appears to not have an effect, please check whether your User Directory configuration might cause the same user(s) being sourced from more than one directory. If this is the case, you can try temporarily disabling the additional directories and see if running the scheduled job is successful with only one directory providing user data.
For more information on failed profile field syncs, please read our knowledge base article on this matter.
Retrieve data from LDAP
Always retrieves the profile information from your LDAP resource.
Users will never be able to edit this profile field, even if the user can't be found in the LDAP resource.
The LDAP connection is strictly "read-only". Never will any data be written back to your LDAP resource.
In the Source section, select LDAP server from the drop-down menu. In the text field, enter the name of the LDAP attribute where the profile information is stored.
The value of this profile field will be retrieved from this LDAP attribute for each profile update.
If you want your LDAP resource to deliver profile information, define any field type like text field or select field and add an additional LDAP attribute in the source section.
If you select any field type and still select LDAP server as data source, the information will be retrieved from your LDAP resource. If the user can't be found in the LDAP resource, the user will be able to edit the field by themselves.
Related topic: CUP - Alternative LDAP connection
Write fields back to user directory (LDAP)
Because the LDAP server is such a crucial part of every IT infrastructure, there is a two step process to enable this feature.
Enable write access inside of Data sources
First, you need to enable and configure the feature itself in the Data sources. Navigate to Confluence administration → Linchpin User Profiles → Data sources.
In the Allow write to LDAP section, select the Enable write to LDAP radio button. 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.
If the test fails, please check the following things:
- Connection to the user directory (network, credentials, permission).
- Check the configured LDAP Schema (Base DN, Additional User DN) in the Confluence administration (User Directories). The DN to search users sometimes can be less specific than the DN for modification. Look up the actual DNs with ldapsearch if you are not sure.
- Does the Confluence User belong to a user directory? Local users (like admin) won't work for the test.
- Does the LDAP Attribute exist in the Schema of your user directory?
- Is the LDAP Attribute you use in your test a plain text field? The test will not work if you use e.g. a binary field for images or other files.
Please note, that admins themselves need to know how to configure their directory service so that access works.
To enable and configure the test feature, your Confluence user needs to have the role of a 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
Secondly, you need to navigate to Confluence administration → Linchpin User Profiles → Profile Editor.
Here you will have to enable the write access for every profile field individually.
Edit the profile field you wish to give the write permission to. Inside the edit mode, scroll down to the Source section and select LDAP server.
Activate the Write data entered by the user into the LDAP attribute button.
Finally, click on the Save button.
At this point, this feature is only supported for the field types Text input, Multiline text, Select and the profile picture.
As of version 2.26 the field type Phone is supported here, too.
Please note: Phone numbers are written to LDAP as they are automatically formatted in the users profile, including Spaces or "+".
The supported user directories are OpenLDAP and Active Directory.
Please note that you must follow both steps to enable write access to LDAP.
By default, no field is written back to your user directory even when you enable the feature globally (first step).
How are conflicting field values handled?
There is a minor possibility for conflicting values.
Usually, the users' data is synchronized by the Scheduled Job "LUP: Bulk profile update (LDAP sync)".
As soon as a user starts to edit their own Confluence profile, the app quickly updates all the fields. 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, it might come to a conflict. This might happen when a user opens the edit dialog, makes changes but doesn't close the edit dialog again. If the LDAP server changed during this time, the user will overwrite these changes once they click the Save button.
Incremental LDAP synchronization
For a faster synchronization, use an incremental LDAP synchronization to only import modified user data.
Navigate to Confluence administration → Linchpin User Profiles → Data sources → LDAP.
In the Advanced settings for incremental synchronization section, you will find the Last LDAP sync date option. Enter the desired date and time here.
The app uses the dd-MM-yyyy and HH:mm:ss formats. Your entered values must match those formats (for example: 23-05-2016; 15:30:00).
The next LDAP sync will only update user data modified after the date you entered. Every time the sync job runs, it will reset this date and time.
In most cases, you do not have to change anything here. Except for two cases.
- If you want to force a complete synchronization once: empty the field.
- If you want to synchronize all users' data that has changed since a specific date: enter that date and time.
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 Timestamp pattern of LDAP resource input field. Information about different timestamp patterns can be found here.
Examples
yyyyMMddHHmmss.Z (known to work for a lot of AD installations)
yyyyMMddHHmmssZ (known to work for a lot of OpenLDAP installations)
Link to this page: https://seibert.biz/lup-ldapimport