I've just built a basic ASP MVC web site for deployment on our intranet. It expects users to be on the same domain as the IIS box and if you're not an authenticated Windows User, you should not get access.
I've just deployed this to IIS6 running on Server 2003 R2 SP2. The web app is configured with it's own pool with it's own pool user account. The IIS Directory Security options for the web app are set to "Windows Integrated Security" only and the web.config file has:
<authentication mode="Windows" />
From a Remote Desktop session on the IIS6 server itself, an IE7 browser window can successfully authenticate and navigate the web app if accessed via http://localhost/myapp.
However, also from the server, if accessed via the server's name (ie http://myserver/myapp) then IE7 presents a credentials dialog which after three attempts entering the correct credentials eventually returns "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials".
The same problem occurs when a workstation browses to the web app url (naturally using the server's name and not "localhost").
The IIS6 server is a member of the only domain we have and has no firewall enabled.
Is there something I have failed to configure correctly for this to work?
Thanks,
I have tried the suggestions from Matt Ryan, Graphain, and Mike Dimmick to date without success. I have just built a virtual machine test lab with a Server 2003 DC and a separate server 2003 IIS6 server and I am able to replicate the problem.
I am seeing an entry in the IIS6 server's System Event Log the first time I try to access the site via the non-localhost url (ie http://iis/myapp). FQDN urls fail too.
Source: Kerberos, Event ID: 4
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/iis.test.local. The target name used was HTTP/iis.test.local. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (TEST.LOCAL), and the client realm.
After extensive Googling I managed to find a solution on the following MSDN article:
How To: Create a Service Account for an ASP.NET 2.0 Application
Specifically the Additional Considerations section which describes "Creating Service Principal Names (SPNs) for Domain Accounts" using the setspn tool from the Windows Support Tools:
setspn -A HTTP/myserver MYDOMAIN\MyPoolUser
setspn -A HTTP/myserver.fqdn.com MYDOMAIN\MyPoolUser
This solved my problem on both my virtual test lab and my original problem server.
There is also an important note in the article that using Windows Authentication with custom pool users constrains the associated DNS name to be used by that pool only. That is, another pool with another identity would need to be associated with a different DNS name.
Sounds like the new Loopback check security feature of Windows Server 2003 SP1. As I understand it, is designed to prevent a particular type of interception attack.
From http://support.microsoft.com/kb/896861
SYMPTOMS
When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or IIS 6, you may receive an error message that resembles the following:
HTTP 401.1 - Unauthorized: Logon Failed
This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address.
Note You only receive this error message if you try to browse the Web site directly on the server. If you browse the Web site from a client computer, the Web site works as expected.
CAUSE
This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
Workaround
Method 1: Disable the loopback check
Method 2: Specify host names
See http://support.microsoft.com/kb/896861 for details.
Edit - just noticed that you said you were seeing this from Client PCs as well... that's more unusual. But I'd still look to test one of these workarounds, to see if it corrected the problem (and if so, might indicate a problem with your DNS config).
It sounds to me as though you've done everything right.
I'm sure you are but have you made sure you are using 'DOMAIN\user' as the user account and not just 'user'?
IE7 only sends Windows credentials (NTLM, Kerberos) if it identifies the server as being on the Intranet. IE7 also added an Intranet zone lockdown feature - if you're not on a domain, by default no servers are in the Intranet zone. This was done to prevent zone-migration attacks.
To change this, go to Tools/Internet Options, Security tab, then click Local Intranet. You can then manually add servers that should be treated as Intranet, by clicking the Sites button, then Advanced, or tell IE not to automatically detect your Intranet and selecting the other checkboxes as appropriate.
I just encountered the opposite problem - my site authenticates externally but not locally.
I compared it to the sites we have working and the difference was that the site that failed to authenticate was using Windows Authentication.
However, other sites I work with (this is a dev server) tend to have Basic Authentication.
Not sure why exactly but this fixed it.
However, at the same time I noticed "Default Domain" and "Realm" settings.
I know it's very unlikely but could these perhaps help at all?
Related
I wanted to implement a small Proof of Concept for ADFS integration with MVC application. For this I created a virtual machine for Windows 2008 R2 and configured ADDS, ADCS and added my updated my server domain to one created one using ADDS.
After this I created certificate using ADCS.
Now, installed ADFS 2.0 using Microsoft download of ADFSSetup.exe RTW.
With help of some I configured ADFS & added relying party trust from my MVC application SSL URI.
After this I tried to run the application however started facing 403.14 error page.
Following observations as outcome from entire configuration:
I tried to access "<>/federationmetadata/2007-06/federationmetadata.xml" and I
got a proper XML which is as per expected.
I saw couple of entries from server computer - IIS website as like "http://<>/adfs/services/trust" OR "https://<>/adfs/ls/" however couldn't get any response from server. even I tried to access same from server using localhost instead of server names, then also no luck.
Then to cross-verify I checked IIS's default website where I found adfs/ls however it was a like a website. Not sure correct or not. I couldn't find anything 'services/trust' under ADFS IIS application.
After that I installed ADFS from Server manager and saw one more virtual directory 'fs',added under adfs application. when I tried to access 'fs' using https I am able to access it easily and can see SOAP service and page displayed with available web method.
I tried to find more on 'adfs/ls' and 'adfs/services/trust' however couldn't get much more information.
Please, if anyone came across this issue. Do let me know.
This is not an issue, this is how ADFS works. Next step you have to configure claims providers and relying parties from ADFS management console (from Admin tools). Relying party could be a sample claims aware MVC application. It should work
The only URL's that ADFS "answers" to are the federation metadata endpoint and the IDPInitiated one.
adfs/ls expects either WS-Federation or SAML parameters after it. On its own it will throw an error.
Then follow How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF.
Why are you using Windows 2008 R2? (ADFS 2.0)? You should rather use Windows 2012 R2 (ADFS 3.0).
I am using a virtual server hosted anywhere (the virtual machine has Windows Server 2012 Datacenter R2 installed), but is not an domain controller. Now I installed Team Foundation Server 2015 RC (it's the release candidate but I think I will get similar problems with other versions) and the URL's are populated using the machine Name.
For example if my domain is abc.de, and my hostname is vmd12345, then the populated urls are something like this:
http://vmd12345:8080/tfs
Accessing repositories from visual studio is not a problem, but when I do some actions (for example view build logs), the web application tries to request vmd12345, what in fact is not accessible outside of the server. I tried to change the urls using the change url button in the TFS admin console, but if I do the system ask for a username and password and I do not know which user account is required.
Trying to change the URL's using the admin console failed cause the system has asked by to enter the credentials (I guess the credentials of the configured service user is ment), but the credentials did not work.
Further investigations shows that this is caused by an IIS problem of the webpage the TFS deploys into the IIS. If I connect at localhost, the credentials of the user were accepted, using the domain name the credentials was not accepted. Any Idea of what the problem can be?
You need to open the administration console on the TFS server and on the "Application Tier" node click "change URL". At the public up only...
We're switching our MVC3 application from IIS 6 to 7.5. I'm working on setting up my local development environment on Windows 7. The app works fine for the most part, but I just discovered that ONE out of the many different MVC Areas I have doesn't work.
When I try hit an action under this area, I get a 503 Service Unavailable error back. This does not happen anywhere else in my application.
There is only one application pool for the whole website.
MVC 3
.Net 4.0
64 bit
Failed request tracing doesn't see these requests.
There is nothing relevant in the Windows application or system logs.
The area works fine under visual studio 2010 cassini, problem happens when I run it under local iis 7.5 (not express)
App pool isn't crashing or otherwise stopped
There's nothing in my ELMAH log
Everyone full control on entire tree in the filesystem security
The url is http://localhost/reports
I'm totally stumped. I can't find any evidence that IIS is even getting the request at all. Is there some other log file beside the ones I listed?
[Update]
Is there any way to view the http.sys URL reservations? I have found some talk about SQL Reporting services calling dibs on /Reports url.
I figured it out. It was due to SQL Reporting services having reserved the http://+:80/Reports url in http.sys.
I didn't actually have reporting services installed, but it apparently still reserved the url.
I fixed it with the following command:
netsh http delete urlacl url=http://+:80/Reports
Check the account / IIS -> Application Pool -> Advanced Settings -> Process Model -> Identity under which your pool is running. I had my password changed, and didn't get a log on invalid password, but rather assemlby load failure, which in turn caused the app pool to be shut off, and the "503 Service Unavailable" was given to the user.
Another solution is, I had the same problem with my http://ApplicationURL/Reports
And yes the SSRS was the issue.
A better solution for this one is
OpenReporting Services Configuration Manager.
Connect to your local service usually COMPUTERNAME\MSSQLSERVER
Go to "Report Manager URL" Option
Modify your virtual directory with another name instead of Reports.
Just remember with this change you reports for SSRS will be in the name that you defined.
Carlos
Are you using any ODBC or other components in this area that you are not anywhere else? I have experienced this error (or one similar, can't remember off the top of my head) when running the app pool in 64bit mode and the underlying calls are referencing at 32bit 'something'. You could try enabling 32bit applications in the application pool settings to see if it affects the outcome.
As mentioned before it is related to SQL Reporting services
You can follow this approach to fix this problem:
Log on to the server that hosts SSRS.
Go to Start > Programs > SQL Server 2008 R2 > Configuration Tools > Reporting Services Configuration Manager
Connect to the server in question (usually your local server)
Go to the Web Service URL section
Change the TCP port to an open port other than port 80 (81 happened to work on my server) and hit Apply
Go to the Report Manager URL section
Click Advanced
Click the entry with a TCP port of 80 and then click the Edit button.
Change the TCP Port entry to the same thing you changed it to in the Web Service URL section previously and Click OK.
Click OK again.
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.
I'll start with appologies; I wasn't sure if this was best posted here of Server Fault so if its in the wrong place then please move :-)
Basic information
I have written the first module of a new application at work. This is written using Visual Studio 2010, targetting .net 3.5 (at the moment) and asp.net mvc 2. This has been working fine during development running on the built in Development server from VS but however does not work once deployed to IIS 7/7.5.
To deploy the application, I have built it in release mode and created a deployment package by right clicking on the project in the solution explorer (this will be done with an automated build in tfs once upgrade from the beta). This has then been imported into IIS on the server.
The application is using windows/domain authentication.
Issue #1
I can fire up internet explorer and browse to the application from a client computer as well as on a remote desktop connection. I can execute the code which reads/stores data in Session fine from the IE instance on the remote desktop but if I browse to it from the client pc it seems to lose the session state. I click on the form submit and the page refreshes and doesn't execute the required code. I've tried setting with; InProc, SQLServer and StateServer. but with no luck :-(
Issue #2
As part of the application it views PDF and Tiff documents on the fly which are on a network share on the office network and creates thumbnails if the document hasn't been viewed before. This works if running on the machine the application is deployed to; however when browsing from a client pc I get an error saying:
Access to the path '\\fileserver\folder\file.tif' is denied
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path '\\fileserver\folder\file.TIF' is denied.
ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6) that is used if the application is not impersonating. If the application is impersonating via , the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.
As this is on a different server the user is not accessible. To get round this I have tried:
1 - setting the application pool to run as domain administrator (I know this is a security risk, but I'm just trying to get it to work at the moment!)
2 - to set the log on account for World Wide Web Publishing service to be the domain admin . When trying to restart the service I get ...
Windows could not start the World Wide Web Publishing Service service on the Local Computer.
Error 1079: The account specified for this service is different from the account specified fro the other services running in the same process.
Any pointers/help would be much appriciated as I'm pulling my hair out (of what little I have left).
Update
I've been using this funky little tool I found -
DelegConfig v2 beta (Delegation / Kerberos Configuration Tool). This has been really usefull. So I've got the accessing of the file share working (there is a test page which will read the files) so now I've just got the issue of passing through the users credentials through to the SQL Server (wans't my choice to do it this way!!) to execute the queries etc. but I can't get it to log on as the user. It tries to access it as "NT Authority\Network Service" which doesn't have a sql login (as should be the logged on user).
My connection string is:
<add name="User" connectionString="Data Source=.;Integrated Security=True" providerName="System.Data.SqlClient" />
No initial catalog is specified as the system is over multiple dbs (also wasn't my choice!!).
I really appriciate all the help so far! :-)
Any further hints?!
Issue #2 - Your options are:
Configure delegation (double-hop authentication) - I haven't done this on IIS7 and it's a bit different to 6, but I believe you will need to enable the web server machine account for delegation in AD, and create an SPN for the web server (eg setspn -A http/<Web Server FQDN> <Domain>\<Machine Name>). Troubleshooting Kerberos can be fairly painful.
Grant access to the network resources to the (domain) application pool account and make sure anonymous authentication is turned on ( <anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" /> )
Response to Update:
You will need to make sure Kerberos authentication is working for SQL Server. Run the query select auth_scheme from sys.dm_exec_connections where session_id=##spid; it will return NTLM or KERBEROS. If it's NTLM, you'll need to do some work configuring SQL Server to use Kerberos. Set an SPN in AD for the SQL service account: setspn -A MSSQLSvc/<SQL Server FQDN>:1433 <Domain>\<Sql Service Account>, restart SQL Server and try the query again. You must use TCP/IP as the connection mechanism (this is the default).
If you don't have an initial catalog, you'll need to make sure that all of the user logins have a default database that they have access to. I would personally pick one database to be the initial catalog as you may get different behaviour depending on how the login is configured.
With this small part of information I could only give some hints:
Issue #1:
Maybe you have a misleading URL as action for the form? Or an caught&ignored exception? Do you have an onError-event in your global.asax.vb?
Sub Application_Error()
Dim ex As Exception = Server.GetLastError
' NOW HANDLE THE EXCEPTION --> REPORTING :-)
End Sub
Issue #2:
I recently had the same exception - I had to check the access-rights for users for this folder and set the appPool-identity to "NETWORKSERVICE". In your case you even try to access a network-folder - check the accessrights on the server and try to use the IP instead of the name - it could be a name-resolution-problem?!
Sorry for this small portion of information... This looks like problems only solveable with direct debug-options on the running server.
Finally last thing on Friday I got it working ...
As I said in the update, the tool for sorting out the delegation of credentials was very handy and helped no end to setting the correct SPN records.
I found I also had to set it up for SQL as I was passing through the credentials into the server. The other thing I found stopping the connections was some of the inbound windows firewall settings where causing problems.
For the connection string; I had to update to:
<add name="ConnectionStringName" connectionString="Data Source=.;Integrated Security=SSPI;Trusted_Connection=True" providerName="System.Data.SqlClient" />
Links I found useful:
Kerberos Authentication and SQL Server
DelegConfig
And even tho it mainly talks about Sharepoint ... this was also useful.
Hope this helps people in the future.