An Invoke-Command script against a remote Windows server fails with access denied when it reaches a file share, though the same code works when run locally on that server. What is happening in PowerShell remoting, and what are your options?

## Restating the symptom precisely The code works when you sign in to the server and run it. It fails when the identical code arrives via `Invoke-Command` or a `PSSession`. That difference — same code, same account, different arrival path — is the signature of a delegation problem, and recognising it quickly is what the question is testing. ## What remoting sets up in the first place `Enable-PSRemoting -Force` on the target starts and auto-starts the **WinRM** service, creates a listener, registers the default session configurations, and opens the firewall. WinRM listens on **5985** for HTTP and **5986** for HTTPS. "HTTP" alarms people; it should not, on its own, because the session payload is encrypted with the key negotiated during authentication. HTTPS exists for cases where you also need certificate-based server identity or must satisfy a policy that inspects transport, and for non-domain targets where the negotiated authentication is weaker. Who may connect is a Windows authorization decision: the session configuration's own security descriptor, effectively the local Administrators group plus the built-in **Remote Management Users** group. ## Who you authenticate as Inside a domain, the default `Negotiate` authentication resolves to **Kerberos** against the target's service principal — which is also why remoting to a machine by IP address or to a workgroup box falls back to NTLM and requires the client's `TrustedHosts` list to be populated, since Kerberos cannot name the target. Kerberos authenticates you *to that one server*. The ticket it holds is good for proving who you are to itself. It is not, by default, usable by that server to go and impersonate you somewhere else. That restraint is deliberate: a compromised member server should not be able to walk your identity around the network. ## The second hop ```powershell $s = New-PSSession -ComputerName app01.corp.example Invoke-Command -Session $s -ScriptBlock { Get-Content \\fs01.corp.example\config\app.config } ``` Hop one: your workstation to `app01`, authenticated. Hop two: `app01` to `fs01`, and here `app01` has no credential of yours to present. Depending on configuration the share sees the computer account `APP01$` or an anonymous request; either way the access check fails. The same shape appears with SQL Server, remote registry, another `Invoke-Command`, or an AD query against a specific domain controller — anything crossing a second authenticated boundary. ## The options, best first **Resource-based Kerberos constrained delegation (RBCD).** Configure it on the *resource* — the file server's computer object — listing which intermediate machines may obtain tickets on a user's behalf: ```powershell Set-ADComputer -Identity fs01 -PrincipalsAllowedToDelegateToAccount (Get-ADComputer app01) ``` This is the modern recommendation because the trust decision belongs to the owner of the resource being protected, it needs no domain-admin edit of the front-end object, and it works across domains in a forest. Scope stays narrow: `app01` gains the ability to reach `fs01` as callers, and nothing else. **Pass a credential to the inner command.** Frequently the real answer. If the remote code can accept a `PSCredential` and use it for the second hop — a cmdlet with `-Credential`, a mapped connection, a service account — no delegation is required at all. The cost is credential handling: it must come from a secret store or a managed identity, never a literal in the script. **Just Enough Administration (JEA).** Register a constrained session configuration that runs under a virtual or group-managed service account with exactly the rights the task needs. The connecting user never holds those rights; the endpoint does, and it is audited. This turns a delegation problem into an authorization design, and it is the answer that impresses at senior level. **CredSSP.** `-Authentication CredSSP` forwards your actual credentials to the target so it can reauthenticate as you anywhere. It works, it is easy, and it means a compromise of that server is a compromise of every account that has ever connected to it that way. Acceptable as a scoped, temporary measure with eyes open; a bad standing configuration for a management path. **Restructure the work.** Sometimes the cleanest fix is to stop making the hop: copy the file to the session (`Copy-Item -ToSession`), or run the job from a host that already has direct access, so no delegation exists to get wrong. ## Running against a fleet The same authentication story governs fan-out. `Invoke-Command -ComputerName` accepts a list and runs in parallel up to `-ThrottleLimit`, which defaults to 32 concurrent connections. Every one of those sessions has the same first-hop identity and the same second-hop limitation, so a script that silently depends on a share will fail on all of them at once — which is usually how people discover the double hop in the first place. ## What a strong answer sounds like Name it as a double hop within a sentence or two; attribute it to Kerberos delegation rather than to PowerShell; propose RBCD or a credential passed inward; mention CredSSP but immediately qualify the exposure it creates. Candidates who reach straight for CredSSP as *the* fix are showing you how their environments are configured.