A: Service isolation lets administrators control what local resources (e.g., files, registry keys on the local machine) a Windows service can access. Microsoft introduced service isolation in Windows Vista and Windows Server 2008.
On previous Windows versions, when you use one of the built-in high-privilege local accounts for running the service (Local System, Network Service, or Local Service -- this is the account you configure on the Log On tab of the service's properties) and you grant that service account access to a resource (in the access control settings of the resource), you also implicitly allow all other services that run under the same service account to access that resource, whether they need access to it or not.
To avoid this security problem, administrators typically create a custom Windows account to run their services. This solution, however, creates additional account management overhead. When you create custom service accounts, you also can't leverage the automated password management features that Windows provides for the built-in accounts.
Service isolation builds on new service-specific SIDs that you can enable for each Windows service. They let administrators isolate a resource for a service's exclusive use by securing the resource with an access control entry that refers to the service's service-specific SID.
A service-specific SID is linked to the service's name (e.g., Myservice), and not to the service account (for example, LocalSystem). Service-specific SIDs are used for authorizing a service; the service account is used for authenticating a service.
Thanks to service-specific SIDs, administrators don't need to worry anymore about the cumbersome process of creating and maintaining custom service accounts. They can now continue to use the built-in service accounts for authenticating their services while relying on service-specific SIDs for authorizing services and setting permissions on the services' resources.
To generate a service-specific SID for a service, you must set the service's SID type property to either "unrestricted" or "restricted." You can do so by using the sc command as follows:
sc sidtype<service_name> unrestricted
After you run this command, the next time the service starts, Windows adds the service-specific SID to the access token of the process that hosts the service. Service-specific SIDs are local (machine-level as opposed to domain-level) SIDs.
To query the current value of a service's SID type property, you can use the following sc command:
sc qsidtype <service_name>
After you have enabled a service-specific SID for a service by using the sc command, you can leverage the SID to restrict access to the service's local file system and registry resources. To refer to a service-specific SID when setting permissions on resources, you must use the syntax NT SERVICE\<service_name>
Windows constructs service-specific SIDs from the service name by using the following formula:
S-1-5-80-{SHA-1(service name in uppercase)}
where SHA-1 stands for the application of the SHA-1 hash function on the service name in uppercase. This formula illustrates how, for a given service, the service-specific SIDs will be identical on different Windows machines. This system greatly facilitates resource permissioning for an identical service that might be hosted on different Windows machines.
