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; } } }

Crowd LDAP, group nesting and LDAP queries

Sys Admin_oc5n5o

Hi!

We're trying to use the underlying LDAP server used by our Crowd instance to manage access to 3rd party applications, but we are facing some strange behaviour.

We use Nested Groups in Crowd/LDAP to manage application access / JIRA Project /Confluence Space/ Bitbucket Repository permissions. Users belong to groups which belong to jira-users, confluence-users, stash-users and they have different permissions for each application.

As I can see with Apache Directory Studio, groups in LDAP are kind of "special users" with the attribute objectClass=groupOfUniqueNames, I think they should be in a different OU (groups) instead of OU=people and this is what is causing most headache.

I want to retrieve all users who belong into the group "internal" directly or by inheritance to allow access to a LDAP connected app, but I can't use the attribute memberOf=internal since it doesn't exist in any user.

User membership into a group if defined by a custom attribute in each group asset called "uniqueMember" which stores the cn of a user. Each group has as many "uniqueMember" attributes as users inside that group.

How can I retrieve only the users who belong into "internal" with a single query? I'm trying

`(&(objectClass=inetOrgPerson)(memberOf=cn=internal,ou=people,dc=company,dc=com))`

Thanks!

Accepted answers

All comments

AnnWorley

Hello! I understand you want to use a nested group in LDAP to assign application access in Crowd, but first we have to sync over the members of that group. You didn't mention what LDAP directory service you are using but since Active Directory is the most common, I wanted to let you know about the nested group attribute that has to be added for AD. Please see: How to write LDAP search filters

The example in the guide is:

(&(objectCategory=Person)(sAMAccountName=*)(memberOf:1.2.840.113556.1.4.1941:=cn=CaptainPlanet,ou=users,dc=company,dc=com))

For your filter it would be more like:

(&(objectClass=inetOrgPerson)(memberOf:1.2.840.113556.1.4.1941:=cn=internal,ou=people,dc=company,dc=com))

If you are not using Active Directory please let me know what LDAP you are using so I can research further.

Sys Admin_oc5n5o

Hi Ann,

we're using an underlying OpenLDAP server, the one bundled with Crowd.

I've already taken a look at that page, but we cannot use the "memberOf" attribute since it doesn't exist among the inetOrgPerson objects in the LDAP.

Our implementation has enabled the "nested groups" configuration of Crowd.

AnnWorley

I cannot find an OpenLDAP server bundled with Crowd, but I have heard of OpenLDAP. You are right that the memberOf attribute is not present by default in OpenLDAP. Without an equivalent attribute to search on we will not be able to filter users by group membership.

However, once the users are in Crowd, you can use the group to allow authentication to the specific application: Specifying which Groups can access an Application

I found instructions for adding memberOf to an OpenLDAP instance: How to enable MemberOf using OpenLDAP

A limitation I noticed is that it only applies the attribute when a new group is created, it wouldn't apply to your existing groups. Depending on how many groups you need the attribute for, that could be a lot of trouble or just recreating a couple of groups.

Sys Admin_oc5n5o

We used to have this memberOf setting but we have to disable it to enable nested groups in Atlassian applications. I'm afraid if we enable it again we will lose access to Jira, Confluence, Bitbucket and others. Isn't there any other solution to retrieve all members (direct and inherited) of a group (objectClass=groupOfUniqueNames) ?

AnnWorley

It turned out that the question was not about using Crowd for the applications, it was regarding whether changing the OpenLDAP schema to accommodate other apps will break Crowd. The recommendation was to try on a test instance first to avoid surprises in Production.

If changing the OpenLDAP schema leaves the attributes in place that Crowd uses in the User Directory setup, then Crowd would not be negatively impacted; but a test instance is the best way to make sure the changes don't interfere with Crowd.

Welcome!

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

Quick Links

Find more posts tagged with

crowd

user

ldap