Configuration driven Active Directory management.
Active Directory is a living service, the content of which is in a perpetual state of change. This makes it impossible to fully define every single aspect of it in configuration - user objects, client computers and many other minutiae are not the direct responsibility of the Active Directory team.
However, if we cannot delete everything not defined in configuration, we must be able to draw the line somewhere, define “These OUs belong to the AD team” or “Those OUs and their content belong to other teams”.
That is what the domain content mode defines.
Content Mode is only applied to the domain Categories. Forest settings (Sites, Schema, …) are unaffected and follow their own rules.
The content mode is defined by the following properties:
The mode defines, whether we consider anything at all beyond what we define:
If multiple Contexts define this property, the last one wins.
Default mode if no Context defines it: Additive
Using the Include & Exclude string arrays, we can then define a list of OUs to “take under management” or “exclude from management”. That is, define OU structures, which are subject to having undefined objects deleted from, or OUs which are exempt from that.
OUs are defined by their distinguished name. Note that %DomainDN% is automatically available as a name label.
Settings from multiple Contexts will be merged. If only Exclude rules are defined, the system implicitly creates an Include rule for “%DomainDN%”. If a later context then adds an Include rule, this no longer happens, possibly failing to apply your intent. If you wish to mix both - or know there is a risk of it happening - and still want everything to be under management by default, manually define “%DomainDN%” as include rule.
Some users are hard to pre-define, and thus need to be excluded from prevention without being able to pre-determine their names explicitly. Very common case: Exchange System Mailbox users. For those you can define name patterns (using regex) to spare them from deletion.
To define the Content Mode, place a json file named “content_mode.json” in the domain folder of the Context. Unused properties are optional.
Example configuration: All OUs are under management except for Resources, Clients and Company
{
"Mode": "Constrained",
"Include": [],
"Exclude": [
"OU=Resources,%DomainDN%",
"OU=Clients,%DomainDN%",
"OU=Company,%DomainDN%"
],
"UserExcludePattern": []
}
Equally legal and has the same effect:
{
"Mode": "Constrained",
"Exclude": [
"OU=Resources,%DomainDN%",
"OU=Clients,%DomainDN%",
"OU=Company,%DomainDN%"
]
}
Example configuration: Only the Tier 0 OU is under management
{
"Mode": "Constrained",
"Include": [
"OU=Tier 0,%DomainDN%"
],
"Exclude": [],
"UserExcludePattern": []
}
The content mode does not affect what you can explicitly define in configuration. That means, you absolutely may define OUs, user objects, groups or whatever else in organizational units you do not take under exclusive management.
Further, some settings have a localized management effect: Notably, if you define any access rules on an object, no matter whether it is under management or not, it will remove all non-defined, non-inherited, non-default permissions.
Scenario: Defining Tier 0
Assuming you want to only define a Tier 0 environment for secure administration and not affect the rest of the architecture in the same way, you would define the following content mode:
{
"Mode": "Constrained",
"Include": [
"OU=Tier 0,%DomainDN%"
],
"Exclude": [],
"UserExcludePattern": []
}
And then define access rule settings for the domain object itself.