All Versions
User Management 5.0 DocumentationUser Management 4.0 Documentation
User Management 3.0 Documentation
More...
This section summarises the effect nested groups will have on login and permissions, and on the viewing and updating of users and groups.
When a user logs in, they will be allowed access to the application if they belong to an authorised group or any of its sub-groups.
The user will be allowed access to a function if they belong to a group that has the necessary permissions, or if they belong to any of its sub-groups.
If you ask to view the members of a group, you will see all users who are members of the group and all users belonging its sub-groups, consolidated into one list. We call this a 'flattened' list.
You cannot view or edit the nested groups themselves. You will not be able to see that one group is a member of another group.
If you add a user to a group, the user is added to the named group and not to any other groups.
If you try to remove a user from a flattened list, the following will happen:
Let's assume that the following two groups exist in your directory server:
staffmarketingMemberships:
marketing group is a member of the staff group.jsmith is a member of marketing.You will see that jsmith is a member of both marketing and staff. You will not see that the two groups are nested. If you assign permissions to the staff group, then jsmith will get those permissions.
In an LDAP directory server, we have groups 'engineering-group' and 'techwriters-group'. We want to grant both groups developer-level access to our JIRA site.
Group memberships are now:
When JIRA requests a list of users in the 'jira-developers' group, it will receive the following list:
Diagram: Sub-groups as members of the 'jira-developers' group
In an LDAP directory server, we have groups 'engineering-group' and 'payroll-group'. We want to grant both groups access to our Confluence site.
Group memberships are now:
When Confluence requests a list of users in the 'confluence-users' group, it will receive the following list:
Diagram: Sub-groups as members of the 'confluence-users' group
objectClass=group attribute and one or more member=DN attributes, where the DN can be that of a user or that of a group elsewhere in the LDAP tree:
member=CN=John Smith,OU=Users,OU=OrgUnitA,DC=sub,DC=domain member=CN=Group Two,OU=OrgUnitBGroups,OU=OrgUnitB,DC=sub,DC=domain