Note that some of the content does not apply to RC1 or earlier versions and may not apply to later versions either.
Enable Windows Authentication
The server running the application must be configured to enable windows authentication and disable anonymous authentication. If anonymous authentication is enabled, then it will be used by default and no user information is collected or required.
- IIS + Kestrel: Windows authentication is configured in IIS (or
Properties\launchSettings.jsonwhen debugging with Visual Studio and IIS Express).
- WebListener: Windows authentication is configured in web host builder programmatically.
At the time of writing, windows authentication only works when the server is hosted on the Windows platform (IIS and WebListener are Windows-only).
Take a look at ASP.NET Core Hosting for setting up either hosting option.
When using WebListener, you need to set up the authentication scheme in WebListener options in
Note: installing package
Microsoft.Net.Http.Server from NuGet is required for accessing the AuthenticationSchemes class.
When using IIS Integration (Express or not), there are some configuration options that you can tweak.
Add configuration in
Startup.cs in the
All three options default to
true at least when running on IIS Express through Visual Studio.
IIS Express (when Debugging from Visual Studio)
In visual studio, right-click into the project properties and select the Debug tab. Check “Enable Windows Authentication” and uncheck “Enable Anonymous Authentication”
The values are stored in
Making this change also forces
system.webServer) each time you start the app in debug mode.
Enable windows authentication in IIS application host configuration file which can be found in the
NOTE: IIS Express application configuration file lives in
$(solutionDir)\.vs\config\applicationhost.configsource when using Visual Studio 2015 (or
%userprofile%\documents\iisexpress\config\applicationhost.config or somewhere else when using an earlier version).
TODO not verified using IIS Express directly. The configuration does not affect the behaviour of IIS Express when debugging through Visual Studio.
The correct section can be found in configuration -> system.webServer -> security -> authentication -> windowsAuthentication.
The configuration should look as follows.
TODO May have to remove the
Negotiate provider as per http://stackoverflow.com/questions/36946304/using-windows-authentication-in-asp-net?
Windows authentication can also be enabled using the Internet Information Services Manager: Go to the site’s Authentication settings, enable Windows Authentication and disable Anonymous Authentication.
Make sure that the
forwardWindowsAuthToken is set to
TODO For accessing further resources such as an SQL DB or other APIs with windows authentication.
Accessing User Information
You can access user identity in
.cshtml files by using, for example:
If you need to access the HttpContext, you need to add the HttpContextAccessor service in
And in cshtml:
In MCV or WebAPI Controllers
Make sure you include credentials in calls, e.g. with
Authorization By Group Membership
- Local groups are written without the domain part or prefixed with the host name:
- Built-in local groups (e.g.
BUILTIN\Administrators) are not recognized by name. You have to write the corresponding SID instead.
- You can find out the SIDs by using the
BUILTIN\Administratorsgroup is not recognized even when using the correct SID.
Group membership shows as role membership in ASP.NET Core. You can enforce group membership directly with the Authorize attribute, with an authorization policy, or programmatically in the controller methods.
[Authorize(Roles = @"<domain>\<group>")] attribute (or
[Authorize(Roles = @"<domain>\<group1>,<domain>\<group2>")] for multiple allowed roles) to the controller or method.
Add a new policy to service configuration in
ConfigureServices method in
To get the required group name from settings, add the group name into
appsettings.json (note the double backslashes):
Then read it in when configuring authorization:
Use a comma-separated string for multiple allowed roles:
Finally, add the authorize-attribute on the controller or method:
[Authorize(Policy = "RequireWindowsGroupMembership")]
The policy syntax allows for more elaborate authorization scenarios with custom requirements, such as activity/permission-based authentication
Check for role membership in controller method and return 403 Forbidden status code if not authorized.
Note that the return type of the method must be
If you need automatic windows authentication, then you may have to enable it specifically in the client browser
- IE (TODO verify same works in EDGE)
- Advanced -> Enable Integrated Windows Authentication in Internet Options
- Security -> Local intranet -> Custom level -> User Authentication -> Automatic logon / Prompt for user name and password
- Chrome uses settings in Windows’ internet options so the IE options should sufficesource
- about:config -> network.automatic-ntlm-auth.trusted-uris -> add url of application
Different Domain or No Domain Binding
TODO I did not get this to work from a remote site, with or without VPN connection (flashes a new console window and dies instantly, unable to capture error message)
If you are developing on a computer that is not bound to a domain, or is bound to a different domain that the app should authenticate against, you can run the server like so:
runas /netonly /user:<user> "<command> <args...>"
IIS: you must establish trust between the two domains to be able to run app pools under a user in different domain than the server.
IIS: does this work at all when running as network service??