locked
Server Error 401 - Unauthorized: Access is denied due to invalid credentials RRS feed

  • Question

  • User1665369602 posted

    This is my first, hopefully not last, web app - so, I expect I'll be posting a few more pleas for help before all is said and done.

    I have an app created in VisualStudio 2008 that accesses an SQL database on another server within our network.  The app worked fine when launched locally from VS2008.  Now, I'm trying to get it to actually run on a network server.  I've gotten numerous errors during trying to get this working, and seem to be going around in circles, so I'm posting the latest one with the expectation that there will be more to come.

    The error I'm getting at the moment is "Server Error 401 - Unauthorized: Access is denied due to invalid credentials."

    The app is on a Windows 2008 R2 server running IIS 7.5.  It is compiled (I used the Publish option in VS2008).  My domain account is a member of the Administrators group on the hosting PC, and the Administrators have full access to the application folder. 

    The app has its own AppPool, running under a custom domain account.  This domain account has also been given full access to the app folder.  The app has authentication enabled for ASP.NET Impersonation and Windows Authentication only.

    UPDATE:

    I couldn't help myself and continued to tinker.  Now I'm getting a login prompt for the server on which the app is hosted, and, when I cancel it, I get "HTTP Error 401. The requested resource requires user authentication."  What I had done was change the order of the providers for Window Authentication so that Negotiate comes before NTLM, which gave me the error "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'".  I changed the order back to NTLM followed by Negotiate, and got the HTTP Error 401.

    Monday, April 3, 2017 6:10 PM

Answers

  • User-718146471 posted

    As I understand AD Trust relationships, the SQL and the Web Server must have a two-way trust. I ran into this situation in one place I worked and that is what we ended up doing is SPN on both and created a two-way trust between them. It might work in your configuration but again I am not 100% sure; the only thing I can work for in this situation is experience and theory because I am not onsite with you (but you probably realize that LOL ). :)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, April 6, 2017 12:58 PM

All replies

  • User-718146471 posted

    If you are using any linked servers, that can happen if you haven't configured that server as a service protocol name (SPN). What I would recommend is create an AD group that you will place your users into and then give them access through the IIS and in the Windows Explorer group. You may not need to use the NT User configured for the App Pool Identity unless that specific user is accessing a SQL Server with AD credentials for example. I would recommend putting that back to the default and then the impersonate will do a pass-through as the user that is accessing the site. Let me know how that works for you.

    Monday, April 3, 2017 8:12 PM
  • User1168443798 posted

    >> Now I'm getting a login prompt for the server on which the app is hosted

    Did you mean you access the web app from your own computer? If so, will you get error if you enter your domain account and password?

    Will you get any error if you access the web application from Windows 2008 R2 Server?

    In my option, when you access the app which enables Windows Authentication on Windows 2008 R2 Server from external computer, you need to provide user name and password to bypass the login prompt.

    Tuesday, April 4, 2017 6:22 AM
  • User1665369602 posted

    There are no linked servers involved in the app.  I definitely plan on using an AD group to authorize my users, but, for now, I just want to get this working for myself, to verify that I can actually create a web app that uses Windows authentication all the way through to the backend database (i.e. I don't want users who are already authenticated on our network to have to deal with a login prompt for the app).

    You say that I may not need to use the NT User configured for the App Pool Identity, and recommend I put that back to the default.  By default, I assume you mean the "ApplicationPoolIdentity" identity.  I made that change, and stopped and started the application pool.  I am still getting the "Login failed for user NT AUTHORITY\ANONYMOUS LOGON" error mentioned in the latter portion of my post.

    To cloud the issue further, I tried logging on to the server on which I've published the app, and tried accessing it in the browser on that machine (e.g. http://localhost/AppName).  On that side, I get a lengthy error page (I assume because I specified debug="true" in my web.config). The error there is "HTTP Error 500.24 - Internal Server Error  An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode".  None of the suggested fixes on that page are appealing because I want the application to perform client impersonation for connection to the backend database, I've already configured validateIntegratedModeConfiguration="false", and I don't wish to use an application pool using Classic .NET mode.

    Tuesday, April 4, 2017 2:00 PM
  • User-718146471 posted

    One thing that you should be aware of is on the client browser, the user's browser needs to send the current user credentials if you don't want the prompt. That can be configured at the domain level as a Group Policy. to set it on your browser, follow these steps.

    To configure Internet Explorer for automatic logon (test with your machine first)


    1. Open the Internet Options dialog box by choosing Internet Options either from Control Panel or from the Tools menu in Internet Explorer.

    2. In the Internet Options dialog box, on the Security tab, select Local intranet, and then click Custom Level.

    3. In the Security Settings dialog box, under Logon, select Automatic logon only in Intranet zone, and then click OK.

    4. In the Internet Options dialog box on the Security Settings tab with Local intranet still selected, click Sites.

    5. In the Local intranet dialog box, click Advanced.

    6. In the next dialog box (also titled Local intranet), type the URL of your Communicator Web Access site (for example, https://cwaserver.contoso.com) in the Add this Web site to the zone box, and then click Add.

    7. In the Local intranet dialog, box click OK.

    8. In the original Local intranet dialog box, click OK.

    9. In the Internet Options dialog box, click OK.


    1. Open the Group Policy Management Console, and then either create a new Group Policy Object (GPO) or edit an existing GPO.

    2. Expand Computer Configuration, expand Policies, expand Administrative Templates, expand Windows Components, expand Internet Explorer, expand Internet Control Panel, and then click Security Page.

    3. In the details pane, double-click Site to Zone Assignment List.

    4. In the Site to Zone Assignment List Properties dialog box, click Enabled.

    5. In the Site to Zone Assignment List Properties dialog box, click Show.

    6. In the Show Contents dialog box, click Add.

    7. In the Add Item dialog box, type the URL of your Communicator Web Access site (for example, https://cwaserver.contoso.com) in the Enter the name of the item to be added box.

    8. Type 1 (indicating the local intranet zone) in the Enter the value of the item to be added box, and then click OK.

    9. In the Show Contents dialog box, click OK.

    10. In the Site to Zone Assignment List dialog box, click OK.

    11. In the Group Policy Management Editor, click Intranet Zone.

    12. In the details pane, double-click Logon options.

    13. In the Logon options Properties dialog box, click Enabled.

    14. In the Logon options list, click Automatic logon only in Intranet zone, and then click OK.

    15. Close the Group Policy Management Editor.

    Tuesday, April 4, 2017 4:57 PM
  • User753101303 posted

    Hi,

    This not just linked server. If you want to access to another server than the web server with the impersonate account you have to explicitely allow that (else by default you could just impersonate anyone on a company server to access to whatever you want using the user credentials).

    To clarify the current situation I would :
    - create a test page to see how the user is seen on the web server (IsAuthenticated, Identity.Name, AuthenticationType etc...) to make sure it works between the browser and the server
    - then from doing a test from the web server to SQL Server (for now I asume this is the step that fails): https://blogs.technet.microsoft.com/askds/2008/06/13/understanding-kerberos-double-hop/

    Of course make 100% sure you have no way around using the actual user identity to connect to SQL Server. If not don't use integrated security to connect for now to SQL Server (also make sure impersonation is needed ie if you have AD groups on the web site it will be still used (you could also use Authorize attributes) even if the user is not impersonated ie "who is connected to the site" and "Under which account the server side code runs" are two separate and independent concepts.

    Tuesday, April 4, 2017 5:29 PM
  • User1665369602 posted

    To bbcompent1:

    I checked the settings you noted in Internet Explorer.  Automatic logon only in Intranet zone was already selected (presumably set by our net admin's group policy).  On the Advanced tab of Sites, the Add function was disallowed (also, presumably, by group policy).  However, on the first Local intranet sites dialogue page, all 3 options under Automatically detect intranet network were checked, including Include all local (intranet) sites not listed in other zones.  Shouldn't that accomplish the same thing as specifying the URL on the Advanced settings window?

    On an unrelated issue, I'm kind of new to these ASP.NET forums.  Am I doing something wrong with my replies?  I kind of expected my reply to your post to follow beneath that post, so it would be apparent to whom and what I was replying.

    Wednesday, April 5, 2017 11:30 AM
  • User-718146471 posted

    No actually I sent you a private message so I could limit how many people saw my settings; security is always of utmost concern. Ok, so that rules out the problem with the browser which is good. We are narrowing down the source of the problem. I would recommend you check out the IIS Forums while I try to formulate the next thing to check in your server. You can view those forums as http://forums.iis.net  If you do find a solution, please reference it in this post along with what you did to fix the 401 logon error.

    Wednesday, April 5, 2017 4:51 PM
  • User-718146471 posted

    On a related post, I found this tidbit of info to narrow down which 401 code is being encountered.

    I would suggest you check the substatus code of the error which could help narrow down the issue:
    
    •401.1 - Logon failed. 
    •401.2 - Logon failed due to server configuration. 
    •401.3 - Unauthorized due to ACL on resource. 
    •401.4 - Authorization failed by filter. 
    •401.5 - Authorization failed by ISAPI/CGI application.
    
    The substatus code can be find in corresponding IIS log entries.
    

    From: https://forums.iis.net/p/1190877/2027343.aspx

    Wednesday, April 5, 2017 4:54 PM
  • User1665369602 posted

    One thing I need to clarify is that I'm not currently getting the 401 Server Error message that was in my original post heading, but the error I noted at the bottom of that post, "'NT AUTHORITY\ANONYMOUS LOGON".  That has been the case throughout our back and forth.  I apologize for any confusion.   Should I start a new post for that error?   Edit the post and change the subject and text?   I may have been getting the 401 error because of having NTLM as the first provider for Windows authentication in IIS, but I'm pretty sure that Negotiate should be first if I want Windows authentication to work from the browser to the web server and on to the database server.

    Wednesday, April 5, 2017 7:33 PM
  • User-718146471 posted

    You don't need to open a new post, we can continue using this one. Did you make sure that the server you are using is set up as a Service principle name in your active directory? If not, that can cause negotiation problems with Kerberos and NTLMv2.

    https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections

    Wednesday, April 5, 2017 8:11 PM
  • User1665369602 posted

    I have set up the service account for the app's Application Pool with an SPN for the HTTP service, as in:

    setspn -A HTTP/MyAppServer.MyDomain.com MyDomain.com\ServiceAccountForAppPool  and

    setspn -A HTTP/MyAppServer MyDomain.com\ServiceAccountForAppPool

    The SQL server runs under domain account MyDomain.com\MySQLServerAccount, for which the following SPNs are registered (shown as though creating them):

    setspn -A MSSQLSvc/MySQLServer MyDomain.com\MySQLServerAccount

    setspn -A MSSQLSvc/MySQLServer:1433 MyDomain.com\MySQLServerAccount

    setspn -A MSSQLSvc/MySQLServer.MyDomain.com MyDomain.com\MySQLServerAccount

    setspn -A MSSQLSvc/MySQLServer.MyDomain.com:1433 MyDomain.com\MySQLServerAccount

    I delegated trust for web application service account, MyDomain.com\ServiceAccountForAppPool, to the following :

    MSSQLSvc/MySQLServer

    MSSQLSvc/MySQLServer:1433

    MSSQLSvc/MySQLServer.MyDomain.com

    MSSQLSvc/MySQLServer.MyDomain.com:1433

    Are you saying that I also need to delegate trust for the above SQL SPNs to the machine on which my web application is running?

    Thursday, April 6, 2017 11:37 AM
  • User-718146471 posted

    As I understand AD Trust relationships, the SQL and the Web Server must have a two-way trust. I ran into this situation in one place I worked and that is what we ended up doing is SPN on both and created a two-way trust between them. It might work in your configuration but again I am not 100% sure; the only thing I can work for in this situation is experience and theory because I am not onsite with you (but you probably realize that LOL ). :)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, April 6, 2017 12:58 PM
  • User1665369602 posted

    I checked the delegation for the SQL service account.  It is set to "Trust this user for delegation to any service (Kerberos only)".  So, it should have delegation trust to HTTP/MyAppServer and HTTP/MyAppServer.MyDomain.com already (by the way, I know that's probably not the best delegation setting, but I'm not the network admin, so I'll just have to assume they knew what they were doing).  Anyway, wouldn't this mean that I have two-way trust between the application service account and the SQL server service account?

    Thursday, April 6, 2017 2:08 PM
  • User-718146471 posted

    As I recall and understand it, yes, but again you might want to hit up the network admin to see what he/she recommends.

    Thursday, April 6, 2017 2:37 PM
  • User-718146471 posted

    I knew I'd find the article again if I looked long enough, its called the Domain Double Hop Authentication Problem

    https://redmondmag.com/Articles/2010/08/23/Reporting-Services-Double-Hop-Authentication.aspx?Page=1

    Thursday, April 6, 2017 3:09 PM
  • User1665369602 posted

    Thanks for the link, but... Expletive-deleted!  What a sadistic web article.  Black font on grey?  I had to download it as text and read it in Notepad to avoid going blind!

    Anyways, it made it sound as though I needed to delegate trust not only to the service accounts under which the Web app and the SQL server run, but the machines they run on as well.  While that doesn't make sense to me, I did so.  However, it still doesn't work - though, the article said to stop and restart the services - if that's necessary, I'm going to have to wait until tonight to avoid interrupting user activity on the SQL server.  I'll let you know if it worked on or before Monday. 

    On a related note, in one of the posts I read while pursuing this topic, I came across a web app tool called DelegConfig2 that is supposed to provide some debugging\configuration checking related to Delegation. I downloaded and installed it in IIS, but when I ran it and clicked the "Report" link (which seems to be the initial step suggested), it would just display a page with the text "Please Wait", and this does not change after waiting an unreasonable amount of time, like 5 minutes.  Do you know of this tool, and if it's any good? I'll continue trying to get it working, but I thought it wouldn't hurt to ask you.

    Friday, April 7, 2017 3:44 PM
  • User-718146471 posted

    Yeah, copy/paste into word is what I had to do. Whoever did that obviously never heard of 508 compliance... As I said, this is one of those odd situations we developers run into rarely. Keep me posted; if I think of anything else, I'll respond to this post but lets leave it open until we get this fixed.

    Monday, April 10, 2017 1:49 PM
  • User1665369602 posted

    Wasn't able to reboot the SQL server over the weekend (forgot I had a long one scheduled).  It's kind of a sensitive machine at this stage (part of a new ERP roll-out), so I'm waiting to get the blessing of my IT Director before scheduling the reboot.  Will keep you informed.

    Tuesday, April 11, 2017 2:33 PM
  • User-718146471 posted

    That's fine Tim, I understand :) I'm patient so no worries.

    Tuesday, April 11, 2017 8:23 PM
  • User-718146471 posted

    Tim, I'm following up with you on this 401 unauthorized error. Have you made any headway yet?

    Thursday, May 4, 2017 4:37 PM
  • User1665369602 posted

    I've had to put this problem aside for the time being.  I was instructed to basically set up this application as open to anyone (it will only be accessed via our local intranet).  Also, since I had been using a (little used) production SQL hosting server as my test IIS server, I'd thought better of it and asked our network guy to set me up virtual machine I could test with - and, that got delayed due to a need for more RAM.  I still want to figure the cursed thing out, as I can see it being a significant benefit on future web apps; but, for now, it's having to wait.

    Thursday, May 4, 2017 5:36 PM
  • User-718146471 posted

    Ok Tim, that's fine. We'll just leave this posting where it is and continue when you are ready.

    Monday, May 8, 2017 8:24 PM
  • User753101303 posted

    Hi,

    IMHO it's better o as you told, to close the original issue and open a new thread. It's easier to deal with a single topic per thread.

    For now my understanding is:
    - check the sub status. the original issue is rather caused when you have a server side configuration issue (ie the account iunder which the app runs is not allowed to access to app files). As suggested already you should have a substatus code (check the IIS log) that should allow to better narrow down the exact issue. This one seems to be solved now.
    - then for the SQL issue, make sure first about what you want. Do you really need users to be connected to SQL Server using their actual identity? What will you with for that? If not it's perhaps doesn't worth to configure this and instead you could use SQL Server authentication or use the application pool identity. 

    Tuesday, May 9, 2017 7:18 AM