nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What happens with the users that are removed from LDAP when you use Crowd LDAP connector?

Sorin Sbarnea (

Most Corporate LDAP directory directories do have the following rule: when an employee leaves they disable the user account for a specific number of days (usually 30 or 60) and after this his account is arhived, which means it will not be visible to any normal LDAP queries.

If I am not wrong now CROWD connector has two major problems:

* If the user is disabled in LDAP, the user will appear as active in the directory, so jira users will continue to assign issue to him or expect him to act. Surprise he is already in permantent vacation!

* When the user is finally removed from LDAP, crowd will remove the user from the directory so Jira and Confluence will start to behave very strange (even breaking in some cases), because as you may expect this used can still own filter, tickets, pages, roles, asigneee, comments. And worse, people will not be able to find who it was because the email and full name are lost, only the login will remain in the system.

Am I true? How should we fix this?

I am not wrong, the only thing crowd should do is to disable users that are disabled in LDAP or not found. I a user reappers, it will just pe enabled. This means that group membership is not lost and also the other systems (jira, confluence,...) will continue to work correctly.

Accepted answers

Moriah Chandler

I found this: https://jira.atlassian.com/browse/JRA-24937 "When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user" while searching for the answer to the above question. Not sure if it answers all of your questions, but seems a step in the right direction.

All comments

Daniel Borcherding

Hello Sorin,

You bring up a very valid point. There is a lot of confusion around best practices in removing employees that have separated.

As it currently stands out suggestion is remove all existing group memberships from separated employees and place them in a new "disabled" group. This will ensure that they no longer have the "can use" permission and are not counted against your seat total. Putting them in a group without use permissions should also remove them from any auto complete forms. This approach also removes the complication of having older records that reference that users without the user actually existing.

This approach should cut down on the number of issues you are seeing. You will still see the old users name and information, but you should not have to worry about issues being assigned to them or eating seat licenses.

Please let us know if that makes sense

Sorin Sbarnea (

Hi Daniel,

Sorry but I have to disagree here: people may have their account disabled or temporary missing from LDAP for several reasons and if jira/crowd is removing their group membership it will make a serious problem. There is the "disabled" flag (recently introduces) which must be used, without altering the memberships or other user attributes in any way.

If you know how LDAP works you will not be surprised to find out that it is possible to get incomplete answers, which now could create serious problems.

Playing with the active attribute is all we need but the problem is that we to be sure that Crowd/Jira/... will not remove the users from the directory when they are not found anymore. All it has to do is to mark them as disabled.

Please note that for 90%+ of corporate installations LDAP directories are read-only, that's because they are considered to be extremly sensitive and IT will probably never allow Jira/Crowd to manage them, even if these systems are managed by the same people.

Shortly, what I want to say is that we cannot prevent people from disapearing from LDAP, all we need is to prevent them from disapearing from crowd/jira, and this should be implemented by disabing them.

The newly introduced feature local-groups for LDAP-connector is great, the connector only needs a little bit additional work to make it a fully functional and easy to maintain solution. I think that this is the last lasting big issue regarding corporate usage is the user removal.

Considering that is very easy to detect if an account is disabled:

(userAccountControl:1.2.840.113556.1.4.803:=2)) -- should check only this bit not others, this works for any version of Microsoft Active Directory and probably even for other directories.

For the moment I do think that both cases: account disabled and account missing (removed) should be treated the same: account is disabled. Obviously on sync the account would be enabled if it will be back and not being disabled.

Chad Barnes1

Is there a reliable way to query JIRA or Confluence (REST APIs) and dertermine which users are no longer valid (not being synched with Crowd)? If so, the Crowd REST API could be used to recreate those users in a Crowd internal directory. That directory could be dedicated to *inactive* users and added to the appropriate inactive groups.

In this way you would not have to change your LDAP practices yet still retain these user identities to service the tools' shortcomings.

Moriah Chandler

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

crowd

crowd-integration