How to Properly Grant Network Service Account Access to Remote SMB Share in Windows Domain Environment


1 views

When dealing with service accounts accessing remote resources, it's crucial to understand the security context. The Network Service account (NT AUTHORITY\NETWORK SERVICE) is a built-in local account that presents the computer's domain credentials when accessing network resources. In a domain environment, this means it authenticates as DOMAIN\SERVERNAME$ (the computer account).

Your current approach of granting ServerA's computer account access works, but let's examine the implications:

# This represents the access control entry you're creating
$acl = Get-Acl \\ServerB\Share
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "DOMAIN\SERVERA$", 
    "Modify", 
    "ContainerInherit,ObjectInherit", 
    "None", 
    "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl \\ServerB\Share $acl

For security-conscious environments, consider these approaches:

Option 1: Computer Account Access (Current Method)

Pros:

  • Simple to implement
  • No additional service accounts needed

Cons:

  • Any process running as Network Service on ServerA gets access
  • Difficult to audit specific application access

Option 2: Dedicated Service Account

Create a domain service account specifically for this application:

# Create the service account
New-ADUser -Name "svc_FileAccessApp" -AccountPassword (ConvertTo-SecureString "ComplexP@ssw0rd" -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true

# Grant permissions
$acl = Get-Acl \\ServerB\Share
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "DOMAIN\svc_FileAccessApp", 
    "Read,Write", 
    "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl \\ServerB\Share $acl

Option 3: Group Managed Service Account (gMSA)

For enterprise environments, gMSA provides automatic password management:

# Create gMSA (run on domain controller)
New-ADServiceAccount -Name "gMSA_FileAccess" -DNSHostName "gmsafileaccess.domain.com" -PrincipalsAllowedToRetrieveManagedPassword "SERVERA$"

# On ServerA:
Install-ADServiceAccount -Identity "gMSA_FileAccess"

When implementing any solution:

  • Always follow principle of least privilege
  • Enable auditing on the share (SACL entries)
  • Consider whether the share really needs to be accessed directly
  • Document the access requirements for compliance

Test your configuration using these PowerShell commands:

# Test computer account access
Test-Path \\ServerB\Share -PathType Container

# Test as Network Service context
Invoke-Command -ComputerName ServerA -ScriptBlock {
    Test-Path \\ServerB\Share -PathType Container
}

# Check effective permissions
(Get-Acl \\ServerB\Share).Access | Where-Object {
    $_.IdentityReference -like "*SERVERA*"
} | Format-Table IdentityReference,FileSystemRights -AutoSize

When an application running as NETWORK SERVICE on ServerA accesses a share on ServerB in the same domain, it authenticates using ServerA's computer account (SERVERA$). The NETWORK SERVICE account itself doesn't exist outside ServerA's security context.

# PowerShell example for setting permissions
$SharePath = "\\ServerB\SharedFolder"
$ComputerAccount = "DOMAIN\SERVERA$"

# NTFS Permissions
icacls $SharePath /grant "${ComputerAccount}:(OI)(CI)(M)"

# Share Permissions
Grant-SmbShareAccess -Name "SharedFolder" -AccountName $ComputerAccount -AccessRight Change -Force

Granting access via the computer account (SERVERA$) means:

  • Any service running as NETWORK SERVICE on ServerA can access the share
  • Local accounts on ServerA cannot access the share unless explicitly granted
  • Applications running under different service accounts would need separate permissions

For more granular control, consider:

# Create a dedicated domain service account
$ServiceAccount = "DOMAIN\svc_appserver"

# Apply constrained delegation if needed
Set-AdUser -Identity $ServiceAccount -Add @{"msDS-AllowedToDelegateTo"="cifs/ServerB.domain.com"}

To verify access:

# Test access from ServerA
Test-Path -Path "\\ServerB\SharedFolder\testfile.txt" -ErrorAction Stop

# Check effective permissions
(Get-SmbShare -Name "SharedFolder").PresetFileAccess
(Get-Acl -Path "C:\SharedFolder").Access | Format-Table
  • Apply principle of least privilege
  • Use domain service accounts instead of computer accounts when possible
  • Enable auditing for sensitive file shares
  • Consider using Group Managed Service Accounts (gMSA) in Windows Server 2012 and later