Raw New Markdown
Generating updated version of doc...
Rendered New Markdown
Generating updated version of doc...
---
title: Run a service under system and local security accounts
description: Learn how to run a Service Fabric application under system and local security accounts. Create security principals and apply the Run-As policy to securely run your services.
ms.topic: how-to
ms.author: tomcassidy
author: tomvcassidy
ms.service: azure-service-fabric
services: service-fabric
ms.date: 03/22/2026
# Customer intent: "As a cloud application developer, I want to secure my Service Fabric applications by configuring them to run under local or system user accounts, so that I can manage permissions and enhance security for my services."
---
# Run a service as a local user account or local system account
By using Azure Service Fabric, you can secure applications that are running in the cluster under different user accounts. By default, Service Fabric applications run under the account that the Fabric.exe process runs under. Service Fabric also provides the capability to run applications under a local user or system account. Supported local system account types are **LocalUser**, **NetworkService**, **LocalService**, and **LocalSystem**. If you're running Service Fabric on a Windows standalone cluster, you can run a service under [Active Directory domain accounts](service-fabric-run-service-as-ad-user-or-group.md) or [group managed service accounts](service-fabric-run-service-as-gmsa.md).
In the application manifest, you define the user accounts required to run services or secure resources in the **Principals** section. You can also define and create user groups so that one or more users can be managed together. This is useful when there are multiple users for different service entry points and they need common privileges that are available at the group level. The users are then referenced in a RunAs policy, which is applied to a specific service or all the services in the application.
By default, the RunAs policy is applied to the main entry point. You can also apply a RunAs policy to the setup entry point, if you need to [run certain high-privilege setup operations under a system account](service-fabric-run-script-at-service-startup.md), or both main and setup entry points.
> [!NOTE]
> If you apply a RunAs policy to a service and the service manifest declares endpoint resources with the HTTP protocol, you must specify a **SecurityAccessPolicy**. For more information, see [Assign a security access policy for HTTP and HTTPS endpoints](service-fabric-assign-policy-to-endpoint.md).
>
## Run a service as a local user
You can create a local user that can be used to help secure a service within the application. When a **LocalUser** account type is specified in the principals section of the application manifest, Service Fabric creates local user accounts on machines where the application is deployed. By default, these accounts don't have the same names as those specified in the application manifest (for example, *Customer3* in the following application manifest example). Instead, they're dynamically generated and have random passwords.
In the **RunAsPolicy** section for a **ServiceManifestImport**, specify the user account from the **Principals** section to run the service code package. The following example shows how to create a local user and apply a RunAs policy to the main entry point:
```xml
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application7Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="Web1_InstanceCount" DefaultValue="-1" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Web1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
<Policies>
<RunAsPolicy CodePackageRef="Code" UserRef="Customer3" EntryPointType="Main" />
</Policies>
</ServiceManifestImport>
<DefaultServices>
<Service Name="Web1" ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]">
<SingletonPartition />
</StatelessService>
</Service>
</DefaultServices>
<Principals>
<Users>
<User Name="Customer3" />
</Users>
</Principals>
</ApplicationManifest>
```
## Create a local user group
You can create user groups and add one or more users to the group. This is useful if there are multiple users for different service entry points and they need to have certain common privileges that are available at the group level. The following application manifest example shows a local group named *LocalAdminGroup* that has administrator privileges. Two users, *Customer1* and *Customer2*, are made members of this local group. In the **ServiceManifestImport** section, a RunAs policy is applied to run the *Stateful1Pkg* code package as *Customer2*. Another RunAs policy is applied to run the *Web1Pkg* code package as *Customer1*.
```xml
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application7Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="Stateful1_MinReplicaSetSize" DefaultValue="3" />
<Parameter Name="Stateful1_PartitionCount" DefaultValue="1" />
<Parameter Name="Stateful1_TargetReplicaSetSize" DefaultValue="3" />
<Parameter Name="Web1_InstanceCount" DefaultValue="-1" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Stateful1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
<Policies>
<RunAsPolicy CodePackageRef="Code" UserRef="Customer2" EntryPointType="Main"/>
</Policies>
</ServiceManifestImport>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Web1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
<Policies>
<RunAsPolicy CodePackageRef="Code" UserRef="Customer1" EntryPointType="Main"/>
</Policies>
</ServiceManifestImport>
<DefaultServices>
<Service Name="Stateful1" ServicePackageActivationMode="ExclusiveProcess">
<StatefulService ServiceTypeName="Stateful1Type" TargetReplicaSetSize="[Stateful1_TargetReplicaSetSize]" MinReplicaSetSize="[Stateful1_MinReplicaSetSize]">
<UniformInt64Partition PartitionCount="[Stateful1_PartitionCount]" LowKey="-9223372036854775808" HighKey="9223372036854775807" />
</StatefulService>
</Service>
<Service Name="Web1" ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]">
<SingletonPartition />
</StatelessService>
</Service>
</DefaultServices>
<Principals>
<Groups>
<Group Name="LocalAdminGroup">
<Membership>
<SystemGroup Name="Administrators" />
</Membership>
</Group>
</Groups>
<Users>
<User Name="Customer1">
<MemberOf>
<Group NameRef="LocalAdminGroup" />
</MemberOf>
</User>
<User Name="Customer2">
<MemberOf>
<Group NameRef="LocalAdminGroup" />
</MemberOf>
</User>
</Users>
</Principals>
</ApplicationManifest>
```
## Apply a default policy to all service code packages
You use the **DefaultRunAsPolicy** section to specify a default user account for all code packages that donβt have a specific **RunAsPolicy** defined. If most of the code packages that are specified in the service manifest used by an application need to run under the same user, the application can just define a default RunAs policy with that user account. The following example specifies that if a code package doesn't have a **RunAsPolicy** specified, the code package should run under the **MyDefaultAccount** user specified in the principals section. Supported account types are LocalUser, NetworkService, LocalSystem, and LocalService. If using a local user or service, also specify the account name and password.
```xml
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application7Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="Web1_InstanceCount" DefaultValue="-1" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Web1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
</ServiceManifestImport>
<DefaultServices>
<Service Name="Web1" ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]">
<SingletonPartition />
</StatelessService>
</Service>
</DefaultServices>
<Principals>
<Users>
<User Name="MyDefaultAccount" AccountType="NetworkService" />
</Users>
</Principals>
<Policies>
<DefaultRunAsPolicy UserRef="MyDefaultAccount" />
</Policies>
</ApplicationManifest>
```
## Debug a code package locally using console redirection
Occasionally, it's useful for debugging purposes to see the console output from a running service. You can set a console redirection policy on the entry point in the service manifest, which writes the output to a file. The file output is written to the application folder called **log** on the cluster node where the application is deployed and run.
> [!WARNING]
> Never use the console redirection policy in an application that is deployed in production because this can affect the application failover. *Only* use this for local development and debugging purposes.
>
>
The following service manifest example shows enabling console redirection with a FileRetentionCount value:
```xml
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>VotingWeb.exe</Program>
<WorkingFolder>CodePackage</WorkingFolder>
<ConsoleRedirection FileRetentionCount="10"/>
</ExeHost>
</EntryPoint>
</CodePackage>
```
<!--Every topic should have next steps and links to the next logical set of content to keep the customer engaged-->
## Next steps
* [Understand the application model](service-fabric-application-model.md)
* [Specify resources in a service manifest](service-fabric-service-manifest-resources.md)
* [Deploy an application](service-fabric-deploy-remove-applications.md)
[image1]: ./media/service-fabric-application-runas-security/copy-to-output.png
View on GitHub