[WinAuth] Clarify app configuration and deployment

[bdlane]

Adding the web.config with the authentication elements causes a configuration error at runtime.

Starting from the 'Web Application' template in the new project dialog in Visual Studio 2019, with Windows Authentication enabled, I can run and debug the project fine.

Then, following the steps outlined in the 'Development side configuration with a local web.confg' section (i.e. adding a web.config file with the <system.webServer><security><authentication> tags), running the project returns a HTTP 500.19, with the following config error:

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

You can fix the problem by modifying the applicationHost.config file in the solution's .vs directory to unlock the relevant sections. However,

1. this step isn't described in the docs, and
2. this can't be right, can it? The applicationHost.config file is auto-generated (by VS?), so might get overwritten, and will need to be done on every developer's machine.

Is this the expected behaviour?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 401ad9a0-9e51-80a2-5846-82e9790d7257
• Version Independent ID: fbc36c26-9992-1f4c-66d3-02f898ee7ec4
• Content: Configure Windows Authentication in ASP.NET Core
• Content Source: aspnetcore/security/authentication/windowsauth.md
• Product: aspnet-core
• Technology: aspnetcore-security
• GitHub Login: @scottaddie
• Microsoft Alias: riande

[guardrex]

Thanks for the report @bdlane ... I think we need to clarify something in the topic for sure (at least for the time being): "development-side configuration" doesn't address running the project on the development machine with IIS Express. It only addresses setting up the project for WinAuth while it's on the development machine so that when it's deployed to an IIS production environment it has the web.config with the correct settings for WinAuth. The next section, Publish and deploy your project to the IIS site folder probably adds to the confusion because although it speaks to deployment (to an IIS site folder) it immediately says to "launch the app." It could be clarified a bit further: It really means deploy the app to the IIS production environment ... then run it.

Anyway ... Yes! ... you probably do need to modify applicationHost.config on the local machine for it to work with IIS Express. Those sections are locked by default. But again, the topic isn't trying to explain how to run the app locally that way ... perhaps it should ... but it doesn't today.

@Tratcher What direction would you like to take:

• Should I modify this to clarify that it applies to IIS/IIS local only?
• IIRC, IIS local install has those sections unlocked by default ... is that correct?
• Shall we broaden the coverage to include IIS Express? If so, it will require unlocking the sections: What's the best approach to do that?

[Tratcher]

@shirhatti @jkotalik

[Nitro66215]

If I may add a couple points. Setting up in the web.config file also does not make the current session user ie: WindowsIdentity.GetCurrent().Name equal the Context.User.Identity.Name. The WindowsIdentity.GetCurrent() is equal to the computer / account used to run the website in IIS. The forced way for my SQL queries to run under the Context.User is to do a WindowsIdentity.RunImpersonated on the User accesstoken. I would prefer to avoid that and just have the imperonated setting set to true in the web.config

[guardrex]

@Nitro66215 Engineering approved what's in the topic. They'll respond here when they see your post. Right now, this is the approved guidance for that ... https://docs.microsoft.com/aspnet/core/security/authentication/windowsauth#impersonation ... i.e., so far, they're saying don't do it app-wide ...

... wrapping entire requests or middleware chains isn't supported or recommended.

[Tratcher]

Running impersonated as the user has many side effects and should be avoided where not absolutely necessary for outbound IO. It's also not practical until .NET Core supports proper async impersonation. https://github.com/dotnet/corefx/issues/24977

[Nitro66215]

Understand. This is not application wide. Only on the calls to SQL. However, this is also in a separate class that the calls to SQL are being done. HttpContext is passed in. However, I'm still running into the User.Identity being looked at as the host computer and not the windows user on the published application. Running locally under debug it operates as it should.

[Tratcher]

HttpContext.User.Identity is the host computer account? That's not something ASP.NET would do. User.Identity is either anonymous or the client identity. Is this a second tier request being made from another server endpoint? In that case it was the machine account that made the request.

Debugging locally IIS Express runs as the current user.

[Nitro66215]

I misspoke. That was something else I must have done before.

Currently the WindowsIdentity.GetCurrent().Name is coming up as NT AUTHORITY\NETWORK SERVICE. When it hits the class module with the referenced httpContext, the RunImpersonated section gets NT AUTHORITY\ANONYMOUS LOGON from httpContext.User.Identity. On the page itself, Context.User.Identity.Name is correctly showing the currently logged in windows user.

[Tratcher]

Can you show how you did the impersonation?

It's also possible you don't have permissions to impersonate (though I'd expect that to cause an error). What does ImpersonationLevel for the HttpContext identity say?
https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.impersonationlevel?view=netframework-4.8