Mirrored groups in Crowd Internal Directory

Jeffrey Wilson

I have inherited administration of my company's Atlassian products, including Crowd Server.

I am doing some housekeeping and it appears that a previous admin had attempted at one time to set up a Delegated directory, ditched it and went on to implement a Microsoft Active directory instead.

The Delegated directory is de-activated so I presently have an MS AD directory and an Internal Directory active.

It appears that as a result of the previous attempt at setting up a Delegated directory, all of the default groups exist in both the MS AD and Internal directories - confluence-developers, confluence-users, jira-developers and so on. Theses groups are "Active" in both the MS AD and Internal directories, but it appears that all of my users are being pulled from MS AD and that there are no users that are members in the "mirror" groups that exist in the Internal Directory.

$10,000 question - Can I delete the mirrored groups from the Internal Directory or are they there for some reason other than the probably unsuccessful attempt at setting up a Delegated directory? Again, I have looked at the groups in the Internal Directory and they have no Direct or Nested members and a a random sampling of my users shows that they are all coming from the MS AD directory.

I want to use the Internal directory for creating special groups so that I can limit their access to Applications via Crowd. (which seems to be the way to do it.)

Just don't want to start removing groups and get a million phone calls because users can't access their apps.

Thanks!

 

Damien Tan

Hey @Jeffrey Wilson

 

Groups that are mapped to the applications in Crowd always follow the directory where it came from. So even if you have 2 groups with the exact same name, as you can see they are both under different directories (in your case, one belong to your Internal Directory another one belong to AD)

 

You'll need to confirm is the Internal Directory mapped to the application in the first place, if it is not mapped to the application, removing the group won't affect the access to your application at all.

If the Internal Directory is in fact mapped to the application, just double confirm again if there is any direct or nested member in it. if it is empty, then removing the group won't affect your users on accessing as well.

 

From my understanding, the "mirrored group" seems to be empty so it is safe to be removed. You'll find your users all located in the group that is coming from the AD instead

 

hope this help