Jira full LDAP integration - how do you deal with retiring users?

[JamieA]

I was quite excited about the possibility of full LDAP integration, which would solve the perennial issues of

1. permissioning users who haven't logged on yet,
2. making all users in the company available in user custom fields
3. retiring users from jira when they've left the company, so they can't be assigned items etc

Unfortunately I've now realised that it hasn't been properly thought through, or I'm missing something.

When a user is removed from LDAP, if they are an assignee or reporter they show in jira as just their username, and it's not linked, nor can you search for them.

When their user is the value of a user custom field, this field just does not show anymore for relevant issues, and a message is logged: "Issue XYZ-5 has an invalid value 'someuser' stored in the field 'User Custom Field'"

Atlassian say We recommend that you perform all user management in JIRA. Wait a minute, this is ridiculous. Does anyone think that in a company of 60k people, HR are gonna call the jira guy and ask him to delete the user from jira?

A sensible thing to happen might be that in this scenario the user is moved to an internal directory called "Retired Users" or something. But you can't create internal directories so I can't even attempt to do it myself.

Someone please help me with what I'm missing here.

[JamieA · Accepted solution]

Confirmed bug.

[Greg Redl]

We are using Crowd to integrate Active Directory into our other Atlassian wares, and also ran into a similar situation. We used an internal Crowd directory to recreate the removed LDAP/AD account, and provided that authentication rights into JIRA. Proper security protocols are kept by not keeping an unnecessary account in LDAP/AD.

Prior to JIRA 4.4.x, you are correct that internal and external user directories could not be used together. Luckily Atlassian released JIRA 4.4.x and finally allowed external and internal user directories to co-exist.

It might take an upgrade to achieve it, but your want of creating an internal directory called 'Retired Users' is now possible. Just make sure that when you create the internal user in this directory you emulate the Display Name and Login Name to be exactly how they were in LDAP. If not, then the links to their information remain broken.

[JamieA]

I don't think I said that internal and external directories could not be used together... what I said was that you could not create more than one purely internal directory. And I want the "Retired Users" directory to be a component of the LDAP directory and handled entirely by jira. When a user is deleted it should be moved to the internal directory component of the "full ldap" directory.

[Sally Unsan]

How do you handle users that leave the company (say BBrown) then a new employee with same username is hired and their AD account is also BBrown?

[Tiago Comasseto]

Hi Sally,

That's is a very specific situation. As a suggestion you could follow this instructions to bulk edit the issues associated to the user BBrown that left the company to someone else, and keep using the account for the new employee.

I hope this helps.

Cheers

[Kyle]

Microsoft AD supports users with unique objectGUID or objectSID or both, perhaps with the same username(i am not too sure about this).

http://technet.microsoft.com/en-us/library/cc961625.aspx

However Crowd and other Atlassian applications use username as the unique identifier for their applications.

Therefore when a user leaves the company, and another one joins with the same username, we have a problem with our Atlassian applications. Because he will generally inherit all the existing issues/pages/historical data in Atlassian products.

I have seen some applications that use objectSID/objectGUID as unique identifier and this helped avoid the historical data inheritance yet allowing the new user to have the old username.

Not sure how Atlassian or other LDAPs would tackle this problem in the future. I hope something like objectSID/objectGUID would happen to directories that use username as unique identifiers.

[Greg Warner]

@Dave . This is run as a scheduled activity. Most of what I have written is in python, so I use pycron for executing this.

[Greg Warner]

I've got 110k employees worldwide. This happens to me a lot. This is how I tackle the situation.

I have a script using the SOAP API that queries JIRA for all of the users who are members of the jira-users group.

I then compare this with a HR database table containing active staff members. If staff appear in JIRA but not in the HR database, I use the JIRA API to move them into a group called jira-leavers and remove them from all other groups. If the staff member one day returns (for example a contractor does this a lot) they are simply placed back into the appropriate JIRA groups and they can continue using JIRA.

This way I maintain the integrity of the JIRA history and automate it as best I can.

cheers

- Greg

[JamieA]

Do you have full LDAP integration? Or delegated LDAP integration. I'm really talking only about the former here... with full LDAP integration jira will just remove them from the directory, causing various buggy behaviour.

[Devu Heda]

@Greg

Do you run this as a scheduled job or on demand? We already plan to do something similar but want to hook that up as a scheduled job within jira else as a cron job

[MitchellM]

There are some other unintended consequences of deleting users in AD or LDAP, one of which is issues that a deleted user was a part of (workflow in progress, for example) need to be reassigned to someone else. The best answer in my situation was to disable users in the directory, not delete them. This also preserved all history activity of that user, even though they are no longer using Jira. Hope that helps.

[JamieA]

That's fine but my point is I have no control or influence over AD, so I cannot disable them and prevent them being deleted.