Configuration Manager trust boundaries: map authority to targets

Why OU Placement Does Not Establish Configuration Manager Trust Boundaries

Configuration Manager trust boundaries follow administrative authority: who can change a management component, which resources an operator can control, and where an installation identity holds local rights. An AD computer's distinguished name is useful inventory evidence, but moving it into an OU named Management does not answer those questions.

Start with the candidate computer, then follow its authority outward. Is it a site server, an SMS Provider host, another site system, or simply a managed client with a product name in its description? Which people and service identities administer it? Which systems can those identities reach? A boundary review is incomplete until the same record connects the management infrastructure to its actual targets.

The Active Directory tiered administration model and administrative sessions provides the broader separation principles. This review adds a product-specific authority map. Keep the two connected: an OU convention can support policy deployment, but it cannot substitute for evidence about who controls Configuration Manager or the systems it manages.

How It Works: Provider Access, Database Authority, and Target Reach

Microsoft describes separate security layers. The SMS Provider exposes site-database access through WMI and the administration service. Provider access and permissions over managed objects are different questions. Local System and the Configuration Manager setup user have default authority over all site-database objects; other administrative users are governed through the console's role-based administration. Roles, security scopes, and collections together define what a user can view and manage. These distinctions come from Configuration Manager security fundamentals.

For the review, record three paths independently:

• Infrastructure control: identities able to administer the provider host, site server, or database infrastructure.
• Product administration: principals whose assigned permissions allow operations on particular Configuration Manager objects and target collections.
• Installation authority: accounts with rights on systems where the product installs a client or site-system component.

This is an assessment model, not a claim that every Configuration Manager operator has unrestricted Windows administration. For each path, establish the granted operation and the affected resource. Do not turn the ability to query the provider into a conclusion that the identity can deploy to every device.

Microsoft's Configuration Manager accounts reference provides concrete distinctions. SMS Admins is a local group on provider computers; its WMI permissions can be inspected with the WMI Control MMC snap-in. RBAC still determines console object access. The client push installation account requires local Administrators membership on target clients, not Domain Admin membership; absent a configured account, the site tries its computer account. The separate site system installation account requires local administrative permissions and the network-access user right on target site systems. The network access account serves resource access, not the execution context for software, updates, or task sequences.

Those accounts deserve separate rows even when the same AD identity fills more than one function. A label such as “service account” hides the distinction between downloading content and administering a target. Conversely, different account names do not establish separation if they receive equivalent rights over the same machines.

Detection: Build the Authority Matrix from Product Evidence

Step 1: Confirm the Candidate's Actual Function

Preserve the LDAP finding, computer DN, matched inventory field, and review date. Ask the product owner to identify the candidate's real function and associated site. Reconcile that answer with the deployed product configuration and host inventory. If it is only a client, record why the heuristic matched it; do not invent a management role to justify the finding.

For a confirmed management component, list its dependent provider and database hosts, installation identities, and administrative owners. Mark unresolved relationships as unknown. An inventory that omits a provider or a remote site system can make a supposedly narrow management scope look safer than it is.

Step 2: Read Roles, Scopes, and Assigned Collections Together

Follow Microsoft's role-based administration configuration procedure. In the console, open Administration > Security > Administrative Users, select the principal, and open Properties. Inspect Security Roles and Security Scopes, including the configured association between roles, scopes, and collections. To inspect a role's object permissions, go to Administration > Security > Security Roles, select the role, open Properties, and choose the Permissions tab.

For collection authority, review the role's Collection object permissions and the collections assigned to the administrative user. Include collections limited by those assigned collections. Microsoft also identifies the Role-based administration and auditing tool for auditing users, collections, and scopes.

Use those views as evidence, not just screenshots of friendly names. Record identifiers, the relevant permitted actions, group-based assignments, and the device membership used for the review. When membership changes, the authority map needs another review. A collection named “Servers” does not establish that every member belongs to the intended trust level.

Step 3: Inspect Installation Configuration and Local Target Rights

Microsoft's Windows client deployment procedure gives the console path: Administration > Site Configuration > Sites, select the site, then Client Installation Settings > Client Push Installation. Inspect the Accounts tab and the General tab's automatic installation settings, selected system types, and domain-controller selection. The procedure also documents push initiated for an individual device or collection.

Read this configuration before initiating any installation. A configured target selection is evidence about the installation workflow; independently inspect where each identity actually holds local administrative rights. Distinguish the configured client push account, the computer-account fallback, and the site system installation account.

Record successful and failed verification separately. If local group membership cannot be checked on a target, mark that target unknown. Do not infer missing rights from an unavailable host, or infer rights on every machine from a successful check on one representative device.

Step 4: Connect Principals to Managed Systems

Build one row per authority path. The following is a review template, not a discovered environment or a set of default permissions:

Read across the table: principal → role/account → site/collection → managed systems. Then ask which row joins previously separated trust levels. Review combined assignments rather than considering each role in isolation. Retain a separate entry for an unknown target set; a blank cell should never silently mean “no access.”

Remediation: Align Authority Before Changing OU Placement

Step 1: Decide the Intended Boundary and Preserve the Baseline

With the infrastructure and identity owners, define which managed systems belong together and which administrative paths must remain separated. Compare that intended boundary with every matrix row. Record the reason for each mismatch, its owner, and the evidence needed to close it.

Preserve the existing role assignments, installation configuration, target memberships, and operational dependencies before changes. Choose a pilot containing both an intended target and a system that should remain outside the operator's authority. Plan an approved functional test and a rollback for each change.

Step 2: Narrow Product Permissions through the Supported Console

Use the administrative-user properties already reviewed to adjust the relevant role, scope, and collection associations. Where existing roles grant excess authority, use Microsoft's documented custom-role procedure: copy a role in Administration > Security > Security Roles, inspect its object permissions, and assign only the required permissions. Built-in role permissions cannot be edited. These operations are covered by the role-based administration configuration procedure.

The change should remove a specific unwanted operation or target relationship. Verify that intended administration still works and that the excluded system is outside the granted authority. Keep infrastructure administration in the review; narrowing a console assignment alone does not resolve a separate host or database administration path.

Step 3: Separate Installation Authority Where Its Reach Crosses the Boundary

For each installation identity, compare its verified local rights with the intended target set. Propose separate, appropriately scoped identities where one account spans trust levels. Check the account configured in the product and the permissions granted at each destination; changing only one side leaves the review incomplete.

Microsoft's accounts reference recommends explicitly denying local interactive logon to the client push account. It also documents a replacement sequence: create a differently named account, add it to the configured list, allow AD replication, then retire the old account. Treat that as a coordinated migration with target-right verification, not an instruction to purge accounts or groups. The site system installation identity requires its own target review. Follow the documented account requirements for the function actually used.

Step 4: Reconcile OU Placement, Administrative Sessions, and Flows

Only after the authority map is coherent should OU placement, delegation, policies, and administrative entry points be compared with the intended design. Consider the management hosts and the people and accounts that control them together. Moving one computer object cannot fix an account that retains rights over an unintended target set.

Review transport as a separate control. The GPO checks for WSUS metadata transport address that connection protection; they do not establish who can administer the SMS Provider or what an installation identity can control. Keep both reviews, with separate evidence and conclusions.

Step 5: Close Findings with Evidence and Retain Exceptions

Rebuild the matrix after the pilot and subsequent rollout. For each changed row, attach the new assignment, current target membership, relevant local-right evidence, and functional outcome. An exception should identify the required operation, affected systems, owner, compensating measures, and a review trigger. An unresolved permission or unreachable target remains unknown.

Define triggers for another review: a new provider host, site system, collection assignment, installation identity, or managed trust level. A boundary decision remains defensible only while its supporting authority map matches the deployed environment.

How EtcSec Detects This

The reviewed etc-collector check is ANSSI_R49_R50_MGMT_CATEGORIZATION, at collector commit 15fc6399c215eabc415c370b762303cfcd7a353a. It is an inventory and naming heuristic, not a Configuration Manager authorization audit.

A computer becomes a candidate when its DN matches an entry in optional mgmt_systems, or when the lowercased combination of SAMAccountName, DNSHostName, Description, and OperatingSystem contains one of these markers: sccm, configmgr, wsus, mecm, defender, atp, mdatp, intune, jamf, ansible, salt, puppet, chef, tanium, bigfix, crowdstrike, carbonblack, or sentinelone.

It produces a finding for candidates whose lowercased DN contains none of ou=tier0, ou=tier-0, ou=tier1, ou=tier-1, ou=admin, ou=mgmt, or ou=management. These are substring tests, not a validation of an OU's actual controls. If no candidate fails that test, Detect() returns nil.

The optional mgmt_systems list comes from tier0_groups.yaml. If that file is absent, no customization is loaded, the list is empty, and only name heuristics apply, without a warning. If the file is unreadable or its YAML is malformed, the engine writes a warning to stderr and continues with defaults. An explicit DN entry adds a candidate; it does not establish product authority or replace the OU substring test.

The LDAP provider supplies computer inventory fields. This check collects no SMS Provider permissions, site-database authority, RBAC assignments, target collections, or installation-account rights. A client name can match; a genuinely powerful management system can be missed; an OU name can satisfy the substring test without enforcing isolation.

Use the finding to start the authority review. Close the architectural question with the product and target evidence in the matrix, retaining unknowns and exceptions even when the naming heuristic no longer reports a finding.