I would have to say that this topic is probably one of the biggest pet peeves of mine in the Information Technology field. Why do Systems Administrators not use Security Groups correctly (mind you, Microsoft administrators usually)? Why do I go to a site and most often find that permissions are given directly to a leaf object (user) and not to a security group? How does an administrator worth their salt get away with this and more importantly, why do they want to do this? It ends up creating more work in the end and clutters Active Directory.
It’s really not hard to follow the following principle, IGDLA, but it is if the system has already been in use for quite some time. In order to correct this situation, generally, a forklift upgrade would have to take place.
So, you are probably wondering what IGDLA is? It’s actually an acronym that stands for the following:
I – Identities (user objects)
G – Global groups (containers to hold user objects with common functions, Human Resources, Information Technology, Supervisors, etc)
DL – Domain local security groups (these are where the permissions are actually applied)
A – Access (this is the access given to the DL, such as, read or read and write)
What’s confusing to a lot of administrators is when it comes to nesting. They get too granular and then the system just breaks down and they start to throw individuals in and give them permissions. The problem with this is when that particular user leaves the organization or no longer requires that access, there is no easy way to enumerate all the places they had access to and remove it.
Let’s use the following image as an example to work with.
At a minimum, an organization should have a security group created to contain users who perform similar functions. Users can, and usually are, part of more than one security group. For instance, in my organization, I am part of the ‘Information Technology’ team. More specifically, I am a Server Administrator and have an office symbol. Everyone with the same office symbol performs a similar function, we are part of a group. I would be part of the ‘Server Team’ security group.
Now let’s also imagine that I am part of a morale committee called, Fish! (based off the novel, Fish!: A Proven Way to Boost Morale and Improve Results, by Stephen C. Lundin). I would also belong to a security group called ‘Fish Committee’. In this group with me are various other people in the organization.
Starting Out, On Boarding
On-boarding, join an organization and get placed into correct department security group
IT sets up a file plan and sets file access appropriately. This means that when you are placed into the one security group, your department group, it will be nested in all the appropriate places you need access for. If you find that you do not have access to something, maybe it is due to fulfilling, or not as a matter of fact, a different role. This means the role based access is working correctly. You do not have the need to know in the role you are assuming and therefore do not require the access you seek. If you are truly in another role, then once you are placed in that role’s security group, you will have the access you require, nothing more.
Off boarding
When you have decided to leave the organization, or the decision has been made for you, the IT staff only needs to disable your account in one place. All of the groups you were a part of can be removed and they are done at that point. There is no digging around looking for where you may have had access to.
Notes
MongoDB 4 Quick Start Guide Published by Packt Publishing, 2018
Role-based access control It’s important to note the difference between a role (https://docs.mongodb.com/manual/core/authorization/#role-based-access-control) and a user. Privileges are granted to roles. Roles, in turn, are assigned to users. This arrangement vastly minimizes the complications which could arise as the numbers of database users increases. In addition, one role can inherit from another, which allows you to create a hierarchy of privileges and minimize the number of assignments which need to be made.
Ideas
- Roles with regards to accessing Organization file plans
- Roles with regards to Microsoft Active Directory
Benefits
- Users share the same permissions (uniform)
- Can easily enumerate a user’s access
Pitfalls
- Hard to implement after a system has already been established
- Must teach junior administrators the correct method