sc.exe sidtype changes the Service SID type assigned to a Windows service. It is the write-side companion to Windows Command #48 – sc qsidtype. Where qsidtype inspects a service, sidtype changes how Windows places that service-specific identity into the service process token.

This is a security-sensitive command. A Service SID can let administrators grant access to one specific Windows service instead of broadly granting access to a shared service account such as LocalSystem. But changing a SID type without understanding the service’s ACLs, hosting model, and resource dependencies can break the service. Treat sc.exe sidtype as a configuration command, not a casual troubleshooting toggle.

Attack Detect Defend explains why Windows services and the Service Control Manager are security-sensitive components and why service configuration must be handled carefully.

What You’ll Learn

• Explain what sc.exe sidtype changes.
• Configure NONE, UNRESTRICTED, and RESTRICTED Service SID types.
• Understand why UNRESTRICTED can support service-specific ACLs.
• Understand why RESTRICTED changes the token more aggressively.
• Recognize the shared-process restriction rule.
• Verify changes with qsidtype and showsid.
• Use a safe test-and-rollback workflow before changing production services.

Start With the Service Control Manager

Windows services are managed by the Service Control Manager, or SCM. Microsoft documents Sc.exe as a command-line interface that can query or modify the SCM database. That is why commands such as query, config, privs, qsidtype, showsid, and sidtype all belong to the same family.

If you need a broader foundation first, review OSITC.005: Windows Services Fundamentals. The important idea for this lesson is that the SCM stores service configuration and controls how Windows starts and manages service processes.

Basic Syntax

The practical form is:

sc.exe sidtype SERVICE_NAME none
sc.exe sidtype SERVICE_NAME unrestricted
sc.exe sidtype SERVICE_NAME restricted

Use the service’s short service name, not merely the friendly display name shown in the Services console. Microsoft’s SC documentation supports both local and remote service configuration, with a remote computer specified before the command in UNC form.

In PowerShell, write sc.exe explicitly. That avoids confusion with shells or profiles where sc may resolve to something other than the Windows Service Control executable.

NONE: Do Not Add the Service SID

NONE configures the service so its per-service SID is not added through the Service SID mechanism. Microsoft defines this as SERVICE_SID_TYPE_NONE, value 0x00000000. The service still runs under its configured account and still has a normal process token. NONE does not mean the service has no security identity at all.

sc.exe sidtype ExampleService none

Removing a Service SID can break permissions if files, registry keys, databases, named objects, or firewall rules were deliberately scoped to NT SERVICE\ExampleService. Before setting NONE, inventory every resource that depends on the service-specific identity.

ITFreeTraining reviews Windows service accounts and the principle of least privilege, useful context for understanding why service-specific identities reduce the blast radius of overly broad permissions.

UNRESTRICTED: Add a Per-Service SID

UNRESTRICTED tells Windows to add the service SID to the process token when the applicable service process is created. Microsoft identifies this as SERVICE_SID_TYPE_UNRESTRICTED, value 0x00000001. The Service SID can then be used in normal Windows access-control decisions.

sc.exe sidtype ExampleService unrestricted

The security advantage is granularity. Instead of granting a resource to every service running under a broad built-in account, an ACL can grant access to a single service identity such as NT SERVICE\ExampleService. Microsoft’s Windows Service Hardening guidance describes per-service SIDs specifically as a way to apply ACLs to resources that are private to one service.

Microsoft also documents real products that use this pattern. System Center guidance, for example, instructs administrators to run sc sidtype HealthService unrestricted before granting database rights to the resulting NT SERVICE\HealthService identity.

RESTRICTED: Add the SID to the Restricted Token

RESTRICTED is the stronger option. Microsoft defines SERVICE_SID_TYPE_RESTRICTED as including the unrestricted behavior while also adding the Service SID to the restricted SID list in the process token. Windows adds additional restricted identities including the World SID, the service logon SID, and the write-restricted SID.

sc.exe sidtype ExampleService restricted

The practical effect is tighter write access. Resources that the service must write to need permissions compatible with the restricted-token model. If those ACLs are not prepared correctly, the service can lose access to files, registry keys, or other objects it requires to function.

This is why RESTRICTED should not be treated as “UNRESTRICTED but safer.” It changes the authorization path. Security hardening is useful only when the application has been designed and tested for the harder boundary.

ManageEngine reviews Windows service-account security and least-privilege practices, providing additional context for why service identities should receive only the access they require.

The Shared-Process Rule

This is one of the most important rules in the lesson. Microsoft’s SERVICE_SID_INFO documentation states that if multiple services are hosted in the same process and one service uses RESTRICTED, all services hosted in that process must use RESTRICTED.

That means you should inspect how a service is hosted before changing it. A service running in its own process gives you a different risk profile than a service sharing a host process with several other services. Use sc.exe qc SERVICE_NAME, Task Manager, Process Explorer, and service documentation to understand the process model before hardening.

A Real Firewall Example

Service SIDs are not theoretical. They can affect service-scoped Windows Firewall behavior. A documented Windows Server RADIUS troubleshooting case used sc sidtype IAS unrestricted to enable the service-specific identity needed for a service-aware firewall configuration.

Configuring a RADIUS server – Microsoft Server 2019
byu/crypticsage inPFSENSE

A pfSense community troubleshooting thread documents the exact sc sidtype IAS unrestricted command in a Windows Server RADIUS and firewall scenario. Treat community reports as examples, then verify against Microsoft documentation and your own environment.

Verify Before and After

Never make the write-side change blind. First inspect the current setting:

sc.exe qsidtype ExampleService

Then record the current result. If you proceed with a change, query again afterward. To display the actual Service SID rather than only its configuration type, use:

sc.exe showsid ExampleService

Do not assume that changing the SCM database means the active process token changed immediately. Microsoft’s current SERVICE_SID_INFO documentation says the change takes effect the next time the system is started. Product-specific Microsoft guidance may also prescribe restarting an affected service as part of a supported procedure. Follow the documentation for the exact service, then verify the running state and permissions instead of relying on the success message alone.

Remote Syntax

SC supports remote service configuration. The server name appears before the command:

sc.exe \\SERVER01 sidtype ExampleService unrestricted

Remote modification requires connectivity to the remote Service Control Manager and sufficient rights to change that service’s configuration. Microsoft documents SERVICE_CHANGE_CONFIG as the access right required by the underlying service-configuration API. A remote failure may therefore be a permissions or RPC/connectivity problem rather than a problem with sidtype itself.

Safe Change Workflow

1. Identify the exact short service name.
2. Read the application or Windows documentation for that service.
3. Run sc.exe qc SERVICE_NAME to understand its configuration and hosting type.
4. Run sc.exe qsidtype SERVICE_NAME and record the current value.
5. Inspect the service’s required files, registry keys, network access, database permissions, and firewall rules.
6. Test the intended change on a disposable VM or nonproduction host.
7. Run sc.exe sidtype SERVICE_NAME VALUE.
8. Follow the documented restart or reboot requirement for that service.
9. Verify with qsidtype, showsid, service status, Event Viewer, and application-level tests.
10. If functionality breaks, restore the previous SID type and retest rather than adding broad permissions as a shortcut.

Common Mistakes

• Changing a production service without recording the old value: always establish a rollback point first.
• Confusing the service account with the Service SID: they are related to the service’s security context but are not the same identity.
• Assuming UNRESTRICTED means unlimited privileges: the word describes how the Service SID is placed in the token, not whether the entire process has unlimited access.
• Assuming RESTRICTED is automatically safe: it can deny writes the application legitimately needs.
• Ignoring shared-process services: Microsoft requires all services in a shared process to use RESTRICTED if one of them does.
• Granting LocalSystem broad ACL access after a failure: this can defeat the point of service isolation.
• Skipping verification: a successful SC command does not prove the application still works.

Hands-On Exercise

Use a disposable Windows VM. Do not use a production machine for this exercise.

1. Open an elevated Command Prompt or PowerShell window.
2. Choose a noncritical test service whose behavior you understand.
3. Run sc.exe qc SERVICE_NAME.
4. Run sc.exe qsidtype SERVICE_NAME and save the result.
5. Run sc.exe showsid SERVICE_NAME and record the service SID.
6. If the service is suitable for the lab, configure UNRESTRICTED.
7. Follow the documented restart/reboot requirement for the test environment.
8. Run qsidtype again.
9. Create a disposable folder and experiment with granting access to NT SERVICE\ServiceName.
10. Verify the service still starts and performs its intended function.
11. Restore the original SID type when the lab is complete.

Knowledge Check

1. What does sc.exe sidtype change?
2. What is the difference between sidtype and qsidtype?
3. What are the three supported Service SID types?
4. Does NONE mean the service has no security identity?
5. What does UNRESTRICTED add to the service process token?
6. What additional behavior does RESTRICTED introduce?
7. Why is the shared-process rule important?
8. Which command displays the actual Service SID?
9. Why should ACL dependencies be checked before changing SID type?
10. Why should the running service be tested after the change?

Answers

1. The configured Service SID type for a Windows service.
2. sidtype changes the setting; qsidtype only queries it.
3. NONE, UNRESTRICTED, and RESTRICTED.
4. No. The service still runs under its configured account and has a process token.
5. The service-specific SID is added to the process token.
6. The Service SID is also added to the restricted SID list along with additional restricted identities, creating a tighter authorization boundary.
7. If one service in a shared process is restricted, Microsoft requires all services in that process to be restricted.
8. sc.exe showsid SERVICE_NAME.
9. Existing permissions may depend on the current service identity and can break after the change.
10. A successful configuration write does not prove that startup, file access, registry access, networking, or application behavior still works.

Key Takeaway

sc.exe sidtype is the configuration command for Windows per-service identities. Use UNRESTRICTED when a supported service needs a distinct SID that can be granted narrowly scoped access. Use RESTRICTED only when the service and every required resource have been designed and tested for the restricted-token model. Use NONE only when you understand what permissions will disappear with the Service SID.

This lesson also connects directly to Windows Command #47 – sc privs: privileges define what powerful system operations a service may request, while Service SID configuration helps define which securable resources can identify and authorize that specific service. Together they are part of Windows Service Hardening.

Primary references: Microsoft Learn — Configuring a Service Using SC, Microsoft Learn — SERVICE_SID_INFO, Microsoft — Windows Service Hardening, and Microsoft System Center — Service SID.

Next: Windows Command #50 will cover sc showsid, the command that displays the actual S-1-5-80-... Service SID generated from a service name.

BitcoinVersus.Tech provides technical education and analysis for informational purposes only. Test service-security changes in a disposable environment before applying them to production systems.

BitcoinVersus.Tech Editor’s Note:
We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support to help further secure the integrity of our research initiatives, please donate using the QR code provided

For best QR-code scanning results, please scan this donation code from a desktop or larger screen. Mobile screens may prevent camera recognition.