{"id":1370,"date":"2019-12-16T01:00:00","date_gmt":"2019-12-16T01:00:00","guid":{"rendered":"http:\/\/inswwdev.azurewebsites.net\/au\/insights\/uncategorized\/rethinking-active-directory-organisational-unit-structure-and-permissions-part-1\/"},"modified":"2019-12-16T01:00:00","modified_gmt":"2019-12-16T01:00:00","slug":"rethinking-active-directory-organisational-unit-structure-and-permissions-part-1","status":"publish","type":"post","link":"https:\/\/www.insentragroup.com\/gb\/insights\/geek-speak\/modern-workplace\/rethinking-active-directory-organisational-unit-structure-and-permissions-part-1\/","title":{"rendered":"Rethinking Active Directory Organisational Unit Structure and Permissions &#8211; Part 1"},"content":{"rendered":"<p style=\"text-align: justify;\"><em>\u201cDoes history repeat itself, the first time as tragedy, the second time as farce? No, that&#8217;s too grand, too considered a process. History just burps, and we taste again that raw-onion sandwich its swallowed centuries ago.\u201d &#8211; Julian Barnes<\/em><\/p>\n<h4 style=\"padding-bottom: 15px; margin-bottom: 30px; margin-top: 40px; border-bottom: 1px solid #f16020;\">BACKGROUND<\/h4>\n<p>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:<\/p>\n<ul>\n<li>Once administrative users have been granted a level of access, they can generally administrate all objects in Active Directory (AD)<\/li>\n<li>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 <em>svc_mq12ui2<\/em> user account used for? Does anyone know what group to add people to when they need access to the XYZ application?)<\/li>\n<li>Test objects get mixed up with production ones<\/li>\n<li>GPO\u2019s are poorly named, and no one can remember their purpose (\u2018Fix_Registry_Issue\u2019)<\/li>\n<li>Changes are made without appropriate change control<\/li>\n<li>Objects are in the wrong OUs. Computer accounts in Group OUs and Groups in OUs for Service Accounts<\/li>\n<li>Service Accounts are reused for multiple applications leading to issues if their password is reset. Service accounts for clusters anyone?<\/li>\n<li>All the administrators are members of the Domain Admins group. &lt;Sarcasm&gt; and after all, why not? &lt;\/Sarcasm&gt;<\/li>\n<\/ul>\n<p>So, what do we want to achieve here? How do we prevent \u2018organic growth\u2019? Let\u2019s make some assumptions:<\/p>\n<ul>\n<li>We want to break the \u2018everyone who needs to administrate something in AD should be made a member of the Domain Admins group\u2019 paradigm. Domain Admins should be few and ideally only used as \u2018break-glass\u2019 accounts<\/li>\n<li>Administrators should only be able to administrate applications or services that fall under their remit<\/li>\n<li>An administrator should not be allowed to add themselves to an administrative group; this should only be possible under Change Control (regular or emergency)<\/li>\n<li>We would like to know at a glance, what makes up an application service including:\n<ul>\n<li>Service Accounts<\/li>\n<li>Groups<\/li>\n<li>Computer Accounts<\/li>\n<\/ul>\n<\/li>\n<li>Changes to the production OU structure should only be made under change control and only after they have been tested in Test\/Dev<\/li>\n<\/ul>\n<h4 style=\"padding-bottom: 15px; margin-bottom: 30px; margin-top: 40px; border-bottom: 1px solid #f16020;\">MY SOLUTION<\/h4>\n<p style=\"text-align: justify;\"><em>\u201cThis 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. \u201c &#8211; With apologies to Major General William H. Rupertus<\/em><\/p>\n<p><strong>Environments<\/strong><\/p>\n<p>Firstly, let\u2019s 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.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/20\/2021\/02\/blog_rethinking_active_directory_img_1.jpg\" alt=\"\" data-udi=\"umb:\/\/media\/545ff73d505248edbf1b651ef209b1d7\" \/><\/p>\n<p>Note: Your mileage may vary \u2013 design this part according to your company\u2019s needs!<\/p>\n<h4 style=\"padding-bottom: 15px; margin-bottom: 30px; margin-top: 40px; border-bottom: 1px solid #f16020;\">The Service Catalogue<\/h4>\n<p>Now we create a new root \u2018Service Catalogue\u2019 OU in each environment. Its purpose is to act as a container for all the application OU structures &#8211; if you think of a better, more accurate name, please let me know!<\/p>\n<p>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.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/20\/2021\/02\/blog_rethinking_active_directory_img_2.jpg\" alt=\"\" data-udi=\"umb:\/\/media\/9ccb50f15fa04e709e3cb6b40e88aa6a\" \/><\/p>\n<p>What do we hope to achieve here? For one, we can group everything to do with an application together. No more \u2018Honey, have you seen my Service Account\u2019?<\/p>\n<p>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 \u2013 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?<\/p>\n<h4 style=\"padding-bottom: 15px; margin-bottom: 30px; margin-top: 40px; border-bottom: 1px solid #f16020;\">OU Administration<\/h4>\n<p>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.<\/p>\n<p>It may be easier to picture this visually:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/20\/2021\/02\/blog_rethinking_active_directory_img_3.jpg\" alt=\"\" data-udi=\"umb:\/\/media\/da7df469e2fa440ab06c686b141cf50f\" \/><\/p>\n<p>The \u2018OU Admins\u2019 OU will contain administrative accounts for technical staff. These administrative accounts will be added to AD groups in the \u2018OU Permissions Allocation Groups\u2019 OU. For instance, \u2018App1-FullAdmin-Production\u2019, \u2018App2-ReadOnlyAdmin-TestDev\u2019 etc.<\/p>\n<p>In turn, these AD groups will be granted appropriate levels of privilege to their specific application only. For instance, \u2018App1-FullAdmin-Production\u2019 will only be allowed to create, delete and modify objects under \u2018OU=App1, OU=ServiceCatalog, OU=Production, DC=MyDomain, DC=com\u2019.<\/p>\n<p>Next, we can start to define some of the delegated permission sets we need to apply to these new OU\u2019s. These permission sets will still have some restrictions, for instance, even a full \u2018App1\u2019 administrator should only be allowed to add a user account to the \u2018Service Accounts\u2019 OU but not computer accounts.<\/p>\n<table border=\"0\" class=\"minimalistBlack\">\n<thead>\n<tr>\n<td width=\"198\">\n<p>OU Name<\/p>\n<\/td>\n<td width=\"302\">\n<p>Purpose<\/p>\n<\/td>\n<td width=\"179\">\n<p>Permitted Object-Type<\/p>\n<\/td>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td width=\"198\">\n<p>App1ComputerAccounts<\/p>\n<\/td>\n<td width=\"302\">\n<p>Contains all Computer Accounts for servers and systems relating to a specific application<\/p>\n<\/td>\n<td width=\"179\">\n<p>Computer Accounts<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td width=\"198\">\n<p>App1ServiceAccounts<\/p>\n<\/td>\n<td width=\"302\">\n<p>Contains all Service Accounts relating to a specific application<\/p>\n<\/td>\n<td width=\"179\">\n<p>User accounts<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td width=\"198\">\n<p>App1SecurityGroups<\/p>\n<\/td>\n<td width=\"302\">\n<p>Contains all Security Groups relating to a specific application<\/p>\n<\/td>\n<td width=\"179\">\n<p>Groups<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>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?<\/p>\n<p>A basic list of security groups for each application may include (and again, your mileage may vary):<\/p>\n<ul>\n<li>App1-FullAdmin-Production<\/li>\n<li>App1-AddOnlyAdmin-TestDev<\/li>\n<li>App1-ReadOnlyAdmin-Production<\/li>\n<\/ul>\n<p>The permissions (and how to achieve this) will be detailed in the next instalment of this blog.<\/p>\n<h4 style=\"padding-bottom: 15px; margin-bottom: 30px; margin-top: 40px; border-bottom: 1px solid #f16020;\">Scripting the Solution<\/h4>\n<p><span>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 \u2018foundational\u2019 OUs. The second creates and configures OUs for a specific application.<\/span><\/p>\n<p><span>The first script:<\/span><\/p>\n<ul>\n<li>Creates the OU structure for:\n<ul>\n<li>The permission granting root OU<\/li>\n<li>Each environment OU and its associated sub-OUs<\/li>\n<\/ul>\n<\/li>\n<li>Creates administrative groups for the functional OUs (who can create workstation or vendor user account objects? etc.) and places them into the \u2018OU Permission Allocation Groups\u2019 OU<\/li>\n<li>Sets delegated permissions on each OU for each relevant group<\/li>\n<li>Imports and links relevant Group Policy Objects<\/li>\n<\/ul>\n<p>The second script creates an entry under the \u2018Service Catalogue\u2019 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:<\/p>\n<ul>\n<li>Creates the OU structure in the Service Catalogue for the application including sub-0Us for Groups and Computer objects<\/li>\n<li>Creates OU specific administrative groups for the application under the \u2018OU Permission Allocation Groups\u2019 OU<\/li>\n<li>Creates AD groups for the application under the \u2018Security Groups\u2019 OU. These groups allow login privilege to the application for general access or administration<\/li>\n<li>Sets delegated permissions<\/li>\n<\/ul>\n<p><strong>The Operational Experience<\/strong><\/p>\n<p>The Finance Department would like a new application set up in your corporate environment. However, there are some stipulations:<\/p>\n<ul>\n<li>The application is considered business-critical. Not just anyone should be allowed to administrate its objects in AD or the application itself<\/li>\n<li>It will require a test environment in order to verify changes before configuring them, via change control, in production<\/li>\n<li>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<\/li>\n<\/ul>\n<p>The process to achieve this is:<\/p>\n<ul>\n<li>Run the script which creates a new entry under the TestDev \u2018Service Catalogue\u2019 OU. This must be performed by a Domain Administrator under a Change Request (CR)<\/li>\n<li>Repeat the previous step for the Production environment<\/li>\n<li>Add the relevant administrators to the newly created AD groups under \u2018OU Permission Allocation Groups\u2019<\/li>\n<li>Build and configure the application in both environments<\/li>\n<li>Remove the administrators from the \u2018OU Permission Allocation Groups\u2019 OU<\/li>\n<\/ul>\n<p><strong>Coming up in part 2<\/strong><\/p>\n<p>In the next part of this blog, I\u2019ll describe my solution for managing permissions in this brave new \u2018Application Service Catalogue\u2019 orientated world.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u201cDoes history repeat itself, the first time as tragedy, the second time as farce? No, that&#8217;s too grand, too considered a process. History just burps, and we taste again that raw-onion sandwich its swallowed centuries ago.\u201d &#8211; Julian Barnes BACKGROUND Organisational Unit (OU) structures are ubiquitous in most companies. You have OUs for your users,&hellip; <a class=\"more-link\" href=\"https:\/\/www.insentragroup.com\/gb\/insights\/geek-speak\/modern-workplace\/rethinking-active-directory-organisational-unit-structure-and-permissions-part-1\/\">Continue reading <span class=\"screen-reader-text\">Rethinking Active Directory Organisational Unit Structure and Permissions &#8211; Part 1<\/span><\/a><\/p>\n","protected":false},"author":88,"featured_media":1371,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[19],"tags":[],"class_list":["post-1370","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-modern-workplace","entry"],"_links":{"self":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/posts\/1370","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/users\/88"}],"replies":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/comments?post=1370"}],"version-history":[{"count":0,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/posts\/1370\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/media\/1371"}],"wp:attachment":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/media?parent=1370"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/categories?post=1370"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/tags?post=1370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}