Access Denied error when running remote PowerShell script to query Server B file share

Zephyr Vance 20 Reputation points
2026-09-07T16:23:54.5733333+00:00

I am running a remote PowerShell script on Server A, but the same issue keeps happening every time I try to run it. The script does not properly query the file share on Server B. Most of the time it simply fails with an Access Denied error, and even though my account has the right permissions, it still completely blocks the connection. It acts like there is a double-hop authentication problem, like we need to configure Kerberos Constrained Delegation or Credential Security Support Provider (CredSSP) to make it work, but I am not exactly sure how to set that up. We are using Windows Servers.

Windows for business | Windows 365 Enterprise
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Chen Tran 12,770 Reputation points Independent Advisor
    2026-09-07T17:18:33.6866667+00:00

    Hello Zephyr Vance,

    Thank you for posting question on Microsoft Windows Forum!

    Based on the issue description. The plausible explanation to this behavior is that when you run a script remotely on Server A, your session is authenticated via a "Network Logon." By design, Windows prevents Server A from taking your credentials and using them to authenticate against a third machine (Server B). This is an essential protection against rogue servers impersonating administrators across the network.

    You can consider to configure traditional KCD. This tells Active Directory that Server A is explicitly allowed to delegate credentials for the cifs (file share) service on Server B. Open ADUC. Then locate the computer object for Server A, right-click, and open Properties. Navigate to the Delegation tab. Select Trust this computer for delegation to specified services only and choose Use Kerberos only. Click Add... -> Users or Computers... -> Type in Server B and confirm. From the list of available services, select cifs (which covers SMB and file shares). Apply the changes.

    Regarding CredSSP which might solve the problem by sending the actual plain-text credentials to Server A. Server A caches them in memory and then authenticates to Server B as if you were sitting locally at the console. However, please be aware: Because CredSSP leaves your credentials sitting in the LSASS process on Server A, it represents a massive credential theft risk. If Server A is compromised, attackers can easily extract your domain credentials. It is generally recommended to strictly limit or disable CredSSP in enterprise environments.

    Hope the response provided some helpful insight. If you find this answer useful. Please feel free to hit “Accept” so I know it addressed your concern.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.