Is there any way to configure IIS 7 to transfer a request to another server in a similar way to how the Server.Transfer() method works in ASP.NET.
Judging by your comment under jsobo's answer:
I have two servers, first server was
installed windows server 2008 and can
access from internet and second server
was installed windows server 2003 but
cannot access from internet. Unlucky
my website can only run on the second
server so I want to transfer request
from the first server to second
server. Do you have any suggestion for
me?
I think the IIS Application Request Routing module may be the answer here:
Application Request Routing module on IIS.NET
You could install this on your internet facing Windows 2008 server and have it route requests to and from the Windows 2003 server.
Your best bet would be to actually do a response.redirect however if the request was a post and not a get then you have problems as the post data will be lost... your options are to proxy the request to the other server or to make a response to the client that writes an autoposting (via javascript) form. Both options are a bit of a hack.
The question I have is why you want to transfer the request to another actual server.
You don't want to do a transfer which silently redirects and then forgets, you want a proxy which handles the response as well.
Apache with mod_proxy can do this.
http://httpd.apache.org
A better choice though would be fixing the wacky setup. Why can't the app that needs to access the internet not be on a computer that can access the internet?!?
Related
I have a single Windows application (.NET) on serving as a server and communicating with the database. I also have client Windows applications (.NET) which communicate with the server application. Pretty standard so far.
As of now, I am using the IP address of the server, say "192.168.1.114", which I enter in my client software to establish the link. For instance, "http://192.168.1.114".
Now, I am trying to change that connection to HTTPS. Is there any way I can do that without actually changing the codebase? (I don't have the source code)
Any IIS certificate? Require SSL? Machine Key? Binding? Anything! I just want those packets to not be transmitted with regular HTTP.
Thank you so much, dear Community.
I have on-prem TFS within a small domain that we RDP into. Development machines are in this domain/enclave as well. Prior to the most recent TFS upgrade, we were able to connect Visual Studio to TFS and browse the TFS web UI using HTTP only within the enclave. We could also use HTTPS from outside the enclave (no http) to access the web UI. With the latest upgrade, I have mirrored the IIS authentication, SSL and binding configurations but now pointing a browser or Visual Studio at the HTTP only address always redirects to the HTTPS address and forces the SSL login. This is a problem for us because we use a large enterprise PKI infrastructure (access cards, non-local services, etc) that is very flaky: constantly dropping the Visual Studio connection to TFS and asking for PIN re-entry every 2 - 3 minutes. How can I stop the http address from re-directing to https all the time in our enclave? Is TFS doing this now? or IIS?
Since TFS2017 server changed the Authentication from NTLM to KERBEROS by default. You could use the following command to use NTLM back:
TFSConfig Authentication /provider:NTLM
And please try to create a new DNS, then check the result again.
If you want to remove Https, you should change the "Public URL" to http in TFS administration console, removed the HTTPS bindings from IIS.
If above is not work, try to uninstall and re-install the Application Tire and choose the http only option.
For more details take a look at this similar question: TFS 2018 - remove HTTPS
Got it. Found this article describing the redirect behavior from the URL. Long story short-> In IIS, select the TFS under Sites, then Application Settings, setting name sslOnly was set to true. Changed to false. Now I can access the TFS portal from inside the enclave using http OR https and from outside using https only. This means that VS can also connect to TFS via http only.
I installed an ASP.net application on a windows Azure VM (IIS 7). SSL certificate is installed, configured and the application works correctly. I have removed Http binding and http endpoints.
The issue I am having is that if I use the cloudapp.net link (using https), the application still opens with a mismatched certificate.
What can I do to deny any user from opening my application using https://xx.cloudapp.net/x?
It seems really silly that people are saying this isn't the right place for this question, since some of the solutions could be code related. ie: In your application, check the host and if it's cloudapp.net, do a URL redirect.
There's a few different options here but it sounds like what you're looking for is just the ability to prevent someone from viewing the application using that URL.
What I would do is set up a site in IIS that uses Host Header resolution to look for xx.cloudapp.net. If that URL is recognized, do a redirect using the HTTP redirect settings to the https version of your app. Don't bind the SSL port to this site or you'll run into SSL errors like you showed above.
The other option is to leave it out entirely and simply use the Host Header resolution to filter out requests for your site. I suspect what you've done is assign all incoming requests to the only IP address on the system, which is why the xx.cloudapp.net is showing your app and the cert is failing.
This would cause xx.cloudapp.net to fail to show any site at all but I think that might be what you want to do anyway.
I just got IIS7 set up on a Windows Server 2008 R2 machine in VirtualBox. After doing so, I could not connect from any other client, though http://localhost worked. For that matter, I was unable to even ping the server.
After doing some research, I found that enabling File and Print Sharing on the server solved the problem, but surely there has to be a better way, and I would much prefer to learn to use the best method, rather than the easiest one.
What, specifically, should I do to enable both pinging of the server as well as access to the web server running on it?
Isn't it that the inbound web HTTP port is blocked by default? I'm not a server guru but can remember going to the firewall to allow it through. Should already be there.
Out of the box on Windows Server 2008/2008R2 firewall is installed and users cannot access resources or services on the server unless you configure exceptions to the firewall. There is one exception to this are services/resources on this server that you make available through the GUI tools (Initial Configuration Tasks Wizard, Server manager) - these automatically create firewall required exceptions for you.
So in your case either upon File and Print Sharing installation or upon using File and Print Sharing config wizard/Shared resource provision wizard (most likely the later) required firewall exception was created for you. The rule in question is: File and Printer Sharing (Echo Request – ICMPv4-In) - actually allows ping, but I guess Windows also uses it for network resources discovery and other things implied by the role you installed.
Nothing prevents you from not enabling File and Print Sharing and just enabling mentioned firewall exception manually.
If I have a website at myFirstDomain.com/dir/, is it possible to get mySecondDomain.com to point to myFirstDomain.com/dir/ so that when users browse at the directed site, they only see mySecondDomain.com/potentialSubDirFromMyFirstDomain/ or how does it work?
Ok good.
Well what you'll need to do is make use of IIS 6.0 Host Header Filter.
Essentially in IIS you will have your default web site which is currently serving myFirstDomain.com.
With Host Headers, we can add another web site which is mapped to the location of your subdirectory and will only be visible if the user enters via 'mySecondDomain.com'.
So in a nutshell we are getting IIS to host multiple sites on one box. I'm not too familiar with the process in IIS 6.0 since all I use is IIS 7.0 which is not available on Windows Server 2003.
However, the following links should help you implement it in IIS 6.0:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/b77cf015-017f-489c-9b5b-65ca4a679392.mspx?mfr=true
http://forums.iis.net/t/1120787.aspx
http://www.goarticles.com/cgi-bin/showa.cgi?C=188629
The idea is that when a user types 'mySecondDomain.com' it will add this 'host header' into the body of the HTTP request from the browser to IIS, IIS will then read this value and check to see if any of the website(s) contain a match for the host header and redirect the user to the appropriate website, thus mySecondDomain.com will appear as though its on its own server (which it technically is anyway.)
From what I remember the host header attribute only exists in the HTTP 1.1 protocol, HTTP 1.0 does not support it and will not send the host header to IIS which means the default web site will be displayed instead...(regardless of what domain you come in from). I'm pretty sure most browsers are using HTTP 1.1 though.
A safer way would be to bind each web site via IP address... but for this you will need multiple internet ip addresses on one box - I've never had a problem with host headers though!
Firstly, I think your going to need direct access to the web server... are you using a VPS/Dedicated Server or Shared Hosting?
Windows Server, Linux?
It is not possible at all with the DNS. You will have to set up a HTTP redirection (no experience with IIS so I cannot help here, just suggest you to drop the "dns" tag).