Missing Classes

[PatrickOnGit]

The tool only allows for worksations, users and groups as class. What about servers? And how to implement different OUs to apply GPOs based on OU level and not using permissions?

[merddyin]

The second layer of the structure splits objects into what are referred to as 'Focus' OUs. Focus OUs separate objects by concern, be that Administrative control (ADM), Standard unprivileged objects (STD), Staging for finalization of build (STG), or finally Servers (SRV). At the end of the day, other than Domain Controllers, AD doesn't differentiate between a server computer object and a workstation from a class perspective. Servers get their own Focus for a variety of reasons, one of which is that most environments where I have used this tool need specific and separate OU structures for servers than for everything else. Also, since most servers are generally centrally located, with the exception of some minor outliers in branch locations for some orgs, it doesn't make sense to follow the same location type of structure approach. That said, another update that I have queued up adds additional flexibility to OU structuring, as this version still requires a consistent structure under each Focus, other than STG. The new updates, which I am still testing, are able to support renaming of core OUs, and a differentiated structure for each Tier and Focus...even the ability to turn a focus off for a given Tier.

[PatrickOnGit]

Thank you for your feedback. I do agree that the OU structure does not need to, or even shouldn't, follow location or worse organisation structure. It is used to either implement operations models using AD delegation or support applying GPOs to groups of server or computer. And it would be great if the tool allows for more flexibility. So far I would need to create different SLOs to provide different OUs to manage groups of servers. When do you think you do have an updated version of the tool? I guess enhancement or question would be the better label for this issue.

[merddyin]

So, to a degree, the current working code base does offer improved flexibility. It allows for customization of the names, and variation of structure between Tiers and Focuses to a substantial degree without worrying that it will break the automated deployment capability. For example, the three Tier layer OUs can be renamed to something else, but they are always deployed. Under this, the Focus layer OUs can again be renamed, or you can disable deployment of some Focus OUs for some Tiers (e.g. if you don't want Staging or Standard OUs for Tier-0, you can disable deployment selectively), but a Focus layer is still necessary for other elements to work. For the SLO layer, you can deploy between one and three levels, and the current code base supports variation in path depth and makeup...so you could deploy one structure for Tier-2\STD, and a completely different one everywhere else, such as for Tier-1\SRV.

That said, the module is still intended to implement a specific security framework, and therefore there remain some limitations imposed by that framework. At a minimum, the Tier and Focus layers are required, and Admin Focus cannot be disabled as objects used for administrative control of AD need to be separated from those used for control of other access for things like shares or apps. You don't want the front-line helpdesk being able to reset passwords on service accounts or manage administrative access to AD. Nothing against helpdesk, but most are focused on closing tickets, not on whether or not something should be done, and it is a common point of breach through social engineering. As mentioned in another response, ideally you would want to use OUs only for delegation boundaries for the most part, or for GPO settings that can't be targeted using Policy Preferences. For everything else, you would leverage metadata through setting of various AD attributes (there's a lot that aren't used that are present on nearly all classes).

[merddyin]

So, minor bit of additional information, in the form of some pseudo documentation. This should enable you to define or customize the Class OUs that get created more or less as you please under the Admin and Standard Focus OUs. I would not suggest attempting to use this for Servers however. The cmdlet detects the Server Focus and handles it differently by treating the Scope OU as the Class OU, and ACLs are set there. Everything in the Server Focus should be a server, so it made little sense to me to create a separate Class OU. The Stage Focus does not use Class OU's by default, but by examining the AP_Objects table, you will see that it is supported if needed.

Class OUs are determined by the AP_Objects table. OBJ_refid - Determines the three character identifier, which is stamped on the object type, and also used for naming of the associated TDGs, if any OBJ_adclass - This maps a given object to a specific AD class, and it can be left blank for non-AD items, and it can be used to map multiple objects to the same type of class OBJ_category - This is essentially just a description field...it should be populated, but it isn't used by the tool anywhere OBJ_relatedfocus - This determines under which types of Focus the class OU, if defined, would be created, and where ACLs would be applied. In the event that a given class will be used with multiple Focus types, there should be an entry for each Focus, and each must have a unique reference ID. OBJ_TypeOU - This determines where in the structure this particular type of object should be found. Since there are multiple types of object that share a given class, and may even use the same OU, it is important that all AD objects are stamped with the correct reference type. This allows for auditing to ensure objects are in the correct location where you intend to grant access. This also allows legacy objects to be moved into the new structure without disruption, since we can tag the object instead if needed. Since we aren't setting ACLs based on the legacy names, the names are less important. TDG names remain explicit however, as we actively use the name to dynamically set access controls. OBJ_SubTypeOU - This is used purely for deployment of a second layer under the class OU for further organization for people who can't let go of the 'use OU as folders' mindset. No ACLs are set on this OU, only on the OBJ_TypeOU, and they inherit down to this level. The latest version of the module in the dev branch has no values populated for this column. OBJ_ItemType - This is essentially just a 'switch' of sorts that determines whether an OU is created or not. Ideally, you would only have one Primary for each Focus and object class. Items marked as Secondary are primarily used for auditing purposes, as objects would be stored alongside the primary. For example, standard security groups (Primary) are stored in Groups, and so are standard Distribution Groups (Secondary). The code accounts for duplicates, so no worries if too many of the same are created, it just slows things down a tiny amount since the dups have to be validated. OBJ_enabled - determines if the Object type is processed by the tool or not...setting a value of 0 means it won't get loaded into memory during module import. OBJ_AssignACLs - This is essentially a filter to determine if there are any specific ACLs to be set. Essentially this should be a 1 for any object type you have an associated PropGroup for. Generally speaking, I only map PropGroups (Task Groups) to primaries as there doesn't need to be a Task Group unless there is an associated OU to set ACLs on. Since all objects in a given class OU should be of the same AD class, there is no point having multiple Task Groups...it just creates mess. OBJ_TierAssoc - This determines which Tier, or Tiers that a given object may be found in. For example, Kiosks are only found in Tier-1 per the model, as these systems presumably require more stringent restrictions. I plan to convert this to a flag in the near future, but for the moment the mappings are shown below. 0 = All Tiers 1 = Tier 0 only 2 = Tier 1 only 3 = Tier 2 only 4 = Tiers 0 and 1 5 = Tiers 1 and 2 6 = Tiers 0 and 2 OBJ_Custom - You will see this one in various tables through the DB. The intent was to be able to differentiate things that were unique to a customer or environment by flagging them with a 1. There is no current implementation within the module that leverages this OU, but the intent was to enable a rapid 'reset' back to the initial defaults.

As another note: The AP_PropGroups table maps to AP_Objects via the OBJ_refid column, which is a foreign key. This determines which OU the ACLs are written to. The OBJ_destination also maps as a foreign key to AP_Objects, but this one determines which OU the associated Task Groups should be created in. At present, this should pretty much always be 15, which maps to the TDG object reference type, which maps to [Tier][Admin Focus][Scope OU/Global OU]\Tasks. In the event that a given environment wants to extend the Tasks model for use in creating non-privileged Roles, you could create TCG PropGroup definitions with no AD property mappings, and the destination would change to 71.

As for what I mean by the Role system, the intent is that no users are added directly to either TDG or TCG groups. Instead, you would create a Role Group, and the group would be nested into one or more Task Groups within the same Tier. The Role Groups would be associated to a specific job function, such as Level 1 Helpdesk Analyst for example, and all employees who are level 1 helpdesk analysts would be added to this Role Group. Each admin account would only get one Role Group. The Role Group would exist in each Tier where that Role has job duties. For example, if the server team and the AD team are the same people, and junior AD engineers are supposed to create AD groups in Tier 2 as well as perform basic troubleshooting, so a junior AD engineer role would exist in both Tier 1 and Tier 2, and the engineer would have an account for each Tier. The junior AD engineer should never be added to the level 1 helpdesk role however...each admin (and service account) gets only a single Role Group membership in a given tier...even if the rights are identical to another team (though that technically is a separation of duties issue), you simply create two roles with the same TDG memberships. The goal is to tie a set of rights to a single job function to enable birthright provisioning when someone new joins the team.

The one exception to this approach is for those handful of organizations who bought into the nonsense sold by password vaulting companies, so they elect to use Role Accounts instead of Role Groups. In this case, the account gets added directly to the TDG for users, and to a Role Group for service accounts...I suppose you could go direct for service accounts too. I'm not a fan of this approach for a variety of reasons I won't go into here. I hope this helps.

Leaving this open for the moment until I can get the formal documentation done.

[PatrickOnGit]

Cool, this is already a lot of help. Thank you. Specificaly that AP_PropGroups and OBJ_destination map to AP_Objects created some confusion. I tried to add delegation to allow linking GPOs, as there is a dedicated team managing GPO and GPO links and none of them should use domain admin / gold card / break class account for their somewhat daily task, (I'm well aware of the risks associated with this).