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


To obtain profile data, Linchpin User Profiles can use LDAP directories as source.

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.


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.


Field type vs. LDAP attribute


If you want your LDAP resource to deliver profile information, you have two options that affect the possibility to edit fields.


Option 1: Define any field type like text field or select field and add an additional LDAP attribute.

If you select any other field type and still select LDAP server as data source, the information will be retrieved from your LDAP resource.

But if the user can't be found in the LDAP resource, the user will be able to edit the field by themselves.


Option 2: Define your field as "Retrieved from LDAP"

This option retrieves the data only 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.



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.

Troubleshooting

If the test fails, please check the following things:

  1. Connection to the user directory (network, credentials, permission).
  2. 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.
  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?

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 inputMultiline textSelect and the profile picture.

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 field. 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

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. Then you can activate an incremental sync again.



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)


Please make sure that all connected LDAP systems use the same timestamp pattern. Otherwise no data will be synchronized!