Question
Limitations of PowerShell JEA: No Automatic Credential Refresh in Persistent Sessions
Nia Byte
0 reputation · 29 Mar 2022, 19:01 UTC
110.7K views1
Loading…
0 reputation · 29 Mar 2022, 19:01 UTC
PowerShell Just Enough Administration (JEA) enables least‑privilege remote sessions by constraining users to a predefined command set. A JEA session is typically created with a RunAsCredential that points to a service account. The session remains alive as long as the runspace is open.
When the service account’s password expires, or its Kerberos ticket lapses mid‑session, the remote runspace does not automatically re‑authenticate. Subsequent commands fail with authentication errors, and PowerShell provides no built‑in event or hook to detect the expiration while the session is active. PowerShell 7.x improves error reporting for authentication failures but still lacks a mechanism to refresh credentials or notify the session owner.
RunAsCredential changes.PSRemotingTransportException) are the only documented ways to detect expiration.35275 reputation · 30 Mar 2022, 01:26 UTC
PowerShell JEA sessions do not automatically refresh the RunAsCredential when the underlying service account password expires or its Kerberos ticket lapses.
powershellRunAsCredential; the credential is not renewed during the lifetime of the session.PSRemotingTransportException or AccessDeniedException.The underlying WSMan remoting infrastructure authenticates the runspace at creation time using the supplied credential and then relies on the Windows security subsystem (Kerberos/LSA) to maintain the token. PowerShell does not monitor token validity or trigger a re‑authentication, so once the ticket or password becomes invalid the existing token is no longer accepted and the session appears dead until it is torn down and recreated.
To continue working after a credential expiration you must detect the failure (for example, by catching authentication‑related exceptions) and then close the existing PSSession and create a new one with an updated RunAsCredential. No shorter‑lived refresh mechanism exists in PowerShell.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 30 Mar 2022, 01:35 UTC
The existing answer correctly notes that the RunAs credential is fixed at session creation. It is worth clarifying that two separate Kerberos contexts are involved:
Enter-PSSession or New-PSSession) is renewed by the OS as long as that user's logon session remains active.Consequently, even if the caller's Kerberos tickets are perfectly valid, commands will fail once the RunAs service account's password expires or its own TGT lapses. PowerShell 7.x surfaces this as a PSRemotingTransportException with an inner System.ComponentModel.Win32Exception (error 0x8009030E – SEC_E_LOGON_DENIED), whereas Windows PowerShell 5.1 often returns a generic AccessDeniedException without the transport detail.
Because Register-PSSessionConfiguration -RunAsCredential validates the credential at registration time, rotating the service account password requires:
PSSession objects cannot be migrated.No in-session API exists to swap the RunAs token, so automation must orchestrate the full teardown/recreate cycle.