locked
ASP.NET delegation not working after a few days. If user logs off/on everything is fine.

    Question

  • Hi all,
    Here's the scenario:
    We have a web application that consumes a web service. This web service uses ADO.NET to connect to a SQL Server database on a different box.
    Both, web app and web service are on the same application server using Windows Server 2003 . We configured delegation on both servers and it works...for a while.

    If the end user hasn't logged off from the machine where the web browser is, in a few days, we see a logon failure on the sql server box.
    We check the logs on the web app and on the web service and up to that point the user credentials are okay, however the SQL Server box registers an anonymous logon and we get an exception on the web service layer.


    The curious thing is, if the end user logs off from his/her computer and logs back on, the delegation works again and the credentials are passed properly b/w the tiers...


    Any comments or ideas on where to start troubleshooting this are ore thanw welcome.


    Thanks!

    Liz
    Friday, October 3, 2008 9:23 PM

Answers

  • Actually the answer here was  a very easy one and also a documented one. On our Windows 2000 terminal servers, IE had been upgraded from 5 to 6 and by default IE 6 has the Security setting Enable Integrated Windows Authentication (requires restart)  checked off.

    http://support.microsoft.com/kb/299838

    We created a group policy for all the users using the terminal servers to propagate this setting and problem solved:

    http://technet.microsoft.com/en-us/library/cc779964.aspx


    The misleading part here was that we also had a similar case for users using Windows XP on their desktops, but on this case they had the IE setting correct and the issue was due to a kerberos.dll version problem.

    Web service fails to connect to make trusted connection to SQL Server after certain period



    In the case of the TS users,  they were unable to check their IE settings as they work on a locked down desktop they connect to remotely.

    It was an interesting process as we were able to check the Kerberos tickets  with Kerbtray.exe to make sure the tickets were there, we used Networt Monitoring, changed the Kerberos logging


    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q262177

    , changed Kerberos to use TCP instead of UDP to try to rule out UDP fragmentation

    http://support.microsoft.com/kb/244474

    but the answer was the simplest one.

    Liz
    • Marked as answer by Lizet Tuesday, November 11, 2008 4:15 PM
    Tuesday, November 11, 2008 4:15 PM

All replies

  • I'm not an expert on how cached credentials work, but it seems like they're expiring on the user's machine. Is it losing connectivity to the domain controller? Check in the event log on the users machines to see what the story is. You may see messages from Kerberos.


    John Saunders | Use File->New Project to create Web Service Projects
    Friday, October 3, 2008 9:26 PM
    Moderator
  • You are in double hop so SQL Server does not know the Asp.net runtime which is Network Serivice account in Win2003 must be added to SQL Server server on Domain level, in SQL Server on server level, and database level.  You must also know IIS6 comes locked down to render only static html so you need to apply all the relevant folder permissions.  I can answer most questions on this issue.


    http://support.microsoft.com/kb/812614

    http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/201da76e-197e-46dc-bad3-a0ea1a8639af






    Asp.net MVP, MCPD Web C#, MCITP BI & MCTS SQL Server 2005
    • Proposed as answer by John SaundersModerator Saturday, October 4, 2008 3:02 PM
    • Unproposed as answer by Lizet Monday, October 6, 2008 5:58 PM
    Saturday, October 4, 2008 2:54 PM
    Moderator
  • Hi John and Caddre,
    I appreciate your prompt replies.

    Caddre,
    I don't see why I should add the Network Service account from the web server to the sql server box, I use impersonation  with delegation on the web layer and the credentials that are passed to the SQL Server box are the user's credentials, not the Network Service credentials.
    I have logs on the web layer that indicate the user credentials are the ones passed to the sql server box under normal conditions.
    We have audited the connections to the server and we see the proper logins when delegation is working.


    When we have the error the credentials are shown on the web layer log but the SQL Server returns an authentication failure and it seems the credentials it gets on its end is the web server\anonymous one.

    I'll check the error log on the client machine and reply back right away.

    Thanks again!






    Liz
    Monday, October 6, 2008 5:17 PM
  • Hi again
    I checked this thread:
    http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/201da76e-197e-46dc-bad3-a0ea1a8639af

    The solution given by Caddre is to add the web server\Network Service as a login account in the SQL Server box and in the database.

    If I understand this correctly, this means that any process running under the Network Service would have access to the sql server box and the database, which is something we certainly don't want.

    The users that the web layer impersonates only have access to a stored procedure inside that database.

    If we grant permission to the Network Service then this account would be the one accessing the database whenever the delegation fails, is that correct? If so, we would lose the auditing at the database layer right there....


    If that is the only solution, then we are better off not using delegation in the first place...


    In my case we also have Mixed Authentication in SQL Server and both the SQL Server box and the IIS box are on the same domain.







    Liz
    Monday, October 6, 2008 5:40 PM
  •  

    (I don't see why I should add the Network Service account from the web server to the sql server box,)

    Asp.net in IIS6 Win2003 uses Network Service account SQL Server needs Asp.net permissions to run your application, you could create your own account and use it but Network Service comes with more limited permissions.  This is not relevant to IIS6 because the default everybody group is not allowed anonymous access in IIS6 with Windows authentication.


    (If I understand this correctly, this means that any process running under the Network Service would have access to the sql server box and the database, which is something we certainly don't want.)

    The only thing connecting SQL Server and Windows is Microsoft makes both SQL Server comes with DCL(data control language) Asp.net cannot impersonate your users without actual access to SQL Server.


    (If that is the only solution, then we are better off not using delegation in the first place...)

    Why delegation may not work.  Good luck.

    http://msdn.microsoft.com/en-us/magazine/cc163740.aspx


    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    Monday, October 6, 2008 6:10 PM
    Moderator
  • I wonder if I can reopen this thread now that I have more elements.

    This issue seems related to Kerberos and not to a problem in the way ASP.NET Delegation is configured.

    Let me make a short summary of the problem. We have a  double hop configuration (see http://blogs.msdn.com/nunos/archive/2004/03/12/88468.aspx) Our web server is configured for ASP.NET delegation (web server has IIS6 over MS Server 2003) and passes the credentials to our SQL Server 2005 box running Windows Server 2003 also.

    This configuration works like a charm when the user requests the page using their own desktop or laptop (most of them use Windows XP on their workstations). Only after a couple of days of not logging off, the user cannot see the requested page. This is not a concern for us now as the user can always log off and log back on on its desktop and see the page.

    This web page is served inside a client application that is consumed internally in the enterprise.

    Our main problem is with remote users that use the client application using terminal servers. Everything works fine if the terminal server has Windows Server 2003 but delegation fails if the Terminal Server has Windows Server 2000. Notice there can be several users connected at the same time on the same terminal server requesting the web page.

    We set up Kerberos logging on the Terminal Server running Windows Server 2000. After restarting the box (setting up this logging requires a restart) http://support.microsoft.com/default.aspx?scid=kb;en-us;Q262177
    the first user using the box was able to see the web page (delegation worked). The second and subsequent users were unable to see the web page (delegation didn't work)

    For these users that delegation didn't work, the system event log on the terminal server shows the following two Kerberos errors:

     Kerberos Error Message was received:
             on logon session LogonUser
     Client Time: Domain\Unsername1
     Server Time:
     Error Code: 14:49:1.0000 11/6/2008 (null) 0x34
     Extended Error: KRB_ERR_RESPONSE_TOO_BIG
     Client Realm:
     Client Name:
     Server Realm: Domain
     Server Name: krbtgt/Domain


    and


    A Kerberos Error Message was received:
             on logon session InitializeSecurityContext
     Client Time:
     Server Time:
     Error Code: 14:49:2.0000 11/6/2008 (null) 0x7
     Extended Error:  KDC_ERR_S_PRINCIPAL_UNKNOWN
     Client Realm:
     Client Name:
     Server Realm: domain.server.com
     Server Name: HOST/ControllerName


    If you could please point me to any documentation regarding this error or have come across this problem before that would be more than great.

    Thanks!!!




    Liz
    Thursday, November 6, 2008 7:04 PM
  • No you cannot open this thread again if you are in Win2000 because that is actually different and does not use constrain delegation.  I don't see how you can use Win2000 without pass through authentication, you need to talk to Microsoft consulting if you don't want to use what I have provided. 

    You may also want to contact your Terminal Services vendor because Asp.net and WebServices access to SQL Server are what I handle not access through Terminal Services which is Thin Client.

    (If you could please point me to any documentation regarding this error or have come across this problem before that would be more than great.)

    I am a developer so your error which is related to Win2k system error is not relevant to me, here is the information relevan to Asp.net from Microsoft relating to impersonation and Asp.net

    (However, on Windows 2000, if we want to directly Impersonate with
    LogonUser, we need to grant ASPNET with the SE_TCB_NAME user right. This is
    by design.)

    http://www.velocityreviews.com/forums/t76910-re-aspnet-impersonation-delegation.html

    http://support.microsoft.com/kb/810204


    Asp.net MVP, MCPD Web C#, MCITP BI & MCTS SQL Server 2005

    • Edited by CaddreModerator Thursday, November 6, 2008 9:38 PM Win2k Asp.net info
    Thursday, November 6, 2008 8:42 PM
    Moderator
  • The IIS is not on Windows 2000 box

    Please read below carefully:

    Web server box: IIS 6 on Windows 2003
    SQL Server box: SQL Server 2005 9.0.3228 on Windows Server 2003

    Web Clients on Windows XP with IE 6 are fine

    Web Clients on Terminal Servers running Windows 2000 and IE 6 are not fine.


    I hope this makes things clearer. I supposed I will have to ask on a Kerberos thread.

    I am really shocked by the way you have modeled both threads related to ASP.NET delegation, you are prompt to close the thread when you can no longer contribute.
    http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/201da76e-197e-46dc-bad3-a0ea1a8639af/



    Liz
    • Marked as answer by Lizet Friday, November 7, 2008 4:59 PM
    • Unmarked as answer by Lizet Friday, November 7, 2008 6:18 PM
    Friday, November 7, 2008 2:52 PM
  • (Web Clients on Terminal Servers running Windows 2000 and IE 6 are not fine.)

    Call Microsoft because your issue is again with thin client access, outside the scope of Asp.net and SQL Server.


    Asp.net MVP, MCPD Web C#, MCITP BI & MCTS SQL Server 2005
    • Marked as answer by Lizet Friday, November 7, 2008 6:18 PM
    • Unmarked as answer by Lizet Tuesday, November 11, 2008 4:01 PM
    Friday, November 7, 2008 3:11 PM
    Moderator
  • Yes, it is an issue with the thin client and it is outside of the ASP.NET or SQL Server configuration. We're calling MS Support. Thanks for the help, we narrowed down the cause thanks to this thread.
    Liz
    Friday, November 7, 2008 4:58 PM
  • Actually the answer here was  a very easy one and also a documented one. On our Windows 2000 terminal servers, IE had been upgraded from 5 to 6 and by default IE 6 has the Security setting Enable Integrated Windows Authentication (requires restart)  checked off.

    http://support.microsoft.com/kb/299838

    We created a group policy for all the users using the terminal servers to propagate this setting and problem solved:

    http://technet.microsoft.com/en-us/library/cc779964.aspx


    The misleading part here was that we also had a similar case for users using Windows XP on their desktops, but on this case they had the IE setting correct and the issue was due to a kerberos.dll version problem.

    Web service fails to connect to make trusted connection to SQL Server after certain period



    In the case of the TS users,  they were unable to check their IE settings as they work on a locked down desktop they connect to remotely.

    It was an interesting process as we were able to check the Kerberos tickets  with Kerbtray.exe to make sure the tickets were there, we used Networt Monitoring, changed the Kerberos logging


    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q262177

    , changed Kerberos to use TCP instead of UDP to try to rule out UDP fragmentation

    http://support.microsoft.com/kb/244474

    but the answer was the simplest one.

    Liz
    • Marked as answer by Lizet Tuesday, November 11, 2008 4:15 PM
    Tuesday, November 11, 2008 4:15 PM
  • Asp.net does not use IE in Authentication and Authorization it uses IIS so again your thin client created IE requirements are not in Scope with this forum.  How you resolve it is not relevant here because if you have a DBA you will not connect to SQL Server with UDP.

    It so happens that for fun I picked up MCSE a while back so NETLOGON is the article below is not relevant to both Asp.net and SQL Server because Microsoft require SQL Server and IIS running servers to be member servers so the profile object in the domain which is in NETLOGON is not relevant to both.  You need skilled Windows System Admin and SQL Server DBA.

    http://support.microsoft.com/kb/244474


    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA

    Tuesday, November 11, 2008 4:28 PM
    Moderator
  • Ahem, Kerberos was changed to use TCP on the domain and both the DBA and the system admin have all MS certifications up to date.
    Would you like to review the URL you posted?


    I think you should also review your *personal* checklist on what applies and what doesn't apply to this forum.
    This thread was a request regarding ASP.NET delegation not working on certain scenarios.

    The official Microsoft documentation for ASP.NET starts with the thin client settings. If IE does not have this setting checked on for that particular user, delegation won't work, period, despite of the fact that the user is properly authenticated on the IIS box.

    http://support.microsoft.com/kb/810572

    I was able to see the user credentials on the IIS box, however, if the client IE didn't have the security settings the SQL Server box received an Anonymous Logon.

    Please make a test, on a working ASP.NET delegation environment, go to a client machine and check off this IE setting...

    Adding the Network Service account from the web server to the sql server box is not the solution and it is a major security risk as you lose the original credentials.
    Liz
    Tuesday, November 11, 2008 5:19 PM
  • (I was able to see the user credentials on the IIS box, however, if the client IE didn't have the security settings the SQL Server box received an Anonymous Logon.)

    I covered that in reasons why delegation may not work.


    (Adding the Network Service account from the web server to the sql server box is not the solution and it is a major security risk as you lose the original credentials.)


    Actually that is not correct because if not manually enabled network service have very limited access one of the reasons you cannot use it to run service applications in a network.



    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    Tuesday, November 11, 2008 5:33 PM
    Moderator
  • The reasons you pointed on why delegation might not work was this article:
    http://msdn.microsoft.com/en-us/magazine/cc163740.aspx

    This article doesn't cover the client security setting on IE and it assumes the IE settings are there. Even with the setting mentioned in the article, if you have the Enabled Integrated Windows Authentication unchecked, delegation won't work.

    Regarding the network service account, if you create this login on the sql server box, your level of  risk depends on what permissions you set on the sql server for that particular login. My point is that you lose the auditing capabilities as all the events will happen under this login instead of the original user that initiated the request. You would have to correlate your web tier logs with your sql server box traces in order to determine who's doing what.


    Am I missing something regarding the Network Service account on the web server?

    Liz
    Tuesday, November 11, 2008 6:13 PM
  • (This article doesn't cover the client security setting on IE and it assumes the IE settings are there.)

    What part of IE setting not relevant to Asp.net and SQL Server you don't understand?  Kieth Brown is one of the best security experts in the Microsoft platform.


    (Regarding the network service account, if you create this login on the sql server box, your level of  risk depends on what permissions you set on the sql server for that particular login.)


    SQL Server uses ANSI SQL which comes with DCL(data control language) again talk to your skilled DBA

    (Am I missing something regarding the Network Service account on the web server)

    You said your system admin is skilled ask the person, I got my information in Win2003 upgrade class in MOC(Microsoft Official curriculum).  I still have the 11 megs here with me when I talk about delegation.


    You have internal issues related to thin client.




    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    Tuesday, November 11, 2008 6:29 PM
    Moderator
  • I'm off this discussion. I can't argue with a person that has all the answers yet can't argue in a logical manner, let alone insult the skills of my coworkers.



    Liz
    Tuesday, November 11, 2008 6:35 PM
  • (This article doesn't cover the client security setting on IE and it assumes the IE settings are there.)

    IE security settings are networking configuration related that is the reason system admins and DBA tell developers to exclude relevant IP addresses in IE.

    I  did not insult your co workers you said both are skilled but immediately asked the last two questions, the granular security setting you are asking your DBA needs to know DCL or your employer needs security admins working with the data team.  Your network also includes Windows 2000 servers and Windows 2003.


    (Regarding the network service account, if you create this login on the sql server box, your level of  risk depends on what permissions you set on the sql server for that particular login.)

    (Am I missing something regarding the Network Service account on the web server)

    The SQL Server anonymous user, Null user and other security context issues resolution depends on point of connection, direct SQL Server connection is resolved by Windows and SQL authentication.  While Asp.net context is resolved by IIS configurations.



    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    Tuesday, November 11, 2008 8:55 PM
    Moderator
  • I'm glad we can go back to the logical track and leave my coworkers at rest for now.
    I do consider Brown's article a very good one.

    Let me see if I understand you correctly. I realize this forum is for ASMX web services and XML Serialization so any thin client setting might look out of scope.

    However, the client that consumes the web service is the one passing the Windows Credentials to the web tier.

    When the client is a web form, if IE has the enabled integrated security checked off, Kerberos authentication is not attempted on the IIS box and the default protocol used is NTML, invalidating delegation of credentials to a second server (sql server box in my case).

    This issue can occur because Internet Explorer does not respond to a negotiate challenge sent by IIS and defaults to NTLM, or Windows NT Challenge/Response, authentication by default.

    When Internet Explorer attempts to access a protected resource, IIS sends two WWW-Authenticate headers, Negotiate and NTLM.

    • If Internet Explorer recognizes the Negotiate header, it will choose it because it is listed first. When using Negotiate, the browser will return information for both NTLM and Kerberos. At the server, IIS will use Kerberos if both the client (Internet Explorer 5.0 and later) and server (IIS 5.0 and later) are running Windows 2000 and later, and both are members of the same domain or trusted domains. Otherwise, the server will default to using NTLM.
    • If Internet Explorer does not understand Negotiate, it will use NTLM.



    Is there a way to make IIS use Kerberos and pass the Kerberos ticket to a second box even if the original request used NTLM?




    Liz
    Wednesday, November 12, 2008 2:07 AM
  • Never mind my previous post, Services For User to Self (S4U2S) in a Windows 2003 domain is the answer for my last question. Thanks for the help.
    Liz
    Wednesday, November 12, 2008 6:02 AM