[Epic] Kerberos Authentication in ASP.NET Core

[analogrelay]

We want to support Kerberos Authentication in ASP.NET Core.

For 3.0, we are targetting the following supported environments as a minimum viable product (MVP):

• ASP.NET Core Server Platform: Linux (including containers) (we'll try to avoid doing anything to prevent it from working on Windows/macOS, it just won't be the testing focus)
• Domain Controller type: Active Directory, running on a Windows OS in the .NET Core
  support matrix (Windows Server 2008 R2 or higher)
• Client: Domain-joined Windows Machines using IE11 and Edge. Other "evergreen" browsers (Chrome, Firefox) as long as they support Kerberos auth.

MVP Features

• Challenge for a Kerberos ticket
• Decode the ticket into an Identity that includes a user identifier of some kind
• (Depending on the feasibility) Including group information in the Identity?
• Support for offline ticket processing via a key table (keytab)

Not in the MVP:

• NTLM is not a priority in the MVP, but we think it may come pretty cheap once Kerberos is up and running.
• Allowing the server to call other services using the Kerberos identity provided by the client (i.e. SQL)
• Allowing non-Windows servers to authenticate with Windows AD-protected resources via a service account
• Unification with WindowsIdentity
• Support for Domain Controllers/Server platforms other than those listed above (though we believe others may come "for free", we just won't be committing to testing those)
• Support for Kubernetes gMSA is for Windows containers, and since the MVP focuses on Linux, Kubernetes gMSA isn't part of the MVP. We won't do anything to prevent Windows usage if possible though.

Other server platforms, DCs, clients, etc. may well come for free, but I want to set a really clear bar for what we are going to be committed to achieving in 3.0. We can always iterate on this in future releases.

Child Items:

• https://github.com/dotnet/corefx/issues/8221 CoreFX Linux Server Kerberos implementation
• https://github.com/dotnet/corefx/issues/36896 CoreFX Negotiate API Postponed
• Add IConnectionCompleteFeature.OnCompleted #9754 Server connection state (also Consider exposing Bedrock's "Connection Features" on HttpContext #9213)
• xplat Integrated Windows Authentication (ntlm/Kerberos) #4662 Auth middleware
• Docs for new Negotiate auth handler AspNetCore.Docs#12420 Docs
• CTI test script Cut from 3.0

[analogrelay]

cc @Tratcher

[analogrelay]

FYI @blowdart - Updated to include MVP (and non-MVP) scenarios.

[markrendle]

Super-happy to see this getting some love. It's going to be a huge unblocker where I'm working at the moment.

[analogrelay]

@markrendle Please let us know if the MVP (described above) is sufficient for your scenarios! If there are gaps, we'd like to at least track them (though we can't commit to much, if anything, beyond the MVP in 3.0)

[csturm83]

Am I understanding the MVP correctly, that Kerberos Constrained Delegation in Kestrel running on Linux will not be supported initially?

My enterprise scenario is a .NET Core web application running in a Linux container which needs to delegate Windows credentials (using Kerberos) to a web service hosted on a Linux machine (assuming appropriate keytabs/SPNs configured).

If this scenario will not be supported by the MVP, does anyone know of an alternative way to implement this today? I had 2 (maybe unrealistic) ideas:

1. Is it possible to reverse proxy NGINX or Apache to Kestrel inside of a Linux container using their respective Kerberos modules to delegate the credentials? I.e. would a WindowsIdentity.RunImpersonated call (or similar) work in such a configuration? The fact that it's WindowsIdentity would lead me to believe no.
   (IE) -> (NGINX/Kestrel/.NET Core app in Linux Container) -> (web service)

2. Is it possible to reverse proxy IIS externally to Kestrel inside of a Linux container, delegating credentials using WindowsIdentity.RunImpersonated.
   (IE) -> (IIS) -> (Kestrel/.NET Core app in Linux Container) -> (web service)

Reading the third bullet in this comment gives me the feeling that neither of these approaches will work.

@Tratcher @Drawaes

[blowdart]

Given that Kerberos Constrained Delegation is a Windows Server feature, rather than a Kerberos feature, you're correct, this isn't going to be supported initially, if at all.

Unblocking "Windows authentication" to a web app hosted on linux is the goal for the MVP.

[csturm83]

Thank you @blowdart for your quick response!

Given that Kerberos Constrained Delegation is a Windows Server feature, rather than a Kerberos feature,

The way I understand it, constrained delegation is a Kerberos protocol extension (S4U2Proxy) that Microsoft invented (may have started out as a Windows Server feature as you suggest). I believe the MIT Kerberos implementation currently supports the S4U protocol extensions.

Likely not a compelling enough reason to change the MVP (which I believe is a big step in the right direction!). I would just suggest/request that the S4U extensions are a feature I believe are worth pursuing in future iterations, if not the MVP.

I'm not entirely sure, but it sounded like some folks chiming in on AspNetCore Issue #4662 had use cases similar to mine (although I believe delegating to SQL).

[blowdart]

Yea, we're treating this as a starting point to unblock what is most requested. After that, well, we'll think about additions based on customer demand,

[Tratcher]

Announcement:
Please try 3.0.0-preview5 System.Net.Security.NegotiateStream in your environments. NegotiateStream allows you to authenticate a TCP connection using NTLM or Kerberos. It will not get you HTTP auth, but it will let you know if you have correctly configured in your environments.

In preview5 we added support to NegotiateStream for server scenarios on Linux. In the next milestone we will implement HTTP server auth using the same underlying libraries.

[ebekker]

Is it possible to control which underlying provider is enabled by the Negotiate support? For example, if I wanted to disable NTLM, but only allow Kerberos, is there a way to control this?

Skimming through the code, I'm guessing this is not baked in. And I believe this support was built atop the NegotiateStream support, and I don't think that flexibility is supported there either, correct?

[Tratcher]

@ebekker no, on Windows that can be controlled machine wide via the registry. On linux you've installed the NTLM module or you haven't.

[ebekker]

Thank you @Tratcher, I was investigating the possibility of migrating some applications we have that are currently hosted behind IIS, where you have finer control of the Windows Authentication providers, such being able to selectively enable/disable and also reorder for preference. We were exploring removing IIS from the equation if we migrated some apps from Framework to Core, but it looks like we'll need to keep IIS for now to maintain that level of control.

Quick follow up -- as your are more intimately familiar with the inner workings of the Kestrel implementation of Negotiate, would you say there is anything that would fundamentally prevent or make difficult to add this type of control to the Negotiate Authentication implementation (i.e. being able to selectively choose which providers to support and in what preferred order)? For example, if we took it upon ourselves to dig into this.

[Tratcher]

@ebekker We have a related thread discussing this:
#14951 (comment)

Summary: We're unlikely to add support for NTLM because it is an old, insecure protocol.

Most other things IIS does can also be added here, except for kernel mode auth.

[ebekker]

Thanks -- just to be clear, we were interested in actually removing NTLM support, as right now, when we use the Negotiate Auth package, it appears to be defaulting back to that, whereas we prefer to stick strictly to Kerberos. Unfortunately, we cannot disable it domain-wide because of some legacy applications.

[Tratcher]

@ebekker ah, that's a different discussion. Go ahead and file a separate issue for that.

[0x4Graham]

Hi all,

I am no expert when it comes to Kerberos or NTLM authentication and so maybe I have missed a solution mentioned above.

I have a .Net Core 3.0 application running on a docker container within Kubernetes connecting to a SQL Server running on a windows server machine.

Currently, I connect to the SQL server using a username and password in my connection string.

Our DBA team has asked that we remove the username and passwords and move towards integrated security. As mentioned in one of the posts above, if you were running in IIS, you can just run the app as that user.

I have come across the following solution: https://www.codeproject.com/Articles/1272546/Authenticate-Net-Core-client-of-SQL-Server-with-In

But it is a really dirty solution and adds unnecessary overhead to the application.

I am wondering if there is a better solution out there? Or any plans to support Kerberos auth in such a manner?

[Tratcher]

Comments on closed issues are not tracked, please open a new issue with the details for your scenario.