DSC File resource lacks explicit permission boundary for remote file system access

Direct Answer

Use the File resource's Credential property to execute remote writes under a dedicated least-privilege identity, and enforce the final boundary with NTFS and share ACLs on the target. In supported Windows PowerShell 5.1 and PowerShell 7+ DSC scenarios, the engine does not apply a built-in sandbox, Constrained Language Mode, or JEA restriction to file system calls. It runs under the identity of the DSC service or the session that invokes Start-DscConfiguration.

What the DSC Engine Actually Enforces

Confirmed behavior: The File resource performs I/O using the access token of the process hosting the DSC engine. By default this is often the LocalSystem account for the DSC service, or the interactive user during a push configuration. DSC does not insert a permission layer between the resource and the file system.

Likely explanation: Administrators sometimes expect Constrained Language Mode or JEA to constrain the File resource. CLM restricts PowerShell language features and cmdlet availability, not underlying Win32 or .NET file I/O. JEA limits which commands a connected user may invoke, but it does not automatically wrap DSC's internal provider operations unless the entire DSC execution is hosted inside a JEA endpoint. This is consistent across supported releases, though exact service-account defaults can vary by deployment method (push, pull, or cloud-hosted LCM).

Steps to Bound Remote File Writes

1. Create or identify a least-privilege account—a group Managed Service Account is preferable—with modify rights only on the specific UNC share and folder.
2. Pass that identity to the resource via Credential:

   File RemoteConfig {
       Ensure          = 'Present'
       Type            = 'File'
       SourcePath      = '\\src\share\app.conf'
       DestinationPath = '\\tgt\share\app.conf'
       Credential      = $Cred
   }

3. Ensure the target machine's SMB share permissions and NTFS ACLs allow only that account. Do not grant the DSC service account or LocalSystem broad rights on the remote share.
4. If the DSC service itself runs as LocalSystem, reconfigure it to run as a constrained service account so the engine's ambient token is not over-privileged.

Verification and Version Notes

• On Windows PowerShell 5.1, inspect the DSC service account: Get-CimInstance Win32_Service -Filter "Name='dsm'" | Select-Object Name, StartName.
• From a session running as the delegated account, verify write access: Test-Path \\tgt\share\app.conf.
• Confirm language mode: $ExecutionContext.SessionState.LanguageMode. Expect FullLanguage unless CLM is explicitly enabled.
• After Start-DscConfiguration, review DSC operational event logs for permission failures.

One missing diagnostic detail would change the recommendation: is the DSC service currently running as LocalSystem? If so, the boundary must also be moved to the service account; otherwise the resource-level Credential is the primary control.