If you haven’t already checkout part 1 of this guide.
So we have already started to setup the permissions and roles, the challenge we have now is how do we implement these permissions without creating pandemonium.
My preferred solution is a sudo greenfields build. I like to carve out an area within Active Directory to create a new OU that will in time hold all the user, groups and devices.
The reason I prefer this type of greenfield migration approach is that you can gradually move different business areas into the new location, you can ensure permissions are correct and no spurious permissions have snuck in before ever having to impact users and systems. It also provides the option to backout the changes quickly should the worst happen.
OU Structure
The below is a demonstration of the type of structure I like to setup. This layout works nicely for setting AD permissions, and for nesting GPO settings in a simplified form. (More on that later) You can omit the Corporate level OU but I find its good to keep everything in one area and in time decommission all other non default OUs into this location. Again your structure might vary depending on requirements but initially we want to sort everything into three areas.
- Devices – This is all the different devices shown in active directory. I generally then group those devices by common types, Laptops, Workstations, VDI, Servers etc as this allow a simplification of GPO’s later on. It also allows the segregation of permissions. Often the VDI desktops are administered by a different team to Laptops/Workstations for instance.
- Groups – The only important OU’s here are Administration and Server Permissions OU. These are high level important groups that are restricted. Also if you have some sort of auditing enabled you can enable auditing on all groups in these OU’s and have a pretty solid grasp of things without to much white noise. The rest of the folders are really to help group types of groups together for easier administration.
- Users – The important OU’s here are Administrators, Disabled Users and Service Accounts. Administrators and Service Accounts are high level important OU’s which are restricted and monitored. The reason I focus on Disabled Users is that generally speaking a disabled user should not be enabled without a managers approval so as a general rule of thumb first line service desk don’t have permission to do this.
Setting Permissions
Now we have the OU structure we can match and document the permission structures. Below is the general permission structure I setup.
You can fine tune this as much as you would like but again this is a simple way to document and highlight who has what permissions to which areas of AD.