Removing groups from user in Crowd, user still can access Jira ?

[Hans Pesata]

Hi!

We are using Crowd 3.7.0 with a Delegated Authentication Directory with a LDAP Connector. We created an Application so the users can access Jira and
the users get created, when they first log in.

I assume, that the users can also be pre-created via an import ?

We assign the appropriate groups to the users and users can start using Jira.
When we remove the groups from a user in Crowd, interestingly the user is still able to access Jira ?! Is this a cache related issue or is there an additional step necessary after removing the groups so the user doesn't have permission anymore to access Jira ?

Regards,
Hans

[Marcin Kempa · Accepted solution]

Hi @Hans Pesata

Thanks for reaching out to Crowd's community!

Let me start from rephrasing your problem description to make sure I understand it correctly.

1. You have Crowd (3.7.0) and you've defined Delegated Authentication directory which is connected to some remote LDAP where you keep your users.
2. You also have Jira deployed and a Jira application created in Crowd.
3. You connected directory (from point 1) to your Jira application in Crowd
4. When the user logs in to Jira, authentication requests goes to Crowd, then to remote LDAP and the user is created

There are also some things that I am not sure as those are not mentioned in your post however I assume that:

1. You are creating groups manually in your directory in Crowd itself
2. You configured that 'all groups' can authenticate to Jira application in Crowd (https://confluence.atlassian.com/crowd/specifying-which-groups-can-access-an-application-25788430.html)
3. When you remove groups from user, this user can still authenticate in Jira and has same permissions as before

I think that this situation might be because of two things in your config (bare in mind that I base that on some assumptions):

• You have configured that 'all groups' can authenticate to Jira application in Crowd (this means that Crowd won't be checking group memberships, so even if user does not have groups assigned would be able to pass login in Crowd itself at least)
• Secondly in Jira you have selected that "Update group memberships when logging in": "For newly added users only". This means that even when user logs in to product memberships won't be updated at that time, only after next synchronization with Crowd, which is kind of a 'cache' issue. This is not well documented unfortunately (https://jira.atlassian.com/browse/JRASERVER-65260)

Regarding:

I assume, that the users can also be pre-created via an import ?

You can specify different type of directory, a connector one which will be periodically synchronizing users and groups from your remote LDAP to Crowd.

If you are not interested with that and you would like to just import them once, there are some import capabilities https://confluence.atlassian.com/crowd/importing-users-and-groups-into-a-directory-25788445.html

Hope that helps,

Marcin Kempa

[Hans Pesata]

Hi Marcin!

Thank You for Your detailed reply!

// Secondly in Jira you have selected that "Update group memberships when logging in":
// "For newly added users only". This means that even when user logs in to product
// memberships

I think this was the problem, with the users still being able to login, altough the group-membership was removed.

Yes, I am manually creating the groups within crowd.

At first I had the option "Allow all users from this directory to authenticate.",
so users got created at first login.

Currently I defined some groups which are allowed to authenticate.
In this case I have to pre-create/import the users in order to enable them to login.

With this I ran into the problem, that I dont know the password of the users, because the authentication is managed via the Delegated Authentication LDAP functionality.

How can I mange to pre-create/import the users without the password ?

Regards,
Hans

[Marcin Kempa]

Hi @Hans Pesata ,

I am not sure what do you mean by 'pre-create' users? You mean you are creating those users manually? Or are you importing them somehow to Crowd?

As I understood your setup you've been using remote LDAP directory that Crowd is connected to. What is the reason you cannot create a connector type of directory and have your users synchronized from there?

Best Regards,

Marcin Kempa

[Hans Pesata]

Hi Marcin!

I was under the imperssion that using a "Delegated Authentication Directory" is the way to go. The Authentication is done through the LDAP Connector and the Users and Groups are manged in the Directory.

How can I synchronize the users ?

Regards,
Hans

[Marcin Kempa]

Hi @Hans Pesata 

If you would like to have your users synchronized from remote LDAP or AD directory you would need to create a connector type of directory rather than a delegated one https://confluence.atlassian.com/crowd/configuring-an-ldap-directory-connector-18579550.html

Unfortunately there is no way to change type of directory, you would need to recreate it.

There are some things to keep in mind. When you go for Connector type of directory, you would need to make sure that you have you LDAP filters right so that Crowd synchronizes only those users you would like to manage and give access to applications. If you configure LDAP filter to broadly you may run into problems that your Crowd instance may run out of license as it will pull more users from LDAP then you have licenses seats reserved in Crowd (provided all those users can login to Crowd or applications connected to Crowd, which means they are in groups that allow them to do so or you allow all users from directory to authenticate).

If you would like to know more on types of Crowd's directory please check this documentation https://confluence.atlassian.com/crowd/adding-a-directory-18579549.html. Also you may find following webinars useful:

• https://www.atlassian.com/webinars/software/centralize-identity-management-using-crowd-data-center
• https://www.atlassian.com/webinars/software/managing-your-atlassian-users-as-you-grow-crowds-tips-and-tricks

Hope that helps,

Marcin Kempa

[Hans Pesata]

Hi @Marcin Kempa !

I followed Your suggestion and created a "Generic Directory Server" Directory Connector with an approriate LDAP Configuration and User filter. Because we dont need the groups from the LDAP Server, I am using (objectclass=unknown) as group LDAP Filter, so no groups will be synced. This works. Is there a better way to not sync groups from LDAP ?

I created some groups within the directory and assigned users to them and the users can successfully login to the assigned application, which allows the groups to log in.

I discovered an error message in the crowd log, regarding the created groups:

2019-11-27 10:41:23,849 http-nio-8095-exec-6 ERROR [console.action.principal.UpdateGroups] Membership already exists in directory [13565954] from child entity [xxxxxx@yyyyyy.zzz] to parent entity [abc.def.ghi]

Any idea what this is about ?

Thank You again for Your persistence and support!

Regards,
Hans

[Marcin Kempa]

Hi @Hans Pesata 

The error you've posted is thrown when there is already a relation between group and group (if nesting is enabled) or between group and user, please check cwd_membership table for those entries.

Regarding

I am using (objectclass=unknown) as group LDAP Filter, so no groups will be synced. This works. Is there a better way to not sync groups from LDAP ?

I am not sure if this is the best approach, I am not 100% sure but I am worried that you may fetch some objects that just do not have all required attributes set and are mapped to that object type https://ldapwiki.com/wiki/ObjectClass%3Dunknown.

Have you tried to point group DN to a subtree that does not exists or does not contain any groups?

Regards,

Marcin Kempa

[Hans Pesata]

Hi @Marcin Kempa 

Yes, I am using a non-existing DN for groups, thanx for the hint!

Is there a possibility to clear the users from my directory to make a full fresh LDAP-Sync ?

Regards,
Hans

[Marcin Kempa]

@Hans Pesata there is no such functionality to do that on existing directory. I would suggest to just recreate it.

Regards,

Marcin Kempa

[Hans Pesata]

@Marcin Kempa 

I used an invalid user object filter, started a sync, -> all users were gone
afterwards used the valid user filter started a sync again -> all users were available again

Regards,
Hans

[Marcin Kempa]

@Hans Pesata 

Is there any thing else I can help you with? Were those answers helpful? If so would you ming changing the status as 'answered' it will help others to find solution if they are running in similar problems.

Thank you!

Marcin Kempa

[Hans Pesata]

@Marcin Kempa 

I had to revert to using the filter (objectclass=unknown) in order to omit syncing the groups, because using a  non-existing DN for the groups caused an exception during the sync process and stopped it.

Thank You for Your support!

Regards,
Hans