Powershell remoting with ip-address as target

Question

I successfully enabled PSRemoting on my Server 2008 R2. I'm able to do a remote-pssession from within the same network using the hostname as target.

I'm failing when I try to use the IP-Address as target from any computer (within the network or from another network (for example via VPN)). I want to be able to use remoting through my VPN connection where I have to use the IP-Address since the hostname can't be resolved.

I don't want to add names into my hosts-file because there are a few other servers at our clients' that have the same dns-name and I don't want to remove and insert the name-ip-address-association again and again.

I hope someone can tell me how to allow the psremoting-target to be called via IP.

Edit: To be more specific, I want to be able to run this:

Enter-PSSession -Computername 192.168.123.123 -credentials $cred 

But I'm only able to run that command if I pass a hostname to "-Computername"

Edit2:
I'm getting following errormessage when I try to login using the ip instead of the hostname (from the internal network):

Enter-PSSession : Connecting to remote server 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 HT
TPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure T
rustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to se
t TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting
 Help topic.

Edit3:
I know about the trusted-hosts setting of WSMan, but that doesn't seem to be the problem. It is already set to "*" (I did that right after enabling remoting), but I still can't connect to that server using the ip as target-computername, but I'm able to connect using the hostname as target-computername. Seems like there's something like the binding in IIS that prevents the listener to listen on requests that target the ip-number instead of the hostname. But IIS isn't installed. I don't know where to look for such a setting.

Update 2011-07-12:
Okay, I think that trustedhosts-setting is not the problem because I CAN connect from our DC via hostname but not if I use the ip-address of the destination for the computer-param.
I think, the problem must be the listener. Maybe the listener takes no requests that were targeted to the destination-ip instead of the destination-hostname. But I don't know how to change that.

Optometer

Enable-PSRemoting doesn't have a -ComputerName parameter. Do you mean Enter-PSSession? – Rainfall

uuuh, yes. I'm confused :) I'll edit it. – Optometer

What is the error message you receive when trying the command? – Late

Answer 1

The error message is giving you most of what you need. This isn't just about the TrustedHosts list; it's saying that in order to use an IP address with the default authentication scheme, you have to ALSO be using HTTPS (which isn't configured by default) and provide explicit credentials. I can tell you're at least not using SSL, because you didn't use the -UseSSL switch.

Note that SSL/HTTPS is not configured by default - that's an extra step you'll have to take. You can't just add -UseSSL.

The default authentication mechanism is Kerberos, and it wants to see real host names as they appear in AD. Not IP addresses, not DNS CNAME nicknames. Some folks will enable Basic authentication, which is less picky - but you should also set up HTTPS since you'd otherwise pass credentials in cleartext. Enable-PSRemoting only sets up HTTP.

Adding names to your hosts file won't work. This isn't an issue of name resolution; it's about how the mutual authentication between computers is carried out.

Additionally, if the two computers involved in this connection aren't in the same AD domain, the default authentication mechanism won't work. Read "help about_remote_troubleshooting" for information on configuring non-domain and cross-domain authentication.

From the docs at http://technet.microsoft.com/en-us/library/dd347642.aspx

HOW TO USE AN IP ADDRESS IN A REMOTE COMMAND
-----------------------------------------------------
    ERROR:  The WinRM client cannot process the request. If the
    authentication scheme is different from Kerberos, or if the client
    computer is not joined to a domain, then HTTPS transport must be used
    or the destination machine must be added to the TrustedHosts
    configuration setting.

The ComputerName parameters of the New-PSSession, Enter-PSSession and
Invoke-Command cmdlets accept an IP address as a valid value. However,
because Kerberos authentication does not support IP addresses, NTLM
authentication is used by default whenever you specify an IP address. 

When using NTLM authentication, the following procedure is required
for remoting.

1. Configure the computer for HTTPS transport or add the IP addresses
   of the remote computers to the TrustedHosts list on the local
   computer.

   For instructions, see "How to Add a Computer to the TrustedHosts
   List" below.


2. Use the Credential parameter in all remote commands.

   This is required even when you are submitting the credentials
   of the current user.

Mismate

Thanks Don for your answer. That cleared much of my cluelessness up. I'm not able to test it now, but I will asap. If I understood everything correct, then all I need to do is following this kb to configure WinRM to listen to https-requests too, right? – Optometer

Yup, and also work the TrustedHosts list and explicitly provide credentials. You may also find that you have to enable something like Basic authentication instead of Kerberos. – Mismate

Yes, enabling basic authentication changed the problem. Sadly, I got an access denied message after I followed the instructions and various tutorials and how-to's. I don't know why I hadn't access. The credentials worked when I tried to connect via hostname. Nevermind... I found a solution that doesn't require PSRemoting. But thanks for your help. I understand that remoting-process better now and I think it's something else than WinRM-Settings denying my access. – Optometer

for me it was ip address:port was the issue. I changed to hostname:port and it worked. thanks – Bonbon

Answer 2

Try doing this:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force

Cleavage

that doesn't work either. The value IS already set to "*". But there's some policy or setting that prevents clients from connecting over an ip. I need to change THAT setting, not the trusted hosts (I already knew about the trusted hosts setting) – Optometer

This command should be used on the source (workstation - remoting from) or the destination (virtual machine - remoting to)? – Skipjack

Answer 3

I test your assertion in my infrastructure the IP address is not the problem the following works for me :

PS C:\Users\JPB> hostname
JPBCOMPUTER
PS C:\Users\JPB> Enter-PSSession -ComputerName 192.168.183.100 -Credential $cred
[192.168.183.100]: PS C:\Users\jpb\Documents>
[192.168.183.100]: PS C:\Users\jpb\Documents> hostname
WM2008R2ENT

If you try to work accross a VPN you'd better have to have a look to the firewall settings on the way to your server. Installation and Configuration for Windows Remote Management can help you. The TCP port WinRM is waiting on are :

WinRM 1.1 and earlier: The default HTTP port is 80.

WinRM 2.0: The default HTTP port is 5985.

---

Edited : According to your error can you test this on youclient computer :

Set-Item WSMan:\localhost\Client\TrustedHosts *

Someplace

I can't connect via IP from the internal network too. I tried it from our DC and it works only if I use the targets hostname. I'll edit my error-message. – Optometer

Answer 4

The guys have given the simple solution, which will do be you should have a look at the help - it's good, looks like a lot in one go but it's actually quick to read:

get-help about_Remote_Troubleshooting | more

Late

You know, if you use "help about_remote_troubleshooting" you can skip the " | more" part :). – Mismate

Answer 5

On your machine* run 'Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$ipaddress"

*Machine from where you are running PSSession

Milamilady

Add -Concat if you need several IP addresses to be in trusted hosts – Stavro

Answer 6

On Windows 10 it is important to make sure the WinRM Service is running to invoke the command

Set-Item wsman:\localhost\Client\TrustedHosts -value '*' -Force

Drippy

Answer 7

For those of you who don't care about following arbitrary restriction imposed by Microsoft you can simply add a host file entry to the IP of the server your attempting to connect to rather then use that instead of the IP to bypass this restriction:

Enter-PSSession -Computername NameOfComputerIveAddedToMyHostFile -credentials $cred 

Rendarender

Answer 8

Please try the following on the client:

Run the following command to restore the listener configuration:

winrm invoke Restore winrm/Config

Run the following command to perform a default configuration of the Windows Remote Management service and its listener:

winrm quickconfig

After you configured winrm again, make sure host is trusted:

Set-Item wsman:\localhost\Client\TrustedHosts -value "$ipaddress" -Force 

Try remote connect again

Reference

Configure winrm for HTTPS

Meek

Answer 9

As Don touched on this, here is more info

Using the IP is Kerberos authentication problem

If you are on a AD Domain and need a more elegant solution than allowing NTLM and trusted hosts: https://learn.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip

" Beginning with Windows 10 version 1507 and Windows Server 2016, Kerberos clients can be configured to support IPv4 and IPv6 hostnames in SPNs.

By default Windows will not attempt Kerberos authentication for a host if the hostname is an IP address. It will fall back to other enabled authentication protocols like NTLM. "

Note that there might be GPOs limiting / disabling NTLM in the domain - since this can be a security risk To check run "RSOP". GPOs are under: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies/Security Options > Network Security

Allowing basic auth and allowing "*" in Trusted hosts makes me cringe a bit :)

GL HF

Mellman

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Anora

Answer 10

I spend a great amount of time and finally got the solution. Following are the steps to do fix this -

1. Go to Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings in control panel
2. Make sure machine discovery in domain and guest is ON.
3. Open powershell in administrator mode on client machine and run winrm quickconfig and winrm set winrm/config/client '@{TrustedHosts="*"}'

Randyranee