Resizing my Azure VM changed my IP and now WinRm wont work

Resizing my Azure VM changed my IP and now WinRm wont work - powershell

I have a VM that i am manipulating using an azure devops pipeline. Previously, using WinRM to transfer files to the VM worked fine. However the vm's ram was not suitable for our needs, so i re-sized the VM to add more ram. Since resizing the VM, the VM's ip address has changed. This has caused WinRM to stop working. I tried to use winrm quickconfig -force in the console, and get this error:
Unable to enable the firewall for WinRM.
I removed the HTTPS listener from 5986 who's host was the old IP address, however i cannot add a new listener that points at the correct IP.
Start-RemotePSSession does not fail, or if it does, then it does so silently
I have looked at the certs and only can see one for the old ip address:
How can i add a cert for my new ip address? Or is there a different/better way to accomplish what i am trying to do (get winrm working again)

Since you have an old cert issued to the old Public IP address, you can generate a new cert issued to the new public IP address.
For example,
1.
Go to the VM console and generate a self-signed cert for a test.
$certificateName = "51.x.x.x"
$thumbprint = (New-SelfSignedCertificate -DnsName $certificateName -CertStoreLocation Cert:\LocalMachine\My -KeySpec KeyExchange).Thumbprint
Delete the old https listener and bind a new cert for the https listener.
winrm delete winrm/config/listener?Address=*+Transport=HTTPS
$thumbprint="7AD714C2AA0EF690EEFxxxxxxD"
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $thumbprint –Force
Enumerate the listeners.
winrm e winrm/config/listener
Note: the winrm quickconfig does not work for self-signed certs based on my validation. You could follow the above steps to manage it. If you have not allowed port 5986 in the windows firewall inside the Azure VM, you can enable it with PowerShell. If there is a network security group in your Azure VM subnet or associated NIC, you also need to enable it for HTTPS port. Read this blog for more details.
New-NetFirewallRule -DisplayName "winrmhttps" -Direction Inbound -LocalPort 5986 -Protocol TCP -Action Allow -RemoteAddress Any

Related

WinRM error while connecting to remote server using powershell [duplicate]

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.

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.

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

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 *

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

On your machine* run 'Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$ipaddress"
*Machine from where you are running PSSession

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 *

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

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

I spend a great amount of time and finally got the solution. Following are the steps to do fix this -
Go to Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings in control panel
Make sure machine discovery in domain and guest is ON.
Open powershell in administrator mode on client machine and run winrm quickconfig and winrm set winrm/config/client '#{TrustedHosts="*"}'

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

WinRM listening on incorrect IP

I have a server where I have configured WinRM using the IP address and HTTPS using the command below.
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address "IP:x.y.z.10" -CertificateThumbPrint "<ThumbPrint>" –Force
The listener shows OK using the WinRM command.
winrm e winrm/config/listener
Listener
Address = IP:x.y.z.10
Transport = HTTPS
Port = 5986
Hostname = ServerA
Enabled = true
URLPrefix = wsman
CertificateThumbprint = <ThumbPrint>
ListeningOn = x.y.z.10
Pinging ServerA resolves to x.y.z.10
This server has two IPs x.y.z.10 (primary) and x.y.z.11 (secondary for a website).
When I check the IP and ports listening using tools like Currports, telnet, or PortQuery, I see that WinRM is listening on x.y.z.11.
I have tried all the following tricks to no avail.
Removed and/or re-installed IIS and default site etc.
Updated WinrRM to the latest (it is a Windows 2008 R2 server)
Removed the .11 IP from the server (after this it listened on
127.0.0.1).
Made sure that default website has id of 1
Tried registering an http-only listener (it still listens on .11 even
though IP used in the new-item command is .10).
Removed expired certs
Made sure that "Skip as Source" is set to false for .10 and true for
.11
Based on my research so far, it seems that somehow WinRM is not seeing the server default IP of .10.
Any suggestion where should I look next?
I have configured about 50 other servers successfully using the same config, but there is something unique about the default IP on this server that I can't wrap my head around.
Thanks for any help!

Setting existing SSL certificate on an IIS website which uses hostheader

The idea is to automate linking an SSL certificate to a website in IIS 7 or above.
All the websites in a server use same IP address and same default port. So they are all differentiated by their host header names.
I could achieve this manually without any issue. But while automating there is issue.
When done manually, the ssl configuation entries in http.sys are recorded as HostNameport TestName:443, not as ipport xx.yy.z.a:443.
So I wanted to mimic the same manual steps for automation to work. But it is not helping.
I tried below steps.
Create a new ssl configuration in http.sys for hostname port combination with below command.
netsh --% http add sslcert hostnameport=Testssl:443 certhash=d70930bb790f89c04c728d9285b64f5fb0258fc7 appid={01010101-0101-0101-0101-010101010101} certstorename=MY
Create a new web binding for the website using hostheader name.
New-ItemProperty IIS:\sites\TestSite -name bindings -value #{protocol="https";bindingInformation="192.168.1.108:443:Testssl"}
or
New-WebBinding -Name TestSite -Protocol https -Port 443 -HostHeader Testssl -IPAddress 192.168.1.108
With the above two steps the new binding is present, but the SSL certificate is not attached to the binding.
Is it not possible to set SSL certificate for a binding with a corresponding hostname port entry in http.sys ssl configuration?

With the help of comment from Lex Li, the below command WORKS.
New-WebBinding -Name TestSite -Protocol https -Port 443 -HostHeader Testssl -IPAddress 192.168.1.108 -SslFlags 1

Azure Powershell Runbook - Invoke commands on remote VM (ARM a.k.a. V2)

What I need
I want to have an automation runbook that executes commands on a remote VM (the VM is a V2 or "Resource Manager" VM).
I found examples to make that work with Classic VMs but I can't make it work for RM VMs (best I found: https://alexandrebrisebois.wordpress.com/2015/08/14/azure-automation-remote-powershell-and-a-virtual-machine/).
Does anybody have an example of running powershell commands on a remote V2 VM in an automation runbook?
Where I'm stuck currently
I have tried to adjust the 2nd piece of the example code (the part that invokes the command) and I get the following error:
[vm-template] Connecting to remote server vm-template failed with the following error
message : 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. Use winrm.cmd to configure TrustedHosts. Note that computers in the
TrustedHosts list might not be authenticated. You can get more information about that by
running the following command: winrm help config. For more information, see the
about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (vm-template:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : ServerNotTrusted,PSSessionStateBroken
My understanding is that since I am not using Kerberos (don't even know what that is) I must use HTTPS. And for that I must do the first half of the example code, which is about importing the certificate (importing where btw since the runbook runs "in azure"?).
I found some pages that explain how to enable HTTPS (Connecting to remote server failed using WinRM from PowerShell) and create the certificate (http://www.jayway.com/2011/11/21/winrm-w-self-signed-certificate-in-4-steps/) but they require some commands to be run on BOTH machines ; I certainly can run commands on my remote VM but I don't understand how I could do it for the client machine which does not really exist since the runbook is running directly in azure.
Any help is greatly appreciated, thanks!

Is your network security group configured to open port 5985 (winrm http port) or 5986 if using https? You also might need a public IP, if you plan on using winrm not from Azure automation. You should also be able to use http, so I think the error you're seeing is a generic failure to connect error.
Note: by default, winrm over http and the listener should be set up and listening on your machines. winrm uses message level encryption, so it's not completely in plaintext. You can verify with:
winrm e winrm/config/listener
Which should show you the listener with something like:
Listener [Source="GPO"]
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 1.1.1.1
Once you've verified that, I would verify that you can connect to the remote machine using winrm from your own computer. You can easily do that with:
$username = '<admin-user>'
$pass = ConvertTo-SecureString -string '<password>' -AsPlainText -Force
$cred = New-Object -typename System.Management.Automation.PSCredential -argumentlist $username, $pass
Enter-PSSession -ComputerName <public-IP> -Credential $cred -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck)
Note that you may have to set your trusted hosts on your own computer to trust the Azure machine to create the winrm session. This can be done with something like:
Set-Item WSMan:localhost\Client\TrustedHosts -value * -Force
Note that you should use the Azure VM's actual name for security, not a wildcard.

Powershell remoting with ip-address as target

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

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 *

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

On your machine* run 'Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$ipaddress"
*Machine from where you are running PSSession

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 *

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

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

I spend a great amount of time and finally got the solution. Following are the steps to do fix this -
Go to Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings in control panel
Make sure machine discovery in domain and guest is ON.
Open powershell in administrator mode on client machine and run winrm quickconfig and winrm set winrm/config/client '#{TrustedHosts="*"}'

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

We Keep Coding

iphone swift flutter scala powershell matlab mongodb postgresql perl eclipse