This issue was fixed with Confluence 3.5. Users which aren't found in LDAP will be no longer counted towards the license count after the next sync with LDAP (or until the user is manually removed, if an "Internal with LDAP authentication" directory is used). The user's personal space will no be longer accessible.

However, the user will not be removed from the people directory. That issue is tracked as CONF-11467.

A related issue around page permissions not working with removed users, CONF-19124, is fixed in Confluence 3.5.12 and later.

Edit: sorry, that's Confluence 3.5.

I haven't been able to test that it is fully working, but I found:

1) Upgrade to 3.5 failed due to LDAP criteria not being specific enough. Specifically, we use a field other than uid= to hold the uid, and the filter criteria was selecting some records that did not have this field. I restored from backup and tried again with a more specific filter specifying "XXX=*". Upgrade took a while (15 minutes?) to complete, and then all was well.

2) Side by side - the old 3.4 had users in the jira-admin group that were broken. No ability to remove from group. No ability to look up user - the new 3.5 had the user automatically removed from the group.

3) I was not able to access the user's personal space. Not sure what I think about this or whether the space is truly gone, or whether I just don't know how to look it up. If the user accidentally stored company information in their personal space (which happens - users don't always listen), this could be a problem.

All in all, I'm happy with the change - but no sure it is perfect just yet. Need more testing, and need to understand what happens to personal spaces for users that disappear in this manner.

We're pretty sure this issue is fixed in 3.5, but we haven't had time to verify that yet.

We'll leave the issue open and hopefully have time to verify the fix during 3.5.x development. If you have any information that this is fixed or not in Confluence 3.5, please let us know.

Dear Moufid,

We are currently working on a major overhaul of our LDAP implementation within Confluence for 3.5 (due out in December or January this year).
In order to fix this issue, the pre-requisite is that the overhaul is complete.
I will update you once I know more.

In the meantime, have you tried Jeremy's workaround?

Kind Regards,
Partha Kamal

I'm on Confluence 3.0.2 and I experience the same issue as describe in here. This made me to fall in a useless wiki after having reached my max Confluence user license.I confirm Anatoli Kazatchkov 10/Aug/09 9:20 PM remark and I have the same concer as Dave van 't Veld 22/Jul/09 6:04 PM. Could you please inform us about this point : we'd like an implementation that would automatically unset the "can-use" permission to any user that is removed from AD

I'd really like to see this get fixed in Confluence!

This bug only references version 2.10 does this issue affect current versions?
We are on version 3.2.1
Active Directory integration (not Crowd)

Maybe this Filter is useful for creating a similar ldap filter for maintaining licenses for disabled users.
In version 3.2.1 using a userfilter maintains proper licensed users when a user is enabled/disabled in AD.

># less atlassian-user.xml
<userSearchFilter>(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))</userSearchFilter>
*note: If you use this filter, the following special characters must be adapted for use in your xml file
! must be changed to & #33 [remove the space]
& must be changed to & amp [remove the space]

Some additional facts:
This user is still a member of confluence-users.
Validated that their content is not deleted when disabled.
Enabling the user puts things back as if nothing was disabled.
We have not performed testing about deletion, removal of this user from confluence-users group.

We're very missing this feature as well. Using SQL statements to get rid of inactive users is not the proper way.

Same here, were looking for a fix for CONF-16445. Java exception in the client navigator is not very friendly and our users are concerned by theses ghosts entries which perturb the sums up of group entries.

Is there any news abount that? We are also unable to delete users from Confluence groups that do not exist anymore in the AD! Is there a workaround?