none
IIS and Windows Authentication

    Question

  • We have a Web Server (ServerA1) that is setup for Windows Authentication and all the site does is accept form entries and write them to a File Server (ServerA2).  Both servers are members of Domain A.  When users from Domain A connect to the site, they can write the files from the form.  We have a one-way trust from Domain B.  When a user from Domain B connects to the web server and tries to write the file from the form, they are not successful.  I check the security log on the ServerA2 and notice that the user is coming in as Anonymous Logon.  How can I configure so that it uses the user credentials from Domain B?

    TIA

    Monday, June 24, 2013 6:20 PM

Answers

  • The more I think about this the more Domain B failing makes sense, but equally I wonder how Domain A is working.

    So users in Domain B connect to the website on ServerA1, and they authenticate using their AD credentials which works fine. They do their thing on the website, and the website then saves the form to ServerA2. Currently the logs on ServerA2 show that the connections made to it are anonymous rather than authenticated.

    Now in a default setup I could understand that, since ServerA1 is going to be connecting to ServerA2 in the context of IIS, not the user that authenticated to it. My thinking at the moment is that you need to use ASP.NET Impersonation Authentication http://technet.microsoft.com/en-us/library/cc730708(v=ws.10).aspx which would then execute the website code in the context of the user connecting from Domain B, and connect to ServerA2 using that same security context.

    What confuses me though is if that's correct, why would users in Domain A be working correctly? Surely they should also be having their requests sent to ServerA2 using IIS's context rather than their own!

    Another possibility (after having a search around... so keep in mind some of this is new to me as well!) could be the issue is connected in some way to "double hops". The topic which sounds similar to your situation but with SQL rather than a file server was raised here http://stackoverflow.com/questions/8249367/asp-net-impersonation-make-windows-identity-flow-across-to-sql-server and perhaps the most pertinent links from there are http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx and http://blogs.technet.com/b/taraj/archive/2009/01/29/checklist-for-double-hop-issues-iis-and-sql-server.aspx which go into how to get around it. If that's what's causing your problem then it sounds like perhaps the relevant Domain A users already (or automatically) have the required delegation permissions, while the Domain B ones don't, which would explain why you're seeing different results depending on the domain the user is coming from.

    Hope some of that helps. I'd definitely be interested to know if any of those fix it and what ended up being the fix!

    Wednesday, June 26, 2013 8:33 PM

All replies

  • Within Internet Explorer for all users in Domain B make sure the users have the website address listed in their Local Intranet security zone (found in Internet Options, Security), otherwise it won't be treated as local and IT won't pass their local credentials to the server.

    You could also check in Internet Options, Advanced, and ensure "Enable Integrated Windows Authentication" is enabled, since that's also required for IE to pass the credentials but it probably already enabled.

    Monday, June 24, 2013 9:15 PM
  • To clarify, the users from the trusted domain (Domain B) are logging on computers that belong to Domain A.  I have looked at the security logs on ServerA2 and see ANONYMOUS LOGON connections, so the credentials of those users are not being passed on by IIS.

    Wednesday, June 26, 2013 11:28 AM
  • If you check the logs on ServerA1 does that show the connections being made with their login credentials or as anonymous connections?

    Also, which version of Windows Server / ISS are you using? In the website's properties in IIS on ServerA1 what security options do you have selected currently?

    Wednesday, June 26, 2013 3:47 PM
  • We're using Windows Server 2008 R2 and IIS 7.5.  Under Authentication, we have Windows Authentication and ASP .NET Impersonation Enabled.  In the event logs for the Web Server (ServerA1), I see the the user from the trusted domain (DOMAIN B\USER), but the Authentication Package is NTLM.  I think to get this to work, the Authentication Pacakage needs to be Kerberos (when users from Domain A logon I see Kerberos).

    Any ideas as to what I might need to do to get it to use Kerberos instead of NTLM?

    TIA

    Wednesday, June 26, 2013 6:55 PM
  • The more I think about this the more Domain B failing makes sense, but equally I wonder how Domain A is working.

    So users in Domain B connect to the website on ServerA1, and they authenticate using their AD credentials which works fine. They do their thing on the website, and the website then saves the form to ServerA2. Currently the logs on ServerA2 show that the connections made to it are anonymous rather than authenticated.

    Now in a default setup I could understand that, since ServerA1 is going to be connecting to ServerA2 in the context of IIS, not the user that authenticated to it. My thinking at the moment is that you need to use ASP.NET Impersonation Authentication http://technet.microsoft.com/en-us/library/cc730708(v=ws.10).aspx which would then execute the website code in the context of the user connecting from Domain B, and connect to ServerA2 using that same security context.

    What confuses me though is if that's correct, why would users in Domain A be working correctly? Surely they should also be having their requests sent to ServerA2 using IIS's context rather than their own!

    Another possibility (after having a search around... so keep in mind some of this is new to me as well!) could be the issue is connected in some way to "double hops". The topic which sounds similar to your situation but with SQL rather than a file server was raised here http://stackoverflow.com/questions/8249367/asp-net-impersonation-make-windows-identity-flow-across-to-sql-server and perhaps the most pertinent links from there are http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx and http://blogs.technet.com/b/taraj/archive/2009/01/29/checklist-for-double-hop-issues-iis-and-sql-server.aspx which go into how to get around it. If that's what's causing your problem then it sounds like perhaps the relevant Domain A users already (or automatically) have the required delegation permissions, while the Domain B ones don't, which would explain why you're seeing different results depending on the domain the user is coming from.

    Hope some of that helps. I'd definitely be interested to know if any of those fix it and what ended up being the fix!

    Wednesday, June 26, 2013 8:33 PM