Rethinking Active Directory Organisational Unit Structure and Permissions – Part 1

“Does history repeat itself, the first time as tragedy, the second time as farce? No, that’s too grand, too considered a process. History just burps, and we taste again that raw-onion sandwich its swallowed centuries ago.” – Julian Barnes

BACKGROUND

Organisational Unit (OU) structures are ubiquitous in most companies. You have OUs for your users, workstations, servers and service accounts, but this can come at a cost:

• Once administrative users have been granted a level of access, they can generally administrate all objects in Active Directory (AD)
• As administrators come and go, the history of how and why objects were named, and their purpose can become lost (What the hell is the svc_mq12ui2 user account used for? Does anyone know what group to add people to when they need access to the XYZ application?)
• Test objects get mixed up with production ones
• GPO’s are poorly named, and no one can remember their purpose (‘Fix_Registry_Issue’)
• Changes are made without appropriate change control
• Objects are in the wrong OUs. Computer accounts in Group OUs and Groups in OUs for Service Accounts
• Service Accounts are reused for multiple applications leading to issues if their password is reset. Service accounts for clusters anyone?
• All the administrators are members of the Domain Admins group. <Sarcasm> and after all, why not? </Sarcasm>

So, what do we want to achieve here? How do we prevent ‘organic growth’? Let’s make some assumptions:

• We want to break the ‘everyone who needs to administrate something in AD should be made a member of the Domain Admins group’ paradigm. Domain Admins should be few and ideally only used as ‘break-glass’ accounts
• Administrators should only be able to administrate applications or services that fall under their remit
• An administrator should not be allowed to add themselves to an administrative group; this should only be possible under Change Control (regular or emergency)
• We would like to know at a glance, what makes up an application service including:
  • Service Accounts
  • Groups
  • Computer Accounts
• Changes to the production OU structure should only be made under change control and only after they have been tested in Test/Dev

MY SOLUTION

“This is my solution. There are many like it, but this one is mine. My solution is my best friend. It is my life. I must master it as I must master my life. Without me, my solution is useless. Without my solution, I am useless. “ – With apologies to Major General William H. Rupertus

Environments

Firstly, let’s start by defining our environments. We need at least two: Production and TestDev. The same OU structures and permission sets will be generated for each environment. Under each environment, there are some basic OUs used for user and workstation accounts.

Note: Your mileage may vary – design this part according to your company’s needs!

The Service Catalogue

Now we create a new root ‘Service Catalogue’ OU in each environment. Its purpose is to act as a container for all the application OU structures – if you think of a better, more accurate name, please let me know!

Then we can start creating sub-OUs for each application service; in the example, I have created OUs for Service Accounts, Groups and Computer Accounts.

What do we hope to achieve here? For one, we can group everything to do with an application together. No more ‘Honey, have you seen my Service Account’?

More than that, we present an option to manage the lifecycle of an application. When a new application is commissioned, or an old one is decommissioned, everything related to it is stored under its root OU. Think of migrating from one application version to another – can you always ensure that you have removed all traces of the old installation once the new one is in place? What about if you migrate from Product A to Product B?

OU Administration

In order to control access to different parts of the new OU structure, there needs to be a separate area which is only accessible to members of the Domain Admins group. In here we will place administrator user accounts and groups which allocate permissions to other OUs in AD.

It may be easier to picture this visually:

The ‘OU Admins’ OU will contain administrative accounts for technical staff. These administrative accounts will be added to AD groups in the ‘OU Permissions Allocation Groups’ OU. For instance, ‘App1-FullAdmin-Production’, ‘App2-ReadOnlyAdmin-TestDev’ etc.

In turn, these AD groups will be granted appropriate levels of privilege to their specific application only. For instance, ‘App1-FullAdmin-Production’ will only be allowed to create, delete and modify objects under ‘OU=App1, OU=ServiceCatalog, OU=Production, DC=MyDomain, DC=com’.

Next, we can start to define some of the delegated permission sets we need to apply to these new OU’s. These permission sets will still have some restrictions, for instance, even a full ‘App1’ administrator should only be allowed to add a user account to the ‘Service Accounts’ OU but not computer accounts.

But then, what about administrative groups who should only have rights to add an object, but not delete it? What about the security application which requires read-only access?

A basic list of security groups for each application may include (and again, your mileage may vary):

• App1-FullAdmin-Production
• App1-AddOnlyAdmin-TestDev
• App1-ReadOnlyAdmin-Production

The permissions (and how to achieve this) will be detailed in the next instalment of this blog.

Scripting the Solution

Experience shows it is better to implement this solution as two scripts rather than one. The first creates the OU structures, groups and permissions for the ‘foundational’ OUs. The second creates and configures OUs for a specific application.

The first script:

• Creates the OU structure for:
  • The permission granting root OU
  • Each environment OU and its associated sub-OUs
• Creates administrative groups for the functional OUs (who can create workstation or vendor user account objects? etc.) and places them into the ‘OU Permission Allocation Groups’ OU
• Sets delegated permissions on each OU for each relevant group
• Imports and links relevant Group Policy Objects

The second script creates an entry under the ‘Service Catalogue’ OU for an application. Generally, it is designed to run from a command line and can either take a name, environment and description directly or from a CSV file. It:

• Creates the OU structure in the Service Catalogue for the application including sub-0Us for Groups and Computer objects
• Creates OU specific administrative groups for the application under the ‘OU Permission Allocation Groups’ OU
• Creates AD groups for the application under the ‘Security Groups’ OU. These groups allow login privilege to the application for general access or administration
• Sets delegated permissions

The Operational Experience

The Finance Department would like a new application set up in your corporate environment. However, there are some stipulations:

• The application is considered business-critical. Not just anyone should be allowed to administrate its objects in AD or the application itself
• It will require a test environment in order to verify changes before configuring them, via change control, in production
• Changes to this environment may only be made under change control. To reduce the risk of administrative errors or malicious intent, no one should be a member of the administrative group unless the Change Authority Board (CAB) has authorised it

The process to achieve this is:

• Run the script which creates a new entry under the TestDev ‘Service Catalogue’ OU. This must be performed by a Domain Administrator under a Change Request (CR)
• Repeat the previous step for the Production environment
• Add the relevant administrators to the newly created AD groups under ‘OU Permission Allocation Groups’
• Build and configure the application in both environments
• Remove the administrators from the ‘OU Permission Allocation Groups’ OU

Coming up in part 2

In the next part of this blog, I’ll describe my solution for managing permissions in this brave new ‘Application Service Catalogue’ orientated world.