Confluence vs AD-LDAP user management best practices

[Alex Perez]

Some background

There is a confluence install (5.1.3) configured to use two directories:

• Internal: storing service accounts, and other administrative users
• Microsoft Active Directory (Read Only, with Local Groups): pointing to the IT MS-AD servers

IT guys in our organization are using Active Directory to manage about 5-10k users.

The problem

Some user -let's say user John Smith "jsmith"- left the company some time ago. He wrote some content in confluence and when the IT people locked and delete his account, the content appeared as written by "jsmith" (instead of "Smith, John" while the user was still active in LDAP).

After some time, a new user called "Jack Smith", with login (=samAccountName) jsmith joined the company. Now, we have a problem ... All the content generated by John Smith some years ago is shown as generated by Jack Smith. There are no email notifications in our confluence install, but Im pretty sure that if they were active, the emails would be sent to Jack (despite Jack can't log in because jsmith was removed from confluence-users when John left the company).

In one sentence: confluence is telling us (incorrectly) that some content is authored by Jack Smith.

Open questions

How can we work around this weird behaviour? I think that is a conflict between the confluence ldap config and the IT user management policies ...

Can we (confluence admins) change the User Directories config to avoid this?

Should they (LDAP admins) leave the users locked and NOT recycle it-s username when a person leave the company?

Is there any best practice to manage this scenario?

Thanks.

[Deleted user · Accepted solution]

Hi Alex,

we have a big directory server with > 100.000 users and I think it is best practise not reuse the userid.

I personally would write a script that renames the autor of the pages to something like "deleted_USERNAME". It#s not the best solution but you could work around the issue of two seperate persons with the same username.

Regards,

Adrian

[Alex Perez]

This could be a solution.

There are some SQLs to rename users in the CONF-4063 issue, Im going to check that.

[jing_hwa_cheok]

Confluence recognize owner of a content based on the username. When the user jsmith was deleted from the AD server, the content that he created still exist inside the database. These content is no longer accessible throught the Confluence UI. When another user with the same username is created in the AD or the internal directory, Confluence will recognize this user as the owner of those content thus giving him the permission to those content.

Normally you won't be able to delete the user from the internal directory that have created some content, this is to prevent this issue from happening. But this restriction is not apply to the AD server.

The best practice is to delete the content of the user after he is disable or remove. You can refer to this document for the step to do this https://confluence.atlassian.com/display/CONFKB/How+Do+I+Remove+a+User+Who+Has+Content+Created

[Alex Perez]

I dont want to delete his content as it's still valid, and even for traceability purposes I want to keep the original author.

Then ... should I tell AD guys that recycling usernames in AD is a bad practice?

[jing_hwa_cheok]

Hi Alex,

Yes, you should tell them to avoid recycling username. Currently, there is no way to avoid this issue if you plan to recycle the username when there the previous username owner content still exists. We have created a feature request https://jira.atlassian.com/browse/CONF-4063 for a function that can be used by the administrator to change the name. In order for this feature to be implemented, confluence must no longer used username as a reference for the content therefore it will indirectly solve this issue as well.

I would suggest you to vote for this feature request.

Kind Regards,

Jing hwa