When using Confluence with LDAP, what is the correct process for removing users

[Angela Todd]

Looking at your documentation on this page: https://confluence.atlassian.com/display/DOC/User+Management+Limitations+and+Recommendations you state the following:

"Be careful when deleting users in remote directories. If you are connecting to an LDAP directory, a Crowd directory or a JIRA directory, please take care when deleting users from the remote directory. If you delete a user that is associated with data in Confluence, this will cause problems in Confluence."

Our sys admins have advised me that it is not good practice to keep users Active Directory once they have left the company.  Their current process is to move them into a 'pending deletion' folder before deleting them permanently.

We have linked our Confluence to LDAP with read only access and local groups.  We do not have incremental synchronisation but are using the method described here: https://confluence.atlassian.com/display/DOC/Synchronising+Data+from+External+Directories to keep the cache up to date.

Can you answer the following questions for me?

1. What "problems" will deleting users in Active Directory actually cause Confluence?
2. How do you recommend deleting ex-employees from Active Directory?
3. Can you explain how Confluence uses the Deleted Objects folder?  It is stated in your documentation that Confluence should have access to read this folder, but not why this is needed.
4. Can Confluence be configured to disable accounts when they are removed from Active Directory rather than simply deleting them?

Thank you very much for your help

[Guilherme V. · Accepted solution]

Hello Angela,

If you delete a user, you will delete his content as well. The best way is to disable him if you are using the Internal Directory.

Another way that I always suggest for other customers, is to filter again the LDAP scope as it is described in this documentation: https://confluence.atlassian.com/display/CROWD/Restricting+LDAP+Scope+for+User+and+Group+Search.

You can also disable those users directly in the database in the cwd_user table. Just update the active column to 'F'. (But I didn't test using the LDAP, just the Internal Directory)
 Backup your database before making any changes  

In my opinion, the best and safety way is to create a new ldap scope just for the active users.

Cheers, 

[Angela Todd]

Hi Guilherme,

Thank you for your reply.

We are not using the Internal Directory, we are using LDAP so your first suggestion will not work for us.

I'm also unclear how the filter will help.  We already filter users in Active Directory based on an AD group that confers access to confluence.  However, when an employee leaves the company we delete their account from AD, which will clearly also cause them to be removed from the filtered list.  What I have observed is that when this occurs the user is also deleted from Confluence, but content that they've authored in public spaces remains.  However, this content is effectively 'orphaned' (ie it is attributed to 'Unknown User (<user.name>'). 

What content are you referring to when you state that the user's content will be deleted?  Is this only content from their personal space? (We have only just enabled this feature so I cannot investigate the effects of deleting a user with a personal space.)

My other observation is that once a user has been deleted it is no longer possible to search for all the content that they authored (they don't have a profile page so there is no Activity History for them, and searching using the global search simply returns content that contains their username in the text).

I simply want to make sure that we are not irrevocably corrupting our Confluence database and would like some guidance on the correct way to remove users when they leave the company or revoke a current employee's access through Active Directory.

Thank you in advance,

Angela.

[Angela Todd]

Sorry - one further question. The JIRA documentation for LDAP (https://confluence.atlassian.com/display/JIRA061/Migrating+Users+between+User+Directories) is very clear on the policy for handling deletions in LDAP: "•When disabling a user in LDAP, it will be disabled in JIRA. •When deleting a user in LDAP, it will be deleted in JIRA if it is not needed, or disabled if it is (e.g. the user has comments)." This is the policy I would have expected Confluence to adopt. Why is there an inconsistency between your two products?

[Guilherme V.]

Hey Angela, About your question regarding corrupting your database, it will not corrupt because of the user_mapping table, it will keep some content information and the expected behavior for deleted users is just show them as "anonymous". Previously versions of Confluence didn't have this option, so all content were deleted as long with the user. Jira is a little bit different from Confluence, they're similar but not equal, so I can't confirm if Jira manage the database as Confluence. Hope I could help you :).

[Brian Clark]

I'm running up against the same issue as Angela.  There doesn't appear to be a solution supported by Confluence for maintaining data and attribution for user accounts deleted from LDAP.  Having all attributable content switch to "anonymous" adds to the confusion, though I guess that's better than all of their content disappearing.  A workaround of creating an account in the local directory with the same username might maintain attribution once deleted from LDAP but it risks creating major confusion later if another user comes along and that deleted username is reassigned to the new user in LDAP.  Does all of this get magically handled somehow if by implementing Crowd?  If so, how?

[David S]

I agree, my LDAP connection is Read-Only.

Syncing does not remove the user that is no longer in the Group DN search string.

We are unable to delete a user from crowd, there is an LDAP write error.