We successfully installed PSWA on VMWorkstation with self-signed certificate. We wild-carded the authorization rules. We can access the PSWA page but cannot authenticate.
Scenario: Launch VM where PSWA is installed. Launch web browser on same VM and attempt to log in.
Result: [Error] “The PowerShell Web Access gateway cannot establish a connection to the destination computer, contact your system administrator.”
Q: Is Scenario 1 possible? OR is it only intended to server as a PSWA gateway and logging into itself is not allowed?
Scenario: Launch VM where PSWA is installed. Launch second VM in the same virtual environment. Launch web browser on second VM and attempt to authenticate into PSWA using CredSSP (configured on Client/Server for WSMAN service on both VM’s).
Result 1: [Error] The Windows PowerShell Web Access gateway cannot establish a connection to the destination computer. Contact the gateway administrator. The error at the gateway is: The WinRM client cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer. Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials. Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name “myserver.domain.com”, the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com.
Result 2 (without credSSP using all other authentication types): [Error] “The PowerShell Web Access gateway cannot establish a connection to the destination computer, contact your system administrator.”
Q: Why can we not authenticate using a known admin account on the destination computer?
So… perhaps a bit more detail would help. Some background:
The connection from the Web browser to the PWA server must be secured via HTTPS. If you’ve set up SSL using a self-signed certificate, this will only work if the Web browser is on the same machine as the PWA server, because only that machine will trust that certificate. Self-signed certificates are a Bad Idea for PWA.
When you hit PWA, you need to provide credentials that the machine you want to manage will accept. PWA will impersonate you, and then delegate your credentials to that machine. PWA needs to be able to make a connection - essentially, it’s running Enter-PSSession - meaning PWA needs to be in the same domain as the target machine.
It doesn’t matter if the PWA machine is also the target server.
So, perhaps describe what you’re doing in terms of:
Client (running browser)
PWA Server
Target Server (the machine you’re asking PWA to connect to)
And describe the relationship between these machines. CredSSP, by the way, has little to do with this, especially if you’ve not already configured it on the various machines. You also need to ensure that Remoting is enabled, and listening, on the Target Server.
One additional note that may be helpful to those testing in the same/similar environment: We configured both the server 2012 R2 (PSWA gateway) and the Windows 7 (Client) to use virtual network VMNet08. The PSWA gateway is a workgroup computer along with the Win7 client machine.
Happy PowerShelling!
PS - I believe the best spot for the gateway in the Enterprise architecture would be to have the PSWA gateway sitting inside a DMZ outside your corporate firewall. It could be even more secure accessing the gateway via VPN-ing into your corporate network and then access the PSWA gateway from there - it would be more cumbersome, yet more secure.