schema/domains/sccm/ extension provides the CI types and finding workflow.System Center Configuration Manager manages every endpoint in most enterprise and government environments. It pushes software, images operating systems, enforces compliance baselines, and distributes patches. If an attacker compromises your SCCM primary site server, they own every managed device on the network.
Despite this, SCCM infrastructure almost never appears in the CMDB. The site hierarchy, distribution points, service accounts, and security role assignments live in tribal knowledge, scattered documents, or the SCCM console itself. When a penetration test finds SCCM misconfigurations, the findings land in a PDF that gets filed away. Nobody tracks remediation. Nobody compares this quarter's findings to last quarter's. The same issues appear in the next assessment.
This is a configuration management problem, and your CMDB is the right place to solve it.
What SCCM Controls
An SCCM environment is a hierarchy of site servers, each running specific roles that serve different functions.
Sites are the top-level organizational unit. A primary site manages clients directly. A secondary site handles content distribution for remote locations. A central administration site (CAS) coordinates multiple primaries. The site code, version, and parent-child relationships define the management boundary.
Site roles are the services running on site system servers. A Distribution Point hosts content packages that clients download. A Management Point handles client communication and policy delivery. A Software Update Point integrates with WSUS for patch management. An SMS Provider exposes the administration interface. Each role has security-relevant settings: whether SSL is required, whether PXE boot is enabled, whether anonymous access is permitted.
Collections determine which devices receive which policies and deployments. A limiting collection constrains membership, creating a hierarchy that controls blast radius. Misconfigured collection scoping is how a deployment intended for test servers ends up running on domain controllers.
Service accounts are the credentials SCCM uses to operate. The Network Access Account downloads content from distribution points. The client push installation account installs the SCCM agent on new machines. The domain join account adds computers to Active Directory during OS deployment. Every one of these accounts is a target.
Security roles define what administrators can do within SCCM. Built-in roles like Full Administrator have unrestricted access. Custom roles can be scoped to specific collections or site systems. But in practice, many environments run with a handful of full admins and no role-based segmentation.
The Misconfiguration Manager Framework
The Misconfiguration Manager project catalogs known SCCM attack techniques into five categories.
CRED techniques harvest credentials from SCCM. The most common finding is CRED-1: the Network Access Account credentials are recoverable from client policy by any authenticated domain user. If the NAA has excessive privileges (which it often does), that's immediate lateral movement.
EXEC techniques execute code through SCCM's deployment mechanisms. EXEC-1 is the classic: client push installation configured with an account that has local admin rights on domain controllers. Compromise the SCCM site, push the client to DCs, and you have code execution on every domain controller.
ELEVATE techniques escalate privileges through SCCM trust relationships. NTLM relay attacks against site systems, abuse of automatic site assignment, and exploitation of the site-to-site communication channel all fall here.
RECON techniques enumerate the environment. Anonymous read access to the SMS Provider WMI namespace lets an unauthenticated attacker map the entire SCCM topology: sites, collections, deployments, and targets.
TAKEOVER techniques compromise the entire hierarchy. A passive site configured to accept unverified data from any source is the textbook example.
SpecterOps released ConfigManBearPig, an open-source tool that maps these misconfigurations and attack paths into BloodHound. It enumerates the SCCM hierarchy, identifies vulnerable configurations, and visualizes attack paths from initial access to domain compromise.
Three Findings That Show Up Everywhere
After enough SCCM assessments, patterns emerge. These three findings appear in nearly every environment.
Recoverable NAA credentials. The Network Access Account is configured with domain user privileges and its credentials are stored in client policy. Any authenticated user on any managed device can extract them. The fix is straightforward: replace the NAA with Enhanced HTTP (available since SCCM 1806) or use a Cloud Management Gateway for internet-based content access. But many environments still run the NAA because it was configured during initial setup and nobody revisited it.
Client push to domain controllers. The client push installation account has local administrator rights on all systems, including domain controllers. This is the default configuration guidance from years of Microsoft documentation. The fix: exclude domain controllers from client push scope and install the SCCM client on DCs manually or through Group Policy.
HTTP-only site system communication. Site systems communicate over HTTP instead of HTTPS. Management Points accept unencrypted client communication. Distribution Points serve content without SSL. This enables credential interception and content manipulation. The fix is enabling HTTPS site-wide and requiring PKI certificates, or at minimum enabling Enhanced HTTP.
Modeling SCCM in Your CMDB
CMDB-Kit ships an SCCM domain extension (in schema/domains/sccm/) with seven CI types for SCCM infrastructure, three lookup types, and a finding type that links discoveries to specific infrastructure records. It layers on top of the extended schema as an opt-in module, keeping the core schema focused on product delivery.
The SCCM Site type captures the hierarchy: site codes, versions, site types, and parent-child relationships. The SCCM Site Role type records what roles run on which servers with their security-relevant settings. Service accounts get their own type because they are the primary attack vector in most SCCM compromise scenarios.
The SCCM Finding type is where this becomes useful. Each finding links to:
- The specific CI it affects (a site, a role, a service account)
- The attack category (CRED, EXEC, ELEVATE, RECON, TAKEOVER)
- The assessment that discovered it
- A severity level
- A remediation description
- A status that tracks progress from discovery through remediation
This turns a point-in-time PDF into persistent, comparable records. When you run the assessment again next quarter, you create new findings and compare them against the previous set. Remediated findings stay in the history. New findings are immediately visible. Recurring findings across assessments become impossible to ignore.
From Assessment to Remediation
The workflow integrates with CMDB-Kit's existing Assessment type.
Start by creating an Assessment record with the type "SCCM Security Review." Populate the SCCM CI types from the target environment: enumerate the site hierarchy, document the roles and their configuration, catalog the service accounts and their privilege levels, map the collections and their scoping.
Run your collection tool. ConfigManBearPig produces a dataset of nodes and relationships that map directly to the CMDB-Kit types. SMS Site nodes become SCCM Site records. Site system nodes with their role attributes become SCCM Site Role records. Accounts identified in the output become SCCM Service Account records.
For each misconfiguration or attack path identified, create an SCCM Finding record. Link it to the specific CI, tag it with the attack category, set the severity, and describe the remediation. The finding now lives alongside the infrastructure it affects.
Track remediation through the Assessment Status lifecycle. When the NAA gets replaced with Enhanced HTTP, update the finding status. When client push gets scoped away from domain controllers, close that finding. The next assessment creates a fresh set of findings that you compare against the previous baseline.
The CMDB becomes the single system of record for SCCM security posture, not a PDF on a SharePoint site.
Getting Started
The SCCM types are a domain extension that layers on top of the extended schema:
ls schema/domains/sccm/data/The example data models a two-site hierarchy with service accounts, security roles, collections, and three findings from a security audit. Use it as a template for your environment.
For the full type reference and assessment workflow, see the SCCM Security Assessment documentation in the CMDB-Kit repo.
If you want help running an SCCM security assessment and building persistent tracking into your CMDB, contact Ovoco. We'll enumerate your hierarchy, run the collection tools, map findings to your CMDB, and build the remediation tracking workflow so your security posture improves quarter over quarter instead of cycling through the same PDF findings.