Documentation for Crowd 2.7. Documentation for earlier versions of Crowd is available too.

Skip to end of metadata
Go to start of metadata

This page provides details of Crowd's behaviour when there is more than one directory mapped to an application.

Note: This information is relevant to only those configurations that have duplicate usernames across directories and multiple directories mapped to a single application. In most cases, you do not need to know Crowd's behaviour to the level described on this page.

In summary:

  • Operations on users execute on the first user found in the list of assigned directories for an application.
  • Operations on groups execute on all assigned permissible directories. This means that groups can have memberships in more than one directory.

The table below describes the behaviour of the individual operations.

Operation

Behaviour

findUserByName, findGroupByName

Finds the first user/group by matching the desired name in the ordered list of directories mapped to the application. The match is case insensitive.

authenticate

Authenticates against the user returned by findUserByName.

addUser

Adds the user to the first directory mapped to the application that has permission to add users.

addGroup

Adds the group to all directories mapped to the application that have permission to add groups.

updateUser, removeUser

Updates/removes the user returned by findUserByName. Only operates on one directory.

updateGroup, removeGroup

Updates/removes the group in all directories mapped to the application in which the group exists where the application has the permissions to update/remove the group.

searchUsers, searchGroups

Finds the users/groups matching the search criteria by searching all directories mapped to the application. Returns an amalgamated result.

findUserMembersOfGroup

Finds the user members of the specific group in all directories mapped to the application. Returns an amalgamated result.

findGroupMembershipsOfUser

Finds the group memberships of the specified user returned by findUserByName. Only operates on one directory.

isUserGroupMember

Determines if the user returned by findUserByName is a member of the group in the same directory as the user. Only operates on one directory.

addUserToGroup

Adds the user returned by findUserByName to the group in the same directory. If the group does not exist in the directory, it is created automatically. Only operates on one directory.

removeUserFromGroup

Removes the user returned by findUserByName from the group. Only operates on one directory.

RELATED TOPICS

Mapping a Directory to an Application
Specifying the Directory Order for an Application

  • No labels

5 Comments

  1. Ok, you change the behaivior of crowd here completely and the change is mentioned in Crowd 2.1 Upgrade Notes. But: we have to rewrite the way we manage our group memberships completely. Bad, Bad Idea! Now all jira-groups have to be visible also in confluence (sad). But with ldap-caching (we have nested groups) enabled, maybe we will have a better, at least an other solution, than before...

  2. I agree with Paulo about this being a bad, bad idea!

    It seems to have completely broken delegated authentication. In crowd 2.0 and before, we delegate authentication to an AD server, but the AD groups don't map very well to our needs, so we use Crowd to manage groups.

    We now have to stay at Crowd 2.0 until we can completely replace Crowd with LDAP.

  3. I agree with others. What is the benefit of having multiple directories per application then. The first matched directory is used both for authentication and to extract the groups of a user. No way to configure an application to authenticate against one directory and get the memberships from another directory.

    We were also planning to buy Crowd for a large installation consisting more than 200 developers (+ Analysts), however in this case it does not seem to be so convenient for us.

    BTW, is there anyone to explain this strange choice of behavior?

  4. Anonymous

    +1 for the above 3 comments.    If you have an application talking to Crowd you MUST have a way for the groups for that application to be just for that application and not visible by other apps,  but users need to have access to multiple apps with SSO - otherwise Crowd is always going to be half broken.   

    I'll look for / open an issue folks can vote on, but I've been working extensively with Crowd now for about a year and a half mixed in with over a dozen applications and I cannot think of a more critical issue.

  5. This page should also describe how Crowd handles users that are not active, i.e. "Active" is unchecked in the User Details page. Apparently Crowd always rejects access for an inactive user, but this is somewhat unintuitive in multiple directory scenarios.

    Example: Crowd has two directories, Crowd Internal Directory and AD Delegated Authentication Directory (AD DA)

    • User A is inactive in the primary directory
    • User A is active in secondary directory

    Result: Crowd rejects access, because user A is found in the primary directory.

    In general, I would like to see a clearly written definition how Crowd behaves with inactive users.