How to Configure NetworkService or LocalService for Windows Services on a Domain Controller


2 views

When configuring Windows Services on domain-joined machines or standalone workstations, specifying NT AUTHORITY\NetworkService or NT AUTHORITY\LocalService is straightforward through the Services management console (services.msc). However, domain controllers present a unique challenge because they don't expose these built-in accounts in the standard user selection dialog.

On domain controllers, the local security subsystem is replaced by the Active Directory security subsystem. The "Select User or Service Account" dialog only shows domain accounts and managed service accounts, not local machine principals like NetworkService.

Here are several methods to configure these accounts on a domain controller:

Method 1: Direct Registry Editing

You can modify the service configuration directly in the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName]
"ObjectName"="NT AUTHORITY\\NetworkService"

Method 2: Using SC Command

The sc command-line tool bypasses the GUI limitations:

sc config "YourServiceName" obj= "NT AUTHORITY\NetworkService" password= ""

Method 3: Manual Entry in Services Console

Despite the dialog limitations, you can still type the account names directly:

  1. Open services.msc
  2. Right-click your service and select Properties
  3. Go to the Log On tab
  4. Select "This account" and type exactly: NT AUTHORITY\NetworkService
  5. Leave the password fields blank

When using these accounts on a domain controller:

  • NetworkService runs with the computer account's privileges in the domain
  • Services running as NetworkService can access network resources as the domain controller's computer account
  • Audit these services carefully as they have elevated domain privileges

For enterprise environments, consider using gMSAs instead:

# Create a new gMSA
New-ADServiceAccount -Name "svc_YourApp" -DNSHostName "yourdomain.com" 
-PrincipalsAllowedToRetrieveManagedPassword "DC01$","DC02$"

# Install the gMSA on the domain controller
Install-ADServiceAccount -Identity "svc_YourApp"

# Configure the service to use the gMSA
sc config "YourServiceName" obj= "DOMAIN\svc_YourApp$" password= ""

If you encounter errors after configuration:

  • Verify the service account name is spelled exactly as shown
  • Ensure no password is specified for built-in accounts
  • Check the system event log for detailed error messages
  • Test with a simple service first to validate your approach

When configuring Windows Services on domain controllers, administrators encounter a unique challenge: the standard GUI methods for specifying built-in accounts like NT AUTHORITY\NetworkService or NT AUTHORITY\LocalService become unavailable. This occurs because:

  • Domain controllers don't maintain local machine security principals
  • The service account selection dialog defaults to domain accounts only
  • Built-in security principals aren't exposed in the standard UI

Here are three reliable methods to configure these accounts:

Method 1: Using Service Control Manager (SCM) Command Line

The most straightforward approach using the sc.exe utility:

sc config "YourServiceName" obj= "NT AUTHORITY\NetworkService" password= ""

Or for LocalService:

sc config "YourServiceName" obj= "NT AUTHORITY\LocalService" password= ""

Method 2: Direct Registry Modification

For advanced scenarios where SCM isn't accessible:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName]
"ObjectName"="NT AUTHORITY\\NetworkService"

Method 3: PowerShell Automation

For scripting deployments across multiple DCs:

$service = Get-WmiObject -Class Win32_Service -Filter "Name='YourServiceName'"
$service.Change($null,$null,$null,$null,$null,$null,"NT AUTHORITY\\NetworkService","",$null,$null,$null)

When using these accounts on domain controllers:

  • NetworkService runs with domain computer account privileges
  • LocalService has significantly reduced privileges
  • Neither account has domain admin rights by default

If you encounter "The account name is invalid" errors:

  1. Verify exact spelling: NT AUTHORITY\NetworkService (case insensitive)
  2. Ensure no trailing spaces in the account name
  3. Check service dependencies aren't requiring domain accounts

For scenarios requiring more granular control:

  • Create dedicated domain service accounts with minimum privileges
  • Use Group Managed Service Accounts (gMSA) in Windows Server 2012+
  • Consider Virtual Accounts for single-service isolation