removing/disabling users when using freeIPA

[Kumu IT]

Our Crowd is configured with freeIPA backend to authenticate and authorize users/groups. The setup works fine for both JIRA and Confluence. 

Since we are over our license (50 users), I have to remove dozen of dormant accounts. I can easily remove them from IPA groups, but the client asked to keep accounts so spaces/projects/issues/etc still have their names for reference  purposes.  

I've tried to disable accounts in IPA, but they still appear in JIRA/Confluence and I presume counted toward the license cap.

So what is a correct way to solve the problem of disabling user accounts so they won't consume the license seat, while user name won't disappear from the JIRA/Confluence. 

Thank you

Oleg

[Kumu IT]

Hi Ann, 

Thanks for your response.

Adding users to Crowd internal directory while removing them from LDAP sounds a bit cumbersome solution.

I prefer to remove users from confluence-users group, however... Since Crowd is configured to authenticate IPA users only from groups confluence-administrators and confluence-users (similar with jira-users/admins/developers), I afraid once I remove a user from confluence-users group it won't show up in Confluence at all. 

Oleg

[AnnWorley]

Hi Oleg,

I understand you have limited the groups that can authenticate from the FreeIPA directory in Crowd in the application settings for Jira and Confluence. For example, in Crowd under Applications>Confluence>Directories and groups tab, you have confluence-users and confluence-administrators.

Users should still be visible in the application when removed from the confluence-users group in such a case, please see: Specifying which Groups can access an Application

This setting will override any permissions configured in a client application. For example, even if the test-users group is given the Can Use permission in Confluence, if they aren't a mapped group as specified on this page, they will be unable to authenticate. This does not prevent usernames and groups from appearing in the client application.

If you have a filter defined on the FreeIPA directory so it only syncs members of particular groups to Crowd, then removing the users from the groups would remove them from the application.

Thanks,

Ann

[Kumu IT]

Ann, 

Thank you for clarifying that, I have the former. 

Have a good day, Oleg

[AnnWorley]

Oleg,

Cool! If you cannot test in a staging environment please consider trying with a test user before removing a ton of accounts from the permission-granting groups.

Happy Friday to you, too. :)

Ann

[AnnWorley]

Hi! I am not super familiar with FreeIPA but it sounds like you are connecting it to Crowd as an external user directory. My understanding is you want to keep historical data attributed to the users in Jira and Confluence but not have the users take up a license.

I understand you disabled the users in FreeIPA but that did not change their status in the applications. Crowd only seems to pick up disabled status from Active Directory, based on this comment on Provide Crowd support for Active Directory's "Account Disabled" flag

There are a couple of approaches. If the groups you use to grant permission to use Jira and Confluence (for example confluence-users usually has global permission to use Confluence) reside in FreeIPA, you may remove the users from those groups to keep their history and prevent them from using the applications or taking up licenses.

Another option is to try the procedure recommended for deactivating LDAP users in this Crowd kb article: Deleting or Deactivating a User. It has this note:

For applications that need users to exist for historical data (such as JIRA), you should recreate the user and mark it inactive in a Crowd Internal Directory before deleting from your LDAP directory.

I strongly recommend trying the deactivation scenario in a test environment first to make sure it works for your configuration. Removing users from groups that grant them application permissions is more reversible but a test environment would come in handy for that, too.