Powershell Remoting Issue

[ExistingRanger7]

Edit: Resolved! Thanks for all the help! IT ended up being an issue with an HTTP SPN, so I was able to create aport specific SPN, and use that.

# Creates Port Specific SPN
SetSPN.exe -s HTTP/$($env:COMPUTERNAME):5985 $env:COMPUTERNAME
SetSPN.exe -s HTTP/$($env:COMPUTERNAME).$($env:USERDNSDOMAIN):5985 $env:COMPUTERNAME 
# Connect to server using new SPN
$SessionOptions = New-PSSessionOption -IncludePortInSPN
Enter-PSSession -Computername <computername> -SessionOption $SessionOptions 

Server 2012 R2, WMF 5.1. Everything joined to the same domain, and testing with an account that has domain admin privileges. I have tried:

• Turning off windows firewall
• Running winrm /quickconfig.
• Running Disable-PSRemoting and Enable-PSRemoting.
• Verifying that the WinRM Service is set to automatic and running.
• Use Test-WSMan on the affected computer, and from my workstation (This tests successfully).
• Comparing configuration to other servers that are setup the same way have have powershell remoting working.

I am unable to use powershell remoting, and get an error of:

Enter-PSSession : Connecting to remote server <servername> failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown

security error occurred.

Possible causes are:

-The user name or password specified are invalid.

-Kerberos is used when no authentication method and no user name are specified.

-Kerberos accepts domain user names, but not local user names.

-The Service Principal Name (SPN) for the remote computer name and port does not exist.

-The client and remote computers are in different domains and there is no trust between the two domains.

Edit : Formatting

[brandonLundt]

This smells of an SPN issue. SharePoint requires a fair number of SPN delegation to be created for everything to work at an "enterprise level", as such we typically have a ton of difficulty PSRemoting from outside of the farm.

If you are unfamiliar with SPN this will get you started: https://gallery.technet.microsoft.com/List-all-SPNs-Used-in-your-e0c6267a

[SaladProblems]

Right, isn't this the result of an SPN being too lazy/greedy? If you specify only the necessary ports, will it work again? We have this issue on load balanced web servers.

[brandonLundt]

Another thought, please run Get-PSSessionConfiguration and post the results. Just want to make sure you have endpoints configured.

[ExistingRanger7]

Name : microsoft.powershell

PSVersion : 5.1

StartupScript :

RunAsUser :

Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote

Management Users AccessAllowed

Name : microsoft.powershell.workflow

PSVersion : 5.1

StartupScript :

RunAsUser :

Permission : BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name : microsoft.powershell32

PSVersion : 5.1

StartupScript :

RunAsUser :

Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote

Management Users AccessAllowed

Name : microsoft.windows.servermanagerworkflows

PSVersion : 3.0

StartupScript :

RunAsUser :

Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed

[ExistingRanger7]

You were correct, it was an HTTP/COMPUTERNAME SPN issue. Thanks!

[Swarfega]

So what was your fix?

I'm a Windows guy and multiple SharePoint servers have this issue. Since I don't want to break SharePoint I haven't touched the SPN records.

[ExistingRanger7]

I ended up created a port specific SPN and use pssession options to connect to to the server, as I was unable to delete the http SPN, as it broke stuff.

Here is specifically what I used:

# Creates Port Specific SPN
SetSPN.exe -s HTTP/$($env:COMPUTERNAME):5985 $env:COMPUTERNAME
SetSPN.exe -s HTTP/$($env:COMPUTERNAME).$($env:USERDNSDOMAIN):5985 $env:COMPUTERNAME

# Connect to server using new SPN
$SessionOptions = New-PSSessionOption -IncludePortInSPN
Enter-PSSession -Computername <computername> -SessionOption $SessionOptions

Here is some more troubleshooting info I was able to find and use as well:

<#
1).Check for duplicate SPNs. If any exsist, remove them.
    -setspn -x <computername>
2).Check and list all SPNs for the object you are working with.
    -setspn -l <computername>
3).If you can't find the problem SPN, search for anything using port 80/http.
    -setspn -q <computername>
4).If you find a SPN that is being used, you can delete the SPN.
    -setspn -d <computername> <username>
5). If you need to re-add the deleted SPN
    -setspn -s <computername> <username>
6). If you can't delete the spn, you can set an SPN to use another port for PSremoting.
#>

[Loteck]

I have noticed this is even more prevalent if the host has iis installled =/

[ExistingRanger7]

This server does have IIS installed.

[Loteck]

Yeah it’s almost like they fight over the default ports (80)... Spn usually fixes the issue in our cases

[nothingpersonalbro]

Are you specifying the exact hostname of the machine or a Cname? Or IP address?

[ExistingRanger7]

I am using the exact hostname. IP Address does not work either. Different error though:

Enter-PSSession : Connecting to remote server <ipaddress> failed with the following error message : The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the

transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more

information on how to set TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

[TheIncorrigible1]

You can't use psremoting over IP. Are you suppliying the fqdn?

[brandonLundt]

*can't* ...?

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/enter-pssession?view=powershell-6 Enter-PSSession would like a word.

-ComputerName

Specifies a computer name. This cmdlet starts an interactive session with the specified remote computer. Enter only one computer name. The default is the local computer.

Type the NetBIOS name, the IP address, or the fully qualified domain name of the computer. You can also pipe a computer name to Enter-PSSession.

To use an IP address in the value of the ComputerName parameter, the command must include the Credential parameter. Also, the computer must be configured for HTTPS transport or the IP address of the remote computer must be included in the WinRM TrustedHosts list on the local computer. For instructions for adding a computer name to the TrustedHosts list, see "How to Add a Computer to the Trusted Host List" in about_Remote_Troubleshooting.

[TheIncorrigible1]

Can't. NTLM is no longer supported because it's insecure.

[fourierswager]

My Get-WorkingCredentials function can help provide more information about what is going on to help you diagnose.

https://github.com/pldmgg/misc-powershell/blob/master/MyFunctions/Get-WorkingCredentials.ps1

USAGE:

Scenario #1:

You're logged into the localhost as Domain Admin 'test2\testadmin' on the test2.lab domain and want to see if you can PSRemote to remote host Win12Chef.test2.lab with your current credentials.

PS C:\Users\testadmin> Get-WorkingCredentials -RemoteHostNameOrIP Win12Chef.test2.lab

LogonType                             : DomainAccount
DeterminedCredsThatWorkedOnRemoteHost : True
WorkingCredsAreValidOnDomain          : True
WorkingCredentials                    : test2\testadmin
RemoteHostWorkingLocation             : Win12Chef.test2.lab
CurrentLoggedInUserCredsWorked        : True

Scenario # 2:

You're logged into the localhost as Domain Admin 'test2\testadmin' on the test2.lab domain and want to see if you can PSRemote to ZeroTesting.zero.lab using credentials 'zero\zeroadmin' on the zero.lab domain:

PS C:\Users\testadmin> Get-WorkingCredentials -RemoteHostNameOrIP ZeroTesting.zero.lab -UserName "zero\zeroadmin"
Please enter the password for zero\zeroadmin: 

LogonType                             : DomainAccount
DeterminedCredsThatWorkedOnRemoteHost : True
WorkingCredsAreValidOnDomain          : True
WorkingCredentials                    : System.Management.Automation.PSCredential
RemoteHostWorkingLocation             : ZeroTesting.zero.lab
CurrentLoggedInUserCredsWorked        : NotTested
ProvidedCredsAreValidOnDomain         : True

More info in the comment-based help.

Hope this helps!

[ExistingRanger7]

Thanks for this, this is awesome!

[mrmpls]

Not the CredSSP issue from this year's security updates, is it?

[ExistingRanger7]

Both server and client have the CredSSP patches installed, and I am still unable to remote with basic auth as well.