I am developing a PowerShell script that uses HTTP to access REST services. For debugging purposes I want to redirect all HTTP traffic created by that script through a local proxy (Fiddler).
What I don't want to is to set Fiddler as system wide proxy in IE/ Windows internet settings as this would redirect the traffic of my whole system through Fiddler (especially because Fiddler decrypts SSL/TLS traffic).
How do I set a proxy that affects only one WebClient instance or only the PowerShell?
Use the WebProxy class and instantiate it with the address to Fiddler (listens on port 8888 by default):
$FiddlerWP = New-Object System.Net.WebProxy "http://127.0.0.1:8888"
$WebClient = New-Object System.Net.WebClient
$WebClient.Proxy = $FiddlerWP
# This request will now get proxied through Fiddler
$WebClient.DownloadString("https://test.site.example")
Related
Sometimes, our clients requests firewall rules for their web servers connect to a certain URL but it turns out that the URL's IP address is dynamic, so we resort to using the proxy. One way that we use to test the proxy rules is to pull up the web servers' browser e.g. IE then set it up to use our proxy server then hit the URL on the browser. Our clients have a lot of web servers that we host so we would like to automate the testing part. Any ideas on doing it using PowerShell?
I'm not sure if it does what you want. But the is code which I found some days ago:
$secPasswd=ConvertTo-SecureString "password" -AsPlainText -Force
$myCreds=New-Object System.Management.Automation.PSCredential -ArgumentList "Domain\name",$secPasswd
$Site="http://www.google.com"
$Test=Invoke-WebRequest -URI $Site -Proxy 'http://ipadress:port' -ProxyCredential $mycreds
$Test.StatusDescription
Here's my scenario:
* I have a certificate installed on my server (Windows Server 2008 R2, with IIS 7.5)
* I create a new HTTPS binding via PowerShell command (New-WebBinding), but I have no way here to associate this to the certificate I have (for which I do have the Thumbprint)
Any ideas on how I can go about making this association. In the attached screenshot, this can be done in the GUI simply by editing the HTTPS binding and selecting it from the drop-down, though haven't seen a good example to do this via PowerShell or Command Line.
Use the Get-WebBinding cmdlet to retrieve the binding of your website and set the certificate using the AddSslCertificate method:
$httpsBinding = Get-WebBinding -Name "YourWebSiteName" -Protocol "https"
$httpsBinding.AddSslCertificate('SSL_HASH_STRING', "my")
I have a self-hosted owin web api service on a test environment, and to give it a better name I use a domain alias, and ARR.
My web api runs on port 8888, and uses Windows Authentication. I have configured my arr to run under testserver:80 with anonymous authentication. I want to deploy a service on the box that will pool the webapi for data. When I try to visit testserver from my web browser on my desktop it works fine. However, when I remote into that box and try to hit testserver it prompts me for credentials. Even if I type them correctly it still will issue me a 401. If I go to localhost:8888 the site will work.
Since, I'd prefer to use the pretty name for the server in my service how do I correct this issue. How do I get it to pass credentials on the same box through ARR?
You might have have an issue with LSA loopback checking.
You get the 401 because ARR forwards your Windows Authentication to localhost, which is not allowed (default setting).
Try to disable LSA loopback checking (restart most probably required). If that works you can limit the disabling of loopback checking to specific websites (to prevent security holes).
See You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version for more information on the LSA loopback check and how to disable it completely or only for specific hostnames.
I have a system in which I use Kerberos with simple delegation to have an AD user's credentials forwarded from a website to a downstream HTTP REST service using integrated Windows authentication. All servers are Windows Server 2012 R2.
This works great.
The issue comes when I started doing Powershell remoting to the same servers that my backend HTTP service runs on. Enter-PSSession makes a Kerberos auth request for the WSMan service on the target machine. AD sees this request, and encrypts the requested ticket with the identity that my custom HTTP service runs as, which the WSMan service obviously cannot use, and remoting fails.
I know it's possible to force IE to do port-specific SPN requests (via KB908209), but I have not been able to have the 2nd hop (i.e. the IIS-brokered request) to do a port-specific request. Nor have I been able to get powershell to make a port-specific request on 5985 for WSMan.
To make things more concrete:
Client browser makes a request to ServerA. Browser makes a Kerberos ticket request to AD for HTTP/ServerA, which is granted and then sent to ServerA.
ServerA wants to make a delegated request to http://ServerB:15200.
ServerA makes a request to AD for a Kerberos ticket for SPN HTTP/ServerB. It does not make a request for SPN HTTP/ServerB:15200. I want it to.
If I have my SPN set up as HTTP/ServerB:15200, simple delegation in IIS fails, but powershell remoting works. If I have my SPN set up as HTTP/ServerB, simple delegation works but powershell remoting fails. If I have my SPN set up as HTTP/ServerB:5985, nothing works.
I am totally stumped at this point -- doesn't seem like delegation and per-port SPNs play nicely together?
You can workaround this by setting up an alias for ServerB, give the HTTP/ServerBAlias SPN to the IIS account and HTTP/ServerB to the PS account, and then make ServerA send its requests to ServerBAlias. Or use the FQDN (e.g. ServerB.domain.local) in one SPN and the NETBIOS in the other (e.g. ServerB).
Or, you can look at how this person hosted WinRM in IIS with a custom account.
Do you have ms-DS-Allowed-to-Delegate-to attribute for HTTP/ServerA set to the list of HTTP/ServerB and HTTP/ServerB:15200?
Am I missing something here?
Does new-webserviceproxy not support proxy credentials?
Corporate environments invariably use proxy servers to talk to the rest of the web and I can't seem to get new-webserviceproxy to talk through ours. I get a 407 proxy authentication required error in return - the credentials argument is for credentials to the webservice not for the proxy.
Unfortunately, this cmdlet has no support for proxy credentials. You may want to try using the code posted here by Lee.
http://www.leeholmes.com/blog/2007/02/28/calling-a-webservice-from-powershell/
He uses NET.WebClient namespace and hence it is possible to add proxy credentials to the connect-WebService code.