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


15 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