Powershell New-PSSession Access Denied - Administrator Account

Question

I try to use powershell PSSession cmdlets, but I'm struggling with Access Denied Error.

What I try to do is using Administrator Account I run command New-PSSession (or Enter-PSSession) and unfortunately I receive Access Denied Error.

I follow all the instructions correctly I believe, cause on the other server I can run those commands with no troubles.

In addition I'd like to inform that test-wsman return me an response. I'm using Built-In Administrator Account and already checked Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI All the privileges seems to be ok. I have no more ideas, looking for help.

UPDATE

I found one interesting behaviour:

Let's assume that:

• IP Address of machine is 22.222.222.222
• I log via remote desktop using Administrator Credentials

I use following commands:

new-pssession // access denied

new-pssession localhost // access denied

new-pssession 127.0.0.1 // access denied

new-pssession 22.222.222.222 // Session created ! It's working !

new-pssession 22.222.222.222 -Credential Get-Credential // access denied (using the same administrator credentials which I'm using for RDP)

I can add that on the other server when I run exactly the same commands all commands are successful.

Any Ideas?

Answer 1

PS session is used to access remote systems. For that you have to do few configurations:

1) Make sure the winrm service is running in all the destination systems as well as in your local system too.

2) You have to enable PS Remoting. Enable-PSRemoting configures a computer to receive PowerShell remote commands sent with WS-Man.

So,Start Windows PowerShell as an administrator

Enable-PSRemoting –Force

3) You need to add the remote computer to the list of trusted hosts for the local computer in WinRM. To do so, type:

winrm s winrm/config/client '@{TrustedHosts="RemoteComputer"}'

4) Check the configuration using:

winrm quickconfig

Once done, you can use the New-Pssession command to create an interactive session with the destination system.

Else, you can use Invoke-Command to perform some remote operation like below:

I have mentioned in the comment section how it has to work. Sample :

$username = "Username"
$password = "Password"
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr

# will list all the processess in the remote system 
# if you are the entireprise admin or the domain admin then you do not have to pass the credentials. It will take the windows authentication by default.
Invoke-Command -ComputerName RemoteServer -ScriptBlock {Get-Process } -Credential $cred

Since you have updated the question: Let me tell you point wise:

127.0.0.1 and localhost -- both are pointing to local system. Means you have to add them in the trusted hosts list of the local system. It is not advisable to use PSSession for the localsystem cause you can directly run all the ps cmdlets in the PS console.

22.222.222.222 -- working cause you have add that in the trusted host list and it is using the windows authentication by default

22.222.222.222 -Credential Get-Credential ---- not working because the format is a bit wrong. Use like this:

New-PSSession -ComputerName 22.222.222.222 -Credential (Get-Credential)

Hope it helps you.

Answer 2

There is a possible answer to this at the end, but a bit of background may help so I'm starting with that.

Intro

It is important to note that my answer is only related to loopback (localhost) sessions. It does not address problems with remote sessions.

Loopback sessions are useful as they enable a user with administrator rights to invoke user commands or scripts on the local host. An example of this is a toast message to a logged in user from a system monitoring program run under the System user. (Yes, there may be better ways of doing this but that's not what is being discussed here).

Background

I had exactly the same problem with exactly the same results as what is shown in the updates section of @Piotr's original question. I searched extensively on Google for an answer, but this yielded no working answers—even though a few people were reporting very similar issues.

Specs

As most people using Powershell remoting seem to not have this problem, it may be related to my machine's specs:

• Windows 10 Home Version 1803.
• Private network using WiFi connection

PS Env:\> $PSVersionTable
    
Name                           Value
----                           -----
PSVersion                      5.1.17134.858
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17134.858
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Possible Answer

The EnableNetworkAccess option worked for me, but I don't know why yet. It is confirmed to work for the PowerShell commands New-PSSession and Invoke-Command, and may work for others as well.

Examples

To configure PowerShell remoting, the following command is needed once—though it will not harm anything if it is repeated. It will only work on private (not public) networks.

PS Env:\> Enable-PSRemoting -force

The following examples don't require an entry in Trusted Hosts.

LAPTOP-XZ is the computer name == $env:COMPUTERNAME

. = dot alias for localhost

Invoke-Command -ComputerName . -ScriptBlock { dir } -EnableNetworkAccess
    
New-PSSession -EnableNetworkAccess
New-PSSession localhost -EnableNetworkAccess
New-PSSession 127.0.0.1 -EnableNetworkAccess
New-PSSession LAPTOP-XZ -EnableNetworkAccess

The IPv4 Address of the computer (192.168.1.103, in my case) will only work if it is included in Trusted Hosts. The EnableNetworkAccess option isn't needed in this case.

PS Env:\> Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.103"
    
New-PSSession 192.168.1.103 

Note that including localhost and its other aliases in Trusted Hosts doesn't work in the above example (-EnableNetworkAccess is needed).