IIS Site Bindings - binding

I have a web website in IIS 6.1, with a Self-signed SSL. The website contains 3 web applications, all setup to use https as binding. Whenever I browse the application, the URL shows as
https://localhost/mysite1/default.aspx
I was under the impression that by adding a Site binding to use the computer name instead would change the URL to something like:
https://myservername/mysite1/default.aspx,
which means it will no longer complain about the SSL certificate being invalid when accessing the website, as the SSL is issued by "myservername"
I used the following command:
cscript.exe //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs set W3SVC/2/SecureBindings “:443:myservername”
My application identifier (2), which is shown under the "Sites" node.
After running the command, the URL is now directing to:
https://myservername.xn--9o0a/mysite1/default.aspx
That obviously doesn't work... it added .xn--9o0a to the URL??? What am I missing?

After doing some googling I managed to find this article that explains everything and how to fix the issue I was having.
http://gavinmckay.wordpress.com/2009/03/24/howto-fix-wcf-host-name-on-iis/

Related

URL Routes In IIS7 MVC 5 (Single Paged Application)

After publishing a MVC5 web application of mine to my IIS server (Individual User Accounts), it would seem that the URL is accessed incorrectly.
During debug, it would be e.g http://localhost:1234/api/Account/UserInfo?=XXXXX
The debug works just fine. The only issue kicks in after I've published it via my IIS7 server.
After publishing and using Google Chrome's console, it would appear that the page is requesting for a resource at mydomainname.com/api/Account/UserInfo?=XXXX instead of mydomainname.com/WEBAPPLICATIONNAME/api/Account/UserInfo?=XXXX.
My best guess is to modify the URLs in /Scripts/app/app.datamodel.js but it would just cause more parsing problems.
I've searched around and can't seem to find any related problems. I hope someone here will be able to lend a hand.
Look like you are using relative path like "/api/Account/UserInfo". Instead i'll recommend you to use #Url.Content("/api/Account/UserInfo"). This will solve your problem
Explanation
In local system when we run application in WebDev server it never have sub folder (like WEBAPPLICATIONNAME) therefore you relative path work correctly. but when you host your application in IIS under Default website in another new website /Virtual folder (like 'WEBAPPLICATIONNAME') then "/api/Account/UserInfo" fall back to Default Website because for '/' in starting. #Url.Content or #Url.Action make sure to add virtual directory name, hence changing your path to "/WEBAPPLICATIONNAME/api/Account/UserInfo" in IIS.

How do you force IIS Express to default to https URL?

I have enabled SSL in my MVC website for IIS Express by setting 'Enable SSL' in the project properties to true. So now I can access my site while debugging over http as well as https (IIS Express's default port 44300). However I'd like to force the default URL to be the SSL one. https://localhost:44300/. Whenever I run the app. from VS it always loads the http URL.
If I try and update the project URL (right click on the project -> click on properties -> navigate to the web tab -> set project URL to https://localhost:44300/) to https, the website fails to load. I just get a 'Page could not be loaded' error in the browser. However if I explicitly add a binding for https to port 44300 in my local IIS instance using IIS Management service it seems to work. I don't think I should have to touch local IIS in any way though.
Am I missing something here? Could someone help me figure this out?
The core of this seems to be finding the applicationhost.config file being passed to IIS, find the section like
<bindings>
<binding protocol="http" bindingInformation="*:62858:localhost" />
and change http to https
If you're using the Rider IDE, open the project properties (right click on solution explorer's icon for the project).
Make sure you add a port number for "SSL" and switch the Url from http://... to https://...
The port must be between 44300 and 44398, otherwise you'll get a connection reset error (see https://stackoverflow.com/a/24957146/423033 )
Sudeep,
If you are using the IIS on your machine (or on your server) you could create a rewrite rule that would intercept any http requests and will replace the http protocol with https.
Here is a link to get you started: http://www.iis.net/learn/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module
As for IIS Express, it has its advantages of using it, but on the other side it is missing advanced functionality like URL Rewrite (check this link: http://weblogs.asp.net/scottgu/introducing-iis-express).
Best Regards,
Daniel D.
Figured it out. This tutorial is perfect and walks you through the whole process
http://www.lansweeper.com/kb/54/How-to-configure-SSL-in-IIS-Express.html

MVC WebApplication no longer starts in IIS Express (redirects to https://localhost in Chrome)

I was changing OAuth/Owin settings and Azure publish settings in a Web Application project this morning, but soon after we decided deployment will be to a specific IIS Azure VM (now visible across our local domain). All code/setting changes have been reverted.
At one point I also changed the drivers\etc\hosts file to allow a dummy name for Microsoft OAuth, but that has been reverted.
Notes:
My startup URL is http://localhost:22222/
I am running under IIS Express (as my local Dev VM will not allow me to install full IIS)
When I start the Web Application with IE I simply get "This page can't be displayed"
If I start it with Chrome I get "This webpage is not available", but it also changes the browser URL to https://localhost (note the s, i.e. using SSL).
I have pulled the project down fresh from source control. No change.
The project is under TFS source control.
Another developer on the same project has the latest files and it works fine.
If I run any other Web Application project, they work just fine.
All OWIN registration of providers has been commented out. No change.
Deleted the entire project folder and pulled fresh from TFS. No change. This probably means a local machine setting somewhere is the cause?
What could I have damaged in my Web Application to cause this problem? I have been scratching my head for hours now and nothing we try is working. The application simply will not start in any browser.
Project Web Settings tab:
Answer at bottom, given to this chromium issue [issue 444479] helped me:
Same here - I also believe caused by HSTS - see
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
If you have (developed) any other localhost sites which send a HSTS
header...
eg. Strict-Transport-Security: max-age=31536000; includeSubDomains;
preload
...then depending on the value of max-age, future requests to
localhost will be required to be served over HTTPS.
To get around this, I did the following.
In the Chrome address bar type "chrome://net-internals/#hsts"
At the very bottom of a page is QUERY domain textbox - verify that localhost is known to the browser
If it is, DELETE the localhost domain using the textbox above
Your site should now work using plain old HTTP
HTH,
Jay
ps. This is not a permanent solution, but will at least get it working
between projects. If anyone knows how to permanently exclude localhost
from the HSTS list please let me know :)
Give it a try.

Unable to get windows authentication to work through local IIS

So I've created a new ASP.NET MVC project using the intranet template. web.config contains the appropriate values (e.g. <authentication mode="windows"/>).
If I fire up the web app using the VS webserver, it all looks fine - the page shows my Windows domain and username and all. However, this works in Opera and Safari as well as IE and FF, which says to me it's not using Windows auth at all (since to the best of my knowledge this doesn't work in any browser except IE/FF).
Next step is to get it working through local IIS. I create a hosts file entry pointing www.mysite.mydomain to 127.0.0.1. So in IIS I create website with a binding to www.mysite.mydomain and enable Windows authentication and disable anonymous authentication.
I have set up IE and FF to enable Windows auth as follows:
IE
Add URL to intranet group
Ensure Windows auth is enabled in the advanced settings
FF
Put 'www.mysite.mydomain' into network.automatic-ntlm-auth.trusted-uris config setting.
But when I dial up www.mysite.mydomain in IE / FF I get a login prompt. Interestingly, even when I type in my Windows login here, it still fails and shows me the login prompt again.
We don't have active directory here but my understanding is that it should work fine with a local account.
I can't think of anything else I need to do. Any suggestions?
Edit: we've recently switched to using Active Directory and the problem remains.
Edit: when I cancel the login prompt, I get taken to an 'IIS 7.5 Detailed Error' page with the following information:
HTTP Error 401.2 - Unauthorized
You are not authorized to view this page due to invalid authentication headers.**
You have to whitelist a domain specified in the hosts file in order for windows authentication to work:
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Right-click Parameters, click New, and then click DWORD (32-bit) Value.
Type DisableStrictNameChecking and press ENTER.
Double-click the DisableStrictNameChecking registry value and type 1 in the Value data box, click OK
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Quit Registry Editor, and then restart the IISAdmin service.
NOTE:
The original Microsoft KB links on this answer were broken and have been removed.
This article provided the instructions for setting DisableStrictNameChecking.
I recently spent three days trying to solve the same problem and it drove me crazy. It was happening on a load-balanced setup where one of the servers was authenticating correctly while the other failed. Investigating the problem - and eventually solving it - it turned out to be unrelated to the load-balanced environment, it could happen with any server when authenticating using Windows Authentication and the server is called with a name other than the one recognized by Active Directory
1. Enable Kerberos logging
To correctly diagnose your issue, you will need to enable Kerberos logging on the machine hosting your IIS site. To do so, add the following registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Add Registry Value LogLevel with ValueType REG_DWORD and value
0x1.
Once you turn on logging, then you try to authenticate, you will get errors logged in your Windows Application Log. You can ignore the error KDC_ERR_PREAUTH_REQUIRED (this is just part of the handshake) but if you get the error KDC_ERR_C_PRINCIPAL_UNKNOWN that means your AD controller doesn't recognize your server therefore you need to follow the steps below.
2. KDC_ERR_C_PRINCIPAL_UNKNOWN
if you're getting KDC_ERR_C_PRINCIPAL_UNKNOWN, that means the name "mysite.mydomain.com" is different from how the AD recognizes your machine so it's unable to provide a valid kerberos ticket. In that case, you need to register a Service Principal Name (SPN) for " 'www.mysite.mydomain" on the AD.
On your AD controller, run this command - you will need Domain Admin privilege:
Setspn -A HTTP/mysite.mydomain YOUR_MACHINE_HOSTNAME
3. Use a custom identity for your Application pool
Finally, make you Application pool use a custom account that belongs to the Active Directory instead of using NetworkService. This can be done in advanced settings of your application pool.
and .. voila.
Notes: The problem could (unlikely) be related to having multiple SPNs registered to the same machine, in that case you will need to run a command to remove duplicate SPNs, but I doubt this is the case. Also try adding a different binding to your site (that doesn't use a custom name) something like htttp://localhost:custom_port_number and see if authentication works. If it works, this is an extra indication that you're suffering from the same problem I had.
Did you try putting the domain in front of the user name?
DOMAIN\username
If you don't have a domain account, try prefixing your username with the machine name:
MYCOMPUTER\myusername
You should check to see if you have Windows Authentication installed/enabled. That may sound weird but in IIS 7 you have to install and enable the various authentication methods. Check out http://support.microsoft.com/kb/942043/ for more info, see quoted section below.
Cause 1
The Web application is configured to use Integrated Windows
authentication. However, the Windows Authentication feature is not
turned on. Or, the Integrated Windows authentication native module
section of the ApplicationHost.config file or of the Web.config file
is not valid. To resolve this problem, see Resolution 1.
Original
Usually when you try to view an asp.net web page hosted on IIS and receive a login prompt it doesn't mean your credentials weren't received or that you aren't authenticated. What it means is that the account that your website is running under doesn't have the right permissions to work with the files.
In IIS 6 and 7 you can easily change the user account that your app pool runs under. Try changing the app pool identity to an account with more access specifically designed for this. Or if you want to stick with the existing account (IUSR_? Network Service?) you can grant that account more permissions on the directory where your website is stored.
This article is specifically targeted at BizTalk but has almost no references to it and focuses on troubleshooting permissions issues with IIS and app pools: http://msdn.microsoft.com/en-us/library/aa954062.aspx
Why local IIS? Can you use local IIS Express?
If so, try this. It seems that IIS Express by default has Windows Authentication set to false.
Change
<windowsAuthentication enabled="false">
to "true" in applicationhost.config file (under 'C:\Users[Profile]\Documents\IISExpress\config' folder). This works for me.
To ensure that IIS uses Windows Authentication, I think you should try to turn of other authtentication methods. If Anonymous Authentication is enabled, Windows authentication will not work. You can also read this Microsoft Support Article which describes IE and IIS requirements in details.
I got this error when I enabled Windows authentication. I wanted to authorize the user based on Windows login and there is no login page in my application.
I got the error fixed by adding the below in my Web config file.
Under the tag system.web, I changed authentication mode="None" to
authentication mode="Forms".
Under the tag appSettings, I added add key="owin:AutomaticAppStartup" value="false"
After reading the answer of Espen Burud, I solved my problem by changing in the root's web.config:
<allow users="*" />
to
<deny users="?" />
The page that needs Windows Authentication is not in the root, but in a sub directory with its own web.config with deny users ? but that did not make Windows Authentication working. Apparently, you need to deny users in the root for that to work.
The IIS config has Anonymous Authentication enabled; that did not matter. After the above change of web.config, Windows Authentication worked.
For Dot Net Core 2.2 and running on IIS, I was having issues with 401.2 Unauthorized when I would check the Enable Windows Authentication within my application. It was a exceedingly simple test website that did basically nothing, just to try and get windows authentication to work. I finally got the auth to work, and here's what you'll need:
Within Startup ConfigureServices:
services.AddAuthentication(IISDefaults.AuthenticationScheme);
Open the application's Properties, click Debug option on the left and make sure you check Enable Windows Authentication.
But here's the kicker that I had forgotten... Configure your system to have Windows Authentication installed on IIS. This was never setup on my machine, and regardless what I did, I would always get a 401 unauthorized error. After installing this (Win 10, IIS v10.0.18362.1) I now get a login prompt. This isn't exactly what I need at this point, but at least it's not the unauthorized error. Good luck and hopefully this helps.

MVC.NET 404 outside of Domain

I am trying to get a demo site for a client setup. This is the 1st application my company is doing in MVC.NET, so I get to experience all the new things to find out (and all the headaches it'll cause).
Anyway, the site works fine locally (localhost) and on the server inside our domain. External users not on the domain however, only get 404 errors. I've tried several different settings/ config options I've found on this site, but nothing is working. I don't know if it's a web.config issue or an IIS issue, or even simply a permissions issue (though it has all the same permissions as the other sites we run with Web Forms).
IIS: v7 in intergrated mode.
Windows Server Web
Well, because you received a 404, the server is being reached okay which is a good sign. (Dealing with firewall issues at a company is always a lot of fun.)
A common problem for something like this is the use of virtual directories to host the website. For example, if the address to your site is http://example.com/MySite/, in MVC that would translate to: /MySite/View/Index.aspx. HOWEVER...if you are using virtual folders, /MySite/ may instead point to another spot on the server (e.g. C:\WebSites\MySite). If you are indeed using virtual paths, make sure you have your files stored at the correct path.
There is a troubleshooting tutorial here: http://support.microsoft.com/kb/248033
thanks for the answers everyone. Turns out it was something with our DNS routing setup with the sub-domains. It was getting rerouted to a place that didn't exist. Our IT guy finally got around to fixing it (ugh!)

Resources