My team and I have been attempting to publish our TFS http endpoint through a reverse proxy. TFS is authenticating using NTLM authentication, basic authentication is not encouraged: https://learn.microsoft.com/en-us/vsts/integrate/get-started/auth/tfs-basic-auth. Since NTLM is stateful going through a reverse proxy has challenges. Ignoring the long history of this issue, here is the current situation:
We're running TFS 2017 using NTLM authentication to the backend domain, TFS is hosted on Windows Server 2016. The reverse proxy server is in a DMZ network separating it from the TFS server via a firewall, but there is a firewall rule opening port TCP 8080 to the TFS server from the reverse proxy server and reverse proxy server is a member of the same backend domain as TFS. On the reverse proxy server, we're using IIS 7 with URL rewrite plugin as the reverse proxy technology on a Windows Server 2008 R2.
The TFS endpoint, altered here for the sake of discussion, is: http://backendserver.example.com:8080/tfs/. The reverse proxy site, again altered here, is http://reverseproxy.example.com:8081/. The rewrite rule is to filter on regular expression: tfs/(.*) and the rewrite url is http://backendserver.example.com:8080/{R.0}. All the other settings are largely unchanged.
So when we access the tfs endpoint directly (from the reverse proxy) it works fine, firewall is open so the regular url works fine (listed above). However when we try the reverse proxy endpoint (http://reverseproxy.example.com:8081/tfs/), we continually get reprompted for authentication with 401 errors. When we try running this same reverse proxy url but as a redirect (url rewrite -> Edit Inbound Rule -> Action -> Action Type -> Redirect) it properly redirects the homepage to TFS, authentication succeeds, and all other pages in TFS, when requested, properly load without additional authentication challenges.
Does anyone have any idea why these 401 errors are occurring? My account isn't being locked out after multiple failed attempts, so I have reason to believe that these failures are not coming from the backend domain itself. Thanks everyone.
Related
hopefully someone can help me.
This is the scenario I want to implement:
Server A has IIS installed and hosts a web app "mysite.com" and some web apis.
Server B has a .NET Core Web API hosted as a Windows Service.
When a client makes a request to a specific port like "mysite.com:9091/api/get-value"
I would like for IIS to re-route that call with same payload to server B on "myapi:9091/api/get-value" through HTTP.
The reason I want to do this is because We have authentication and certificates already configured on Server A, and also we want all incoming requests to go through the main site.
I have been reading on reverse proxy with IIS, and it would seem to be what I need, but it's not clear if the hosted app that will be running under Kestrel must be on the same physical machine as the IIS Web Server (i.e. Server A), or I can re-route to whichever other server I want, as long as it's on same network.
Any thoughts will be appreciated.
Hopefully my question is clear enough, otherwise please do let me know and I'll try to rephrase.
It is not necesarray to have both kestrel and iis on same server.
You could use the iis URL rewrite rule and reverse proxy to forward the request to the Kestrel server:
https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222
Host ASP.NET Core on Windows with IIS
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1
Almost have this working. Almost.
My set up is that I have an Azure B2C Tenant set up, and some modified example code that I've changed to reflect the Tenant information. This all works fine locally, with a localhost uri.
My remote set up is a Ubuntu 16.01 server, with a Nginx 1.10.0 webserver acting as a reverse proxy to a .NET Core 1.0.4 and all with a LetsEncrypt SSL cert.
The proxy serves .NET projects fine, however when I hit the sign in it takes me over to the B2C login with an incorrect redirect_url.
I'd expect the value to reflect what is in the settings file, "https.sub.host.suffix/signin-oidc" instead I'm getting "http.sub.host.suffix,sub.host.suffix/signin-oidc"
Any ideas or suggestions appreciated!
If NGINX is offloading SSL/TLS and then calling the .NET Core app, check as most probably is doing it through open HTTP (port 80).
You either need to ensure HTTPS all-the-way, or signal an HTTPS scheme to get triggered if HTTP endpoint was called.
As the .NET Core App gets a request through an HTTP endpoint, every URI created by it will keep that same scheme. So, you'll need to force https:// at link building time.
Hope it helps!
I have a web role which is configured for 2 endpoints, one http, one https 443:
Then I have 3 certs (one is the main and 2 are CA). I have uploaded all of these and also checked thumbprints are correct.
But when I deploy, the http site works fine but the https site does not. Fiddler shows:
Authentication failed because the remote party has closed the
transport stream
Any ideas?
Note: Also worth noting this https works fine when on local machine through Visual Studio and only reports the certificate error, which is expected.
First, open the portal and enable RDP to the instances, then connect to the role instance, open IIS, and verify the HTTPS binding is configured properly. Try accessing the site using https locally from the server and verify it works.
Report with the findings.
I am curious to understand how IIS 7.5 Reverse Proxy is implemented in Rewrite Module (v2).
I am planning to setup a website that will handle proxing between requests coming from users (internet) and my HTTP services that are deployed on the same server. I have setup a website within IIS and configured the reverse proxy logic. I've then setup another website on the same server and deployed all my WCF REST services there. I am planning to implement IIS offloading, common tasks (such as authentication, etc) on the reverse proxy website before the request gets to the actual services (like WCF routing service for SOAP). Configuration is working perfectly fine.
However I am trying to understand the implications of this setup. When IIS does reverse proxing, does it create a new HTTP request (and a new TCP port) between those two websites? And even if both sites are on the same server? Should I expect number of TCP connections opened on this server to get doubled when reverse proxy is used?
Furthermore, has anyone experienced any performance/resource issues with a similar setup?
Cheers,
OS
I have an application server installed, listening for HTTP traffic on a port which is not blocked from the world by a firewall. I wish to expose the services offered by this application only through HTTPS, preferably as a "sub directory" of the HTTPS site already hosted by the server.
Using IIS7 Url Rewriting (as part of the ARR package), I am able to setup a rule that redirects all traffic to a sub path of my existing HTTPS site. However, I am facing some trouble, when trying to make the same rule route to my server farm setup - all requests matching the rule simply get 404 reponses. Adding the very same rule to a non-SSL site, yields the expected behaviour - the application services are proxied right trough.
What might be wrong in my setup? Is ARR proxying the HTTPS requests as HTTPS traffic to the application server? The application I want to host does not have a HTTPS interfaces so, if yes: can I tell it not to do so?
Yes, I can use IIS7/ARR to route HTTPS requests to HTTP application.
The problem I experienced, was caused by the fact that the web site I wanted to use as the "container" for the proxy directory was buildt with ASP.NET MVC. The URL routing framework within ASP.NET interfered with the IIS url rewriting, and causes the 404 error.