User mode authentication isn't supported with Kerberos and HTTP.sys.
What does this mean? I can't find a concrete definition of "User mode authentication" via Google. Does this mean that users cannot sign-in to an ASP.NET web service which uses HTTP.sys?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Hello @aschuhardt ... I think I ran into this myself when I was working on some of the topics.
@Tratcher ... do you think that the _Applications and user mode_ section of https://docs.microsoft.com/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication#BKMK_CredentialInputForApplicationAndServiceLogon is sensible content? If so, I can link the "user mode" text to the Credential input for application and service logon section of that topic.
IIRC, there are limited direct references to "user mode." One of them is https://docs.microsoft.com/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode, but there's no security context there. There are more link opportunities to "kernel mode," but many of them don't refer to user mode (or security for that matter), so they wouldn't be helpful here.
Right, User mode is the opposite of Kernel mode. Http.Sys is a kernel mode system driver that has an authentication feature built in, but that feature uses the system account and settings when authenticating. The AspNetCore HttpSys server wrapper over Http.Sys depends on that kernel mode feature for windows auth.
By contrast, IIS supports either kernel mode or user mode auth. You can configure it to use the Http.Sys kernel mode auth feature, or the one IIS provides in user mode. The configuration for each is different. .NET's HttpListener only supported user mode.
but that feature uses the system account and settings when authenticating
When I use HTTP.sys in ASP.NET Core with Negotiate/NTLM authentication specified, per the docs article this issue concerns, I'm prompted by my browser for a username/password combination upon accessing the app.
After I have successfully authenticated, my HttpContext on the server has a ClaimsPrincipal associated with it, which contains a number of claims. Included among these claims is a username that matches the username I used to authenticate in my browser.
Are you saying that the claims that are assigned to the user principal on the server at this point don't correspond to the user account that I used for authentication? Do they correspond, instead, to the "local system" account?
This is where I'm confused. I would think that the credentials I used to log into the web page would have some bearing on the info the server has about the currently-authenticated user, but this talk of "authentication is not supported" is throwing me off.
Thanks for your help with this.
From: Chris Ross notifications@github.com
Sent: Thursday, September 10, 2020 12:01 PM
To: dotnet/AspNetCore.Docs
Cc: Addison Schuhardt; Mention
Subject: Re: [dotnet/AspNetCore.Docs] Clarification needed on what is meant by "User mode authentication isn't supported with Kerberos and HTTP.sys." (#19819)
Right, User mode is the opposite of Kernel mode. Http.Sys is a kernel mode system driver that has an authentication feature built in, but that feature uses the system account and settings when authenticating. The AspNetCore HttpSys server wrapper over Http.Sys depends on that kernel mode feature for windows auth.
By contrast, IIS supports either kernel mode or user mode auth. You can configure it to use the Http.Sys kernel mode auth feature, or the one IIS provides in user mode. The configuration for each is different. .NET's HttpListener only supported user mode.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
It seems like the explanation is along those lines. The topic says ...
HTTP.sys delegates to kernel mode authentication with the Kerberos authentication protocol. User mode authentication isn't supported with Kerberos and HTTP.sys. The machine account must be used to decrypt the Kerberos token/ticket that's obtained from Active Directory and forwarded by the client to the server to authenticate the user. Register the Service Principal Name (SPN) for the host, not the user of the app.
... so I guess we can just link "kernel mode" and "user mode" to https://docs.microsoft.com/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode, since that topic clarifies the difference between the two modes. It doesn't need to address security aspects ... just define the terms.
Windows/NTLM/Kerberos auth aren't just about authenticating the client to the server, but also about authenticating the server to the client. It's similar to TLS in that regard, where both the server and the client can provided certificates as a form of identity.
When running in Kernel mode the identity used for the server half of the handshake is the machine account. When running in user mode the identity is the the one running the application processes. This affects where you configure things like SPNs.
The final ClaimsPrincipal on the HttpContext is still going to represent the client regardless of using user mode or kernel mode to negotiate it.
Thanks for this explanation, that makes a lot more sense now. There is quite a bit more to this that was confounding my understanding of what is happening.