Windows SCM: Is there a supported integration point for policy-based rejection of service-creation requests?

Question

Windows SCM: Is there a supported integration point for policy-based rejection of service-creation requests?

Chris Terrell 20

Microsoft DocHelp directed my SCM documentation inquiry to Microsoft Q&A.

I am evaluating a Windows application design requiring an independently protected, fixed policy to constrain service creation through the existing Windows Service Control Manager.

The policy concerns the actual application caller and material creation inputs, including service identity, executable/configuration inputs, and service-account association. An application authorization reference and executable-content identity are application-level requirements; I am not assuming SCM already interprets them.

Question

Does Windows provide a documented, supported integration point—or explicitly supported composition of interfaces—that permits an independent enforcing component to evaluate and reject an actual SCM service-creation request based on that policy before prohibited creation effects occur?

For any identified mechanism, please provide the supporting documentation and applicable Windows version/configuration limits. Please distinguish integration with the existing SCM implementation from callbacks available when an application registers its own RPC server.

Documentation examined

CreateServiceW documents the creation inputs and requires an SCM handle with SC_MANAGER_CREATE_SERVICE.

Service Security and Access Rights describes access checks for SCM/service objects and service-object security.

I have not established from these references the independent policy-enforcement integration described above.

Scope and required boundary

This thread seeks identification of a supported integration mechanism. The broader evaluation also requires binding the enforcement decision to the same request, including relevant delegated processing; preventive ordering across relevant SCM, registry, filesystem, and credential/account-association effects; service protection from first existence; and coverage of equivalent creation methods and routes.

Those requirements remain unresolved by merely identifying a candidate mechanism. Detailed assessment of a candidate’s ordering and coverage can follow once it is identified.

A caller-side wrapper, post-event notification, rollback, or later security change would not by itself satisfy the preventive requirement.

Environment and evidence limits

This is a documentation and design inquiry. No deployed Windows version, build, update level, transport, or filter configuration has been established for it. No observed Windows defect or absence of a suitable mechanism is asserted. Please state the versions and configurations covered by any answer.

Credential values are not requested. If the integration is unsupported, please distinguish a documented limitation from an undocumented implementation detail or a question the available documentation does not settle.

0 comments

3 answers

Your answer

Answer 1

The documented SCM integration points in the provided material are access-right checks on the SCM handle and on the service object being created or opened. The material documents that:

CreateService requires an SCM handle with SC_MANAGER_CREATE_SERVICE.
The SCM creates the service object's security descriptor when the service is installed by CreateService.
Requested access is granted or denied based on the calling process access token and the security descriptor associated with the SCManager or service object.
Only processes with Administrator privileges can open SCM handles usable by CreateService.

The provided documentation does not describe a supported pre-create policy hook, callback, filter, or other integration on the existing SCM creation path that can inspect the requested service-account value and reject a substitution such as Account_B before service creation occurs.

The provided documentation also does not describe a supported composition with SCM that would bind an independent authorization decision to the actual CreateService request and caller, including delegated processing, with prevention of creation effects on the prohibited request.

What is documented for service objects is post-creation security and access control:

The SCM creates the service object's security descriptor at install time.
Default service-object access rights are then granted to accounts such as Administrators, LocalSystem, and local authenticated users.
SERVICE_CHANGE_CONFIG is the right required to change service configuration, including settings controlled through ChangeServiceConfig and ChangeServiceConfig2.

That supports controlling later modification of a service, but it does not document an independent mechanism that rejects an unauthorized service-account substitution before the service is created.

For Windows versions/configurations, the provided material documents only these relevant distinctions:

On Windows Server 2003 and Windows XP, the SCM security descriptor could not be modified; this changed in Windows Server 2003 SP1.
Remote authenticated users are not granted default service access by default, with older-version differences noted.

Those version notes do not add a documented pre-creation enforcement point for the scenario described.

Based on the provided documentation only, no documented, supported SCM-path integration is established that satisfies the required boundary of preventing the prohibited service creation and its creation effects before they occur, solely by independently enforcing the requested service-account association on the existing CreateService path.

Answer 2

The AI answer limits its conclusion to the two cited references. The remaining question is whether another documented, supported integration or composition on the existing SCM creation path addresses the stated service-account-substitution scenario.

Could a human reviewer identify such a contract, or a documented limitation, with the Windows versions/configurations it covers? Ordinary SCM access prerequisites are assumed satisfied in the scenario; the unresolved requirement is independent rejection of the policy-prohibited request before its prohibited creation effects.

For precision, the cited documentation describes initial service-object security-descriptor creation at installation. I am not asserting an unprotected interval before later security configuration.

Answer 3

Hello @Chris Terrell ,

I looked into this specifically for the SCM create path, and the answer is that Windows does not document or support such an integration point. There is no supported way for an independent component to evaluate the actual CreateService request, meaning the caller, executable/config inputs, and the requested service-account association, and reject it before the creation effects occur. The documented SCM security model is an access-check model only, and none of its surfaces is a content-aware, pre-create policy callback.

What the SCM path exposes, all access-based and all documented:

CreateService requires an SCM handle holding SC_MANAGER_CREATE_SERVICE, and only administrators can obtain a create-capable handle. The decision is made against the SCManager object's security descriptor, which you read or set with QueryServiceObjectSecurity / SetServiceObjectSecurity (or sc sdset scmanager). That gate is preventive and enforced by SCM itself, but it is caller-and-rights based: it decides whether a principal may create a service at all. It does not see, and cannot reject on, the requested service-account value or the executable/config inputs, so it does not meet the policy you described. The SCManager descriptor became modifiable in Windows Server 2003 SP1; it was not on XP or Server 2003 RTM.

There is no documented callback, filter, or hook on CreateService that receives the request parameters and can veto them, and no documented composition that binds an independent authorization decision to the same SCM request and caller, with delegated processing, and prevents creation effects. On the nature of that answer, since you asked to distinguish it: this is a documented design boundary, not an undocumented implementation detail and not a point the docs leave open. The SCM security model is fully documented, it is exclusively an access-check model over the SCManager and service objects, and it defines no extensibility surface of the kind you need. The mechanism is absent by documented design, not hidden.

The supported, preventive mechanisms that come closest, and where each one falls short of your boundary:

Code-integrity policy (WDAC, or AppLocker on older systems). Preventive and independent of the caller. It constrains which executable/image identity may run, including a service's image, so it partly covers "executable-content identity." It does not evaluate the CreateService request and does not reject on the service-account association; it acts on the image at load or run, not on the create request. WDAC applies to Windows 10 and Server 2016 and later.
Registry filtering driver (CmRegisterCallbackEx, pre-operation RegNtPreCreateKeyEx / RegNtPreSetValueKey). A kernel filter can block, before the configuration manager processes it, the writes SCM makes under HKLM\SYSTEM\CurrentControlSet\Services\<name>, including the ObjectName value that carries the service account. This is the only supported mechanism that is both preventive and able to read the requested account. But it filters the registry effect, not the SCM request: the operating thread is SCM (services.exe), not your original caller, so it does not deliver the SCM caller identity or the request as one delegated unit; SCM writes the account and other inputs as separate registry operations you must correlate; and it requires a signed kernel-mode driver, subject to driver-signing and memory-integrity constraints on current builds. Pre-operation blocking with these capabilities is Windows Vista and later.
RPC filtering (netsh rpc filter). Can block calls to the SCM RPC interface preventively and independently, but at interface/opnum and caller-attribute granularity. It cannot parse the CreateService arguments, so it cannot reject specifically on the requested account.

None of these binds an account-aware, parameter-level decision to the actual CreateService request and caller, with delegated processing and prevention before all SCM, registry, filesystem, and credential effects. Caller-side wrappers, post-create notifications (NotifyServiceStatusChange), auditing, and later DACL changes are out of scope for the same reason you gave.

So, to your two framings: there is no supported SCM-path contract that satisfies the requirement, and the reason is a documented design limitation of the SCM security model, which is access-based only, not an undocumented detail. If the policy must be content-aware and pre-creation, the supported building blocks are the SCManager descriptor to constrain who may create services, WDAC to constrain the service image, and, for account-content enforcement, a registry-filter driver that vetoes the service-key write, accepting that it is a registry-path control rather than an SCM-request contract.

Versions and configuration: the SCM access model applies to current Windows client and server, with the descriptor-modifiability change at Server 2003 SP1 as noted; WDAC from Windows 10 and Server 2016; registry and RPC filtering from Vista onward. No specific build, update level, or filter configuration was assumed beyond what the cited documentation states.

Sources:

I hope this settles the integration-point question for your design. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation

Thank you.

Chris Terrell 20 Reputation points

2026-09-15T17:15:17.26+00:00

@Taki Ly, thank you for the detailed response and for identifying the relevant supported mechanisms and documentation.

I understand your answer as addressing the bounded question in this thread: whether Windows SCM provides a supported integration point through which an independent policy component can synchronously inspect and allow or reject an individual service-creation request before SCM completes that creation, together with the applicability and limitations of the mechanisms you identified.

I am reviewing the cited sources and the distinctions among an SCM integration point, access control, registry-based policy, and RPC filtering before determining whether the answer resolves the question for acceptance. This acknowledgment does not extend the answer beyond the service-creation boundary asked about here.

Thank you for the careful technical contribution.