Last post Dec 05, 2018 08:36 PM by hanssj
Nov 20, 2018 04:11 PM|hanssj|LINK
First, some context about this: We are developing a web application for internal use within our domain/corporate network. Technologies used are an MVC 5 application running on an IIS 8 instance on a Server 2012 R2 server. I have created a minimal sample
within our application to try to figure out the problem, why authentication and impersonation is not working as expected.
Problem is this: According to this article https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff649264(v=pandp.10) there should be a way to get the user
that is authenticated from within the ASP.NET using any of these three identities available. On the test server (Windows 7 with IIS 7.5), these properties are all pointing to DOMAIN\USER, but on the production instance the output is as follows (the identity
of the AppPool).
In web.config the settings are all made as follows (like in
<identity impersonate="true" />
<authentication mode="Windows" />
Debug output shows that authentication mode is actually using Windows Authentication and testing with non-domain-joined clients, this is actually the case. Entering any credentials that are not domain logins or local server windows user accounts, a 401 unauthorized
is returned successfully. This means that authentication works.
Then why is none of the listed properties in ASP.NET set to the identity of the authenticated user making the HTTP request?
Thanks for helping!
Nov 20, 2018 06:18 PM|PatriceSc|LINK
You are 100% sure you are showing System.Web.httpContext.User.Identity.Name ? You tried to show IsAuthenticated and AuthenticationType ? Also disable impersonation.
The above property should ALWAYS return the authenticated user for this web request (that is if authenticated or "blank").
Forget about the thread or Windows identity which is to return the account under which the code runs (and so if using that mistakenly you have to enable impersonation even if you don't really need it to get the "expected" result).
Nov 20, 2018 08:55 PM|bruce (sqlwork.com)|LINK
if your clients are getting a 401, then I'd check that authentication mode is set correct. use IIS to check the configuration of the application.
Nov 21, 2018 12:42 PM|hanssj|LINK
I'm not entirely sure, but it's the HttpContext exposed by the Controller base class as shown below:
The content of these variables is as follows:
This is really mindboggling, because Authentication Mode is correct according to the API and the user gets successfully authenticated. Can you confirm if I'm using the correct property to access the System.Web.httpContext.User.Identity.Name property?
@Bruce: I only get the 401 Unauthorized when purposefully giving false credentials, that's not the issue. It's the expected response.
Nov 22, 2018 06:11 PM|PatriceSc|LINK
Yes this is System.Web.HttpContext.User.Identity.Name, User being exposed as well at places where you frequently need to use it. You are 100% sure you are showing the correct property in your HTML table ? BTW you disabled impersonation? This is not needed.
You are using Remote desktop ? It seems someone else have the same problem when using a VPN, and running remote desktop to use a browser on the machine where IIS is running.
The behavior I saw until now is that User.Identity.Name is ALWAYS the browser side authenticated user (it works even for other authentication methods such as Form, Azure AD, ADFS etc...). Other methods are returning the account under which the code runs
and so it depends on the site configuration (and the IMHO wrong advice sometimes given is to enable impersonation).
Nov 26, 2018 10:14 AM|hanssj|LINK
Thanks for the reply!
No change after disabling impersonation. Not using RDP or a VPN either, it's just standard client/server connection with the browser running on my personal device. I really don't know what might be wrong anymore.
Nov 26, 2018 12:14 PM|PatriceSc|LINK
I don't remember to have seen someone reporting this kind of behavior. What if you check the IIS log ? Which value do you see in csUserName ?
By default log files are stored at C:\inetpub\logs\LogFiles
Nov 26, 2018 12:32 PM|hanssj|LINK
Looking at the logs, the correct DOMAIN\USER value is recorded there.
Nov 26, 2018 01:10 PM|PatriceSc|LINK
Ah and so once again you are 100% sure you are showing System.Web.httpContext.User.Identity.Name or could it be a mistake in your code which would show the value returned by another method claiming it to be User.Identity.Name ? It should
really return the value you are seeing in the IIS log.
If it still doesn't work I would restart with a brand new project with really the minimal amount of code (could it be some code that changes the expected user identity ?). If IIS is left alone, it should really show the same value than the one shown in
the IIS log.
Nov 26, 2018 02:18 PM|hanssj|LINK
Do you have a known-good sample to get the User.Identity.Name? A Razor minimal sample would probably be the minimum working sample.
I have made a pastebin here with the current code example: https://pastebin.com/ikypFfrS
What is even more odd, is that by deploying the same project to the Win7-based test server, there are no issues whatsoever there. Is there a comprehensive list of config file locations for IIS that I could diff to check what setting might be different.
Nov 26, 2018 04:30 PM|PatriceSc|LINK
What if you add [Authorize] to your controller or you add a global filter ?
I find really weird that the IIS log shows the correct value while User.Identity.Name is showing the application pooll account ??? I'm not sure I would know how to get this behavior if I wanted to get it.
Nov 26, 2018 04:40 PM|mgebhard|LINK
I'm guessing this is a double hop situation where the web server is making outbound requests to a service or DB. At least that would explain the problem statement.
Nov 29, 2018 09:03 AM|hanssj|LINK
Actually, this isn't the case: There is the client on the browser, the IIS hosting the ASP.NET MVC application and a single SQL server that is referenced only using a connection string with embedded SQL username and password (non-AD-based). The SQL server
runs on the same WinServer 2012 instance.
Dec 05, 2018 08:36 PM|hanssj|LINK
I have found the solution to this problem: There was some unknown config in the IIS Site configuration that made it not give the correct data to ASP.NET. Deleting and re-creating the site in the IIS control panel solved this issue. What the root-cause was,
I can't say though.
That this would solve the problem got apparent when I had ported the whole site to ASP.NET Core first (because it's better anyways) and created a new site for testing (worked fine), then copied the whole folder over to the old location and the ASP.NET Core
site also stopped working correctly. So the reason was also never ASP.NET, it was always on the IIS side.