Group Management Across an Organization

[NVergin]

I'm curious how others are dealing with the issue of trying to organize and manage groups across your organization's IT/business systems.  I'm working on a plan to do a full company-wide review of all the various types of groups across our system to try and bring some order to the "chaos."   Ok, chaos might be a bit of an exaggeration, but there is definitely room for improvement.  As we are looking to enhance our security/compliance and automate more and more functions, it becomes increasingly important to know what groups belong to what systems, prevent unnecessary, overlapping, or orphaned groups, and have a clear understanding of who is a part of those groups and why.

For example, within JumpCloud, I use a lot of prefixes when naming things so that I can keep similar groups together, such as software deployment groups, SSO groups, policy groups, patch management groups, department-based device groups, department-based user groups, etc, etc.  And all the names try to make it very clear who a group applies to or what its purpose is.

Do you try and keep names consistent across systems or is that not a concern?  So for instance "Engineering" in one system should be identical in both naming and membership with "Engineering" in another?  How do to manage the creation of new groups?  For instance Google Groups...  Is that ability controlled by IT or do users have the ability to do so?

I'd enjoy hearing how others have approached this wide-ranging topic within your organizations and if you've found things that worked well or perhaps things that seemed like a good idea at the time, but ended up not panning out with actual use.

[BenGarrison]

I was always curious how organizations with multiple groups did this. I have seen a few examples but definitely worth sharing some best practices here.

[steven]

So I just did this a month ago or so, and ran into the same issue of "How the he11 do I organize this to make sense for scalability". I've split this into a few sections, so you can see how I set it up across the board.

User Group

• All *** - Currently only 1 of these (Employees). The main purpose of this group is to manage the Google Workspace connection. It also adds them to a staff-wide Google Group (staff@) and gives them some SSO apps that the entire company needs.
• Devs *** - These groups contain the developers for each team & division. These are used to handle SSH access to our various servers.
• Group *** - This manages default Google Groups, and handles "Target Audiences" in Google Workspace as well. I think only one of the divisions use this for division-wide emails. Some of them (Such as Group - Developers) grant all developers access to SSO apps too.
• SSO *** - Pretty self explanatory. Grants access to various SSO apps.
• z_Service Account - This group contains one user "Webspec Service Account", it is added to all of our employee computers in the event I need to access one and the employee isn't available (Either OOO or has left the company)

Device Groups

• Computers - All -- This contains all of our employees computers, and we have all of our policies & most of our software applied to this group. This is also the group that the user group "z_Service Account" is attached to.
• Computers - Employees -- We have 2 computers that are in conference rooms, that need the "Guest Account" enabled on them. Computers - All has a policy that disables the Guest Account, so I created this to just handle the very few computers that need it.
• Computers - Developers -- Only thing this does is installs software that only developers need.
• Patch Mgmt *** - Patch Management groups for the four "tiers"!
• Servers - *** - These groups match up exactly with the user group "Devs - ***". Allows only certain devs SSH access to certain servers.

Google Groups

We do manage some groups through JumpCloud, but we have quite a few other groups that aren't managed through JC just because it doesn't make sense to. Anyone in our organization can create groups, since it doesn't cost us money we don't really care, haha. The groups that JumpCloud does manage, we don't add any 'managers' or 'owners' to them so people can't invite members who aren't supposed to be in it!

I hope this helps, it's a pain to structure these for scalability and usability.