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

@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.

Hi @Chris Terrell ,

Take the time you need to review the sources. If anything in them reads ambiguously while you work through the distinctions between an SCM integration point, access control, registry-based policy, and RPC filtering, I am happy to clarify a specific point within this same service-creation scope. If a separate concern comes up outside it, a new thread would be the cleaner place to keep each question self-contained.

Thank you.

@Taki Ly, thank you for offering to clarify. My remaining question concerns the source basis for the “documented design boundary” characterization in your answer.

I can trace the SCM access checks and registry-operation blocking to the cited documentation. The netsh rpc reference also distinguishes filtering conditions from parameter-buffer auditing; I have not treated that auditing facility as a policy veto based on CreateService arguments.

Could you identify the specific documentation passages or contract provisions supporting the further conclusion that no supported integration point—or explicitly supported composition—on the existing SCM creation path satisfies the stated requirement? If that conclusion follows from analysis of the documented interfaces, please explain that connection and distinguish it from any express documented exclusion, including the applicable version/configuration limits.

The requirement remains independent evaluation of the actual caller and material creation inputs, including the requested service-account association, bound to the same request and able to reject it before prohibited creation effects occur. Ordinary SCM access prerequisites are assumed satisfied.

This remains a clarification of the existing service-creation question. Detailed ordering and coverage assessment can follow if a candidate mechanism is identified.

Hi @Chris Terrell ,

Thanks, that is a fair point, and you are right to push on it. I need to correct my wording.

There is no express documented exclusion. No page in the SCM documentation says that CreateService has no pre-create policy callback, filter, or hook. Microsoft's reference pages describe what each interface does. They do not list interfaces that do not exist. So when I wrote "documented design boundary", that was too strong. The correct classification is this: my conclusion that no supported integration point, and no supported composition, on the existing SCM creation path meets your requirement is an inference. I reached it from the documented interface surface plus one premise about what "supported" means, which I state explicitly below. I did not get it from a passage that says so. Below I separate what the documentation states from the inference, and I add the version limits.

What the documentation states

• Service control manager: the SCM is a "remote procedure call (RPC) server". Its documented functions are keeping the database of installed services, starting services, enumerating them, tracking status, passing control requests, and locking the database. There is no policy or extensibility function in that list.
• MS-SCMR, RCreateServiceW (Opnum 12): this is the wire method behind CreateService. "The SC_MANAGER_CREATE_SERVICE access right MUST have been granted to the caller when the RPC context handle was created." On success "the server MUST use the service name specified in the lpServiceName parameter to create a new service record in the SCM database and use the values from the appropriate parameters of the client request to update the attributes of this newly created service record." lpServiceStartName "specifies the name of the account under which the service SHOULD run." The documented return codes are access denied, invalid handle, data, parameter, name, and service account, circular dependency, exists, marked for delete, duplicate name, and shutdown in progress. There is no return code for a policy rejection.
• SCM Handles: for OpenSCManager, CreateService, and OpenService, "the requested access is granted or denied depending on the access token of the calling process and the security descriptor associated with the SCManager or service object."
• Service Security and Access Rights: SC_MANAGER_CREATE_SERVICE is "required to call the CreateService function"; "only processes with Administrator privileges are able to open handles to the SCM that can be used by the CreateService" function; on Windows XP and Server 2003 "the security descriptor for the SCM cannot be modified" and "this behavior has changed as of Windows Server 2003 with Service Pack 1". The same page documents NotifyServiceStatusChange as the way "to receive notification when any service is created or deleted", which is after the fact.
• CreateServiceW: the function "creates a service object and installs it in the service control manager database by creating a key with the same name as the service under" HKLM\SYSTEM\CurrentControlSet\Services, and ObjectName is the value that stores lpServiceStartName.

Taken together, those pages describe the whole decision SCM makes on the create path: an access check of the caller's token against the SCManager object's security descriptor, followed by parameter validation and the creation itself. None of them presents lpServiceStartName, lpBinaryPathName, or the other inputs as something an outside component gets to approve or reject before creation.

How I get from there to the conclusion

Step 1. The documented decision on the create path is small enough to list, and it is only an access check plus SCM's own parameter validation. You assume the normal SCM access prerequisites are already met, so that gate cannot be the answer to your requirement. It also never evaluates the service-account value against a policy.

Step 2. I then checked every documented mechanism that can sit in front of, or underneath, the create path. Each one lacks the piece you need, a decision on the request parameters, bound to that request, before creation:

• RPC filtering (WFP filtering conditions, layer FWPM_LAYER_RPC_UM). The complete documented condition set is interface UUID, version, and flags, DCOM application ID, image name, protocol, authentication type and level, encryption algorithm and key size, remote user token, pipe, and local and remote addresses and port. FWPM_CONDITION_RPC_OPNUM is documented for Windows 11 with the October 2025 cumulative update or later. No condition reads the marshaled parameter buffer. So on current Windows 11 a filter can block opnum 12 on the SCM interface for a given caller or image, which is preventive and independent, but it cannot see lpServiceStartName, so it cannot reject on the requested account. On netsh rpc, the documented actions are block, permit, and continue; audit is a flag on a rule, and the page states that only permit filters can have auditing enabled. Auditing is therefore not a rejection path, which matches your reading.
• Registry filtering (Filtering Registry Calls, REG_NOTIFY_CLASS, REG_SET_VALUE_KEY_INFORMATION). A RegistryCallback "receives notifications of each registry operation before the configuration manager processes the operation" and "can block a registry operation." This is the one documented mechanism that is both preventive and able to see the requested account, because it sees the ObjectName write. But it is a contract on the registry operation, not on the SCM request. MS-SCMR says the server creates the record, so the write the callback sees is the SCM server's operation, not the client's RPC call. The structure the callback receives for a value write contains the key object, value name, type, data, data size, and driver context; it has no member that identifies the RPC client or carries the CreateService request. The inputs arrive as separate registry operations you would have to correlate. And the callback lives in a kernel-mode driver, which must be signed (Driver Signing Policy: signature required for 64-bit from Windows Vista, and "starting with Windows 10, version 1607, Windows will not load any new kernel-mode drivers which are not signed by the Dev Portal"). One correction to my earlier note on versions: blocking is documented from Windows XP, the RegNtPreSetValueKey and RegNtPreCreateKeyEx classes from Windows Server 2003 and later, and CmRegisterCallbackEx with layered filtering and full pre-operation handling from Windows Vista.
• Application control (App Control for Business feature availability): "Available on Windows 10, Windows 11, and Windows Server 2016 or later." Its enforceable file types are driver, executable, DLL, installer, script, and packaged-app files. It decides what code may run, so it can constrain the service image, but it does not receive the create request and does not evaluate the service account.
• NotifyServiceStatusChange: documented as notification after a service "is created or deleted", so already outside your boundary.

Step 3. This step is my premise, not a quotation. I treat a supported contract as one that Microsoft documents. I am not aware of a page that states that rule in general terms, so please read it as the working assumption behind the inference. If an interface is not documented, I do not count it as a supported integration point, whether or not something like it exists inside the OS.

Putting it together: the documentation does not provide, and does not describe, any component on the SCM create path that receives the actual CreateService request with its caller and inputs and can reject it before the creation effects happen. That much is a documented absence, in the sense that the pages above list the decision surface and no such component is on the list. The further step, "and therefore none is supported", is my inference using the premise in step 3. The documentation does not state that negative, and I cannot point you to a passage that does. What it leaves open is only whether undocumented internals exist, and under the premise in step 3 that would not change the supported answer.

Version and configuration limits

SCM access model               current Windows client and server
SCManager SD modifiable        Windows Server 2003 SP1 and later (not XP or 2003 RTM)
WFP RPC filtering              Windows Vista / Server 2008 and later
RPC_OPNUM condition            Windows 11 with the October 2025 CU or later
Registry callback blocking     Windows XP and later
RegNtPre* notification classes Windows Server 2003 and later
CmRegisterCallbackEx           Windows Vista and later
Kernel driver signing          64-bit from Vista; Dev Portal signing from Windows 10 1607
App Control for Business       Windows 10 / Windows 11 / Server 2016 and later

None of these version changes adds a parameter-level decision on the CreateService request before creation, so the version axis does not change the conclusion. I did not assume any specific build, update level, or filter configuration beyond what those pages state.

If you need an express, citable statement of the create-path extensibility position for your design record, the documentation does not have one today. The "Was this page helpful?" control on the CreateService and Service Security pages goes to the owners of those pages, so that is the place to ask for it.

I hope this gives you the classification you were after. If you feel the question in this thread is helpful, you are welcome to follow this guide, as it helps others with similar questions find the information more easily. Either way, I am happy to clarify anything else within this scope.

Thank you.

@Taki Ly, thank you for correcting the source classification and explaining the inference and its working premise. That answers my follow-up about the basis of the conclusion.

I understand this as your analysis of the documented interfaces, rather than an express Microsoft exclusion of every supported integration or composition. Could you update the original answer’s “documented design boundary” wording to match this clarification, so readers do not miss the correction?