xplat Integrated Windows Authentication (ntlm/Kerberos)

[Eilon]

From @evil-shrike on January 25, 2018 12:41

I haven't found any ticket for tracking the xplat Windows-auth support in aspnet/dotnet core.
I understand that currently we have only out-of-the-box Windows auth support in IIS/IISExpress and http.sys and only on Windows.

There's a decent article in docs https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?branch=pr-en-us-3622&tabs=aspnetcore2x on how to configure Windows auth. But it says nothing about non-Windows use-cases.

There're many issues here on Github and questions around on sites like SO on "how to implement Windows authentication in aspnet core on Linux". But all issues are closed with reasoning like "Kestrel doesn't implement Windows auth currenly, use IIS or https.sys". This is understandable but it's unclear what to do if we need to host an app on Linux and support integrated Windows auth (in intranet networks).

So there are several points which need to be addressed:

• what options do exist currently (at the time of 2.0/2.1) for getting integrated Windows authentication on Linux and other *nix OSes?
• what are plans (if any) for improving/adding such functionality?

I understand that strictly speaking this issue is related to Kestrel project probably, but it's more easily to find it here though. Moreover it's implementation details where Windows-auth support should live.

Anyway it should be some source of information describing what to do with aspnet core apps on Linux for adding Windows auth.

Some additional info:

• middleware for ntlm support - https://github.com/OneBitSoftware/Microsoft.AspNetCore.Authentication.ActiveDirectory (ntlm only, Windows only - "Achieving server-side NTLM handshaking depends the Windows platform due to interop, dependency on domain-joined machines and secur32.dll")
• it's possible to authenticate via Kerberos on Linux - https://technet.microsoft.com/en-us/library/2008.12.linux.aspx
• there's Application Proxy with Kerberos Constrained Delegation in Windows Server and Azure AD which seems to solve such problems - https://blogs.technet.microsoft.com/applicationproxyblog/2015/09/21/all-you-want-to-know-about-kerberos-constrained-delegation-kcd/ but it's complex
• there're modules for Nginx (http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ntlm) (requires commercial license) and Apache httpd (http://adldap.sourceforge.net/wiki/doku.php?id=mod_auth_ntlm_winbind) (it's unclear how stable it is) to add ntlm support
• It seems that Java has Kerberos support out-of-the-box - https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/single-signon.html
• Java implementation for app servers - http://spnego.sourceforge.net/ (not sure how it relates to the previous point)

Copied from original issue: #2824

[Eilon]

From @davidfowl on January 25, 2018 15:23

We don't have any plans AFAIK to support windows authentication when running on linux. There were discussions we had early on about how windows authentication could be supported in Kestrel, but that was by calling back into windows, not writing a fully managed implementation of ntlm, kerberos etc.

/cc @blowdart @DamianEdwards

[Eilon]

From @evil-shrike on January 25, 2018 15:33

We don't have any plans AFAIK to support windows authentication when running on linux.

This is a very pity, especially in contract with the support of Kerberos in Java... May I ask what are reasonings for such a decision?

[Eilon]

From @blowdart on January 25, 2018 15:35

Because it would be too risky and too hard to secure. We're not about to take a dependency on Samba.

[Eilon]

From @khellang on January 25, 2018 15:43

According to https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-authentication, it looks like RHEL, SUSE and Ubuntu already have clients for Kerberos, though?

[Eilon]

From @Tratcher on January 25, 2018 17:28

It's not impossible, but it's an extremely large and high risk work item. We're still working on Kestrel's fundamentals such as protocol correctness, stability and performance. Large, high risk features will need to wait.

[Eilon]

From @evil-shrike on January 25, 2018 18:17

Well, ok, it's too early to expect Windows-auth in Kestrel, but we need some guidance on how to support Windows-auth on Linux in general in the meantime.

I can see two approaches:

• "reverse proxy" - all unauthenticated requests will be redirected to a Windows-IIS machine and then back - it can be achieved via some middleware I guess (on Linux side) and some simple app on Windows-side. But it would be nice to have some working and tested solution and not invent a wheel
• authenticate in web-server (hosting the aspnetcore app) - probably in Nginx/Apache modules - again it'd иу nice to have a list of good and working modules for every common server

So any recommendations (or any other piece of advice) are highly desirable.

[Eilon]

From @Tratcher on January 25, 2018 22:8

Your first scenario could be accomplished using OpenIdConnect and an auth server like IdentityServer4.

[Eilon]

@blowdart HI

[blowdart]

@evil-shrike when you say "Windows Authentication" what do you mean?

Do you want

1. "I want to use Windows Authentication to authenticate against a web site"
2. "I want to use Windows Authentication to authenticate against a web site and then I want to be able to impersonate that user so I can access network resources"
3. "I want to run my web site under a linux account that comes from a domain via kerberos and let it talk to SQL as that account"

Or something else altogether.

One thing to note up front - it's extremely unlikely we'd implement NTLM, that protocol needs to die and since Win2k it's Kerberos anyway.

[evil-shrike]

@blowdart I guess all these and other use-cases will find their use if we say "dotnetcore supports Windows auth on Linux". I mean people will want them. But in my particular case I need the 1st one - "I want to use Windows Authentication to authenticate against a web site".
It'd be even OK if I have just a ClaimsPrincipal in HttpContext.User (not WindowsPrincipal) for an authenticated (on server) user via Kerberos.

Also we need to be able to talk to LDAP/AD. It was overwhelming to know that currently we don't have API for LDAP/AD access on Linux (no System.DirectoryServices.Protocols).

I wouldn't care about NTLM if we'll have Kerberos. But correct me if I'm wrong that this means that authenticating via local Windows users won't work, right (as Kerberos requires a domain)?

[blowdart]

WRT NTLM: There's no local Windows users on a Linux system ... is that really a problem?

Directory Services is apparently coming, but that's .NET Core rather than ASP.NET Core.

The fun part of this is it might have to be part of .NET Core, because really WindowsPrincipal is very fixed to Windows, and that's what would do the delegation flow/impersonation. We'd have to examine the possibility of KerberosPrincipal of something of that ilk, but honestly the use cases need to come first to allow me to justify it and get the scope of the work figured out.

[evil-shrike]

WRT NTLM: There's no local Windows users on a Linux system ... is that really a problem?

yeah, sure, not a problem, sorry )

[blowdart]

Another question - is this for a stand alone box, or for containers?

I ask because joining your containers to a domain, or setting up SPNs for them seems wrong. In that case, if all you want is auth for a web site, using OIDC or WSFed to an ADFS server seems like the better option, this way it's clean with no dependencies. That way auth is taking care of by an auth provider, and your container has no pollution that demands connections to non-container infrastructure.

(Forgive me if I'm not using the right container terms here)

[evil-shrike]

I needed it for standalone server.
As for containers I understand your reasoning but I'm afraid that requiring a ADFS server imposes additional complexity for developing and testing. Also currently it's not very clear how to implement such an approach.

[blowdart]

Well, ADFS would just be a typical external identity flow, either OIDC or WS-Fed, and it'd work like Facebook, twitter or goggle, or indeed an external auth, except ADFS knows what your internal network is, and supports integrated auth too, so it's automatic for internal users.

Anyway, as you can imagine Kerberos / SPNEGO / Integrated, whatever you want to call it, would be a brand new feature. So this will popped on the backlog, and as each new version starts planning we'll revisit it.

[blowdart]

For research purposes (most are out of date, but a decent starting point)

Kerberos is a network authentication protocol for client/server applications & SPNEGO provides a mechanism for extending Kerberos to Web applications through HTTP

https://msdn.microsoft.com/en-us/library/ms995330.aspx HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol
https://msdn.microsoft.com/en-us/library/ms995329.aspx HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol
https://msdn.microsoft.com/en-us/library/ms995330.aspx#http-sso-2_topic2 HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol
https://msdn.microsoft.com/en-us/library/ms995331.aspx HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol

RFC 4120 - The Kerberos Network Authentication Service (V5)
RFC 2743 - The Generic Security Services Application Program Interface (GSS-API)
RFC 4178 - The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
RFC 4559 - SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows

[blowdart]

Linked to https://github.com/dotnet/corefx/issues/15017

[undecided2013]

My use case would be for ASP.Net Core living in a docker container on Linux needing to connect to legacy Sql Server on Windows which currently uses AD Groups associated with roles for Authorization. In legacy .net apps. connections to sql server are usually done with service accounts that are in AD.

[tynor88]

@undecided2013 Have you progressed with a solution for this? I have the exact same use case.

[valorl]

@blowdart Here's a managed-only implementation of Kerberos on .NET (xplat) you might wanna look at for implementing this: Kerberos.NET. It uses a ClaimsPrincipal.

@undecided2013 This is possible to do if you install Kerberos client dependencies inside the container (e.g. krb5-user on debian). The tutorial from the vscode-mssql repo might help. Keep in mind you'll have to continuously refresh the ticket, so there will have to be a supervised script running in your container. If you're using Kubernetes, you can make separate sidecar container where this will run and make it share the cache in memory with the app container.

[blowdart]

OK folks, give me survey love :)

https://microsoft.qualtrics.com/jfe/form/SV_9LvT1hbZ2nHHcFv will help us understand what you want, you might even get followup calls to discuss it in greater detail. Free feel to spread the survey link around.

@evil-shrike @undecided2013 @tynor88 @valorl

[Eilon]

Setting milestone to preview6 so it's out of the generic 3.0.0 milestone.

[John0King]

Will it be a Microsoft.AspNetCore.Authentications.<NTLM/Kerberos> package or implement on the kestrel server ?

[Tratcher]

@John0King my current prototype is as an auth package. Either way we need some new connection state features from the server, so it will only work with Kestrel.

[Tratcher]

FYI: There's a draft PR for this now at #9831.

[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.

[Tratcher]

Verified in SDK 3.0.100-preview6-012105-1 on Ubuntu.

[pavelzhilnikov]

Now it is possible to use Kestrel with Nginx as reverse proxy and SPNEGO module to get Kerberos is working and i can use authorize attribute or get login using HttpContext.Current.User.Identity.Name?

[Tratcher]

Yes. Careful though:
"Credentials can be persisted across requests on a connection. Negotiate authentication must not be used with proxies unless the proxy maintains a 1:1 connection affinity (a persistent connection) with Kestrel."

I don't think NGinx guarantees that.

[pavelzhilnikov]

@Tratcher

Suppose I want to experiment inside the company in which I work, but I do not understand the simplest thing. If I publish a simple web api application on Linux with Windows enabled and anonymous authentication and add the Authorize attribute to the controller, then the application throws an exception defaultscheme must be specify.
On iis, this problem is solved with a single line of code:
services.AddAuthentication (IISDefaults.AuthenticationScheme);
I do not understand how I should set up Kestrel.

Maybe some other opportunities to make Kerberos work on Linux with Kestrel, even if not official?

[durranitech]

@concretor91

Maybe you are missing this

services.AddAuthorization(options =>
{
options.FallbackPolicy = options.DefaultPolicy;
});
services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
.AddNegotiate();ere the sample code @Tratcher put up
https://github.com/aspnet/AspNetCore/blob/40091e9a12491d4e4a97df940cb6e589c898f908/src/Security/Authentication/Negotiate/samples/NegotiateAuthSample/Startup.cs

[pavelzhilnikov]

@durranitech
Thanks, could not find this information

[Tratcher]

The docs for this are available here:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-3.0&tabs=visual-studio#kestrel
Let me know if you have trouble following them.

[valorl]

@Tratcher Thanks. Very glad this is coming in 3.0.

Are there any plans for including the AD groups in the identity ?

With this package, the only claim included is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name, whereas when using the SteveSyfuhs/Kerberos.NET library, the ClaimsPrincipal has all the AD groups included as claims. IIRC, the claims should already be part of the received Kerberos ticket.

[Tratcher]

Are there any plans for including the AD groups in the identity?

Not in this release. Please open a new issue to track that ask.

So far we haven't even identified the APIs/libraries necessary to make that work on Linux. We don't process tickets directly, we rely on SChannel and GSS to handle that.

[valorl]

@Tratcher Sure, I've created #12938 to track this.

[nino96]

@blowdart In the following comment that you posted, can you explain how to achieve the third scenario in asp.net core mvc 2.1?
Basically I have a self-contained .net core mvc app deployed to linux and it needs to be able to connect to an SQL Server with integrated security, both the linux server and sql server being in a corporate intranet. Any help would be much appreciated!

@evil-shrike when you say "Windows Authentication" what do you mean?

Do you want

1. "I want to use Windows Authentication to authenticate against a web site"
2. "I want to use Windows Authentication to authenticate against a web site and then I want to be able to impersonate that user so I can access network resources"
3. "I want to run my web site under a linux account that comes from a domain via kerberos and let it talk to SQL as that account"

Or something else altogether.

One thing to note up front - it's extremely unlikely we'd implement NTLM, that protocol needs to die and since Win2k it's Kerberos anyway.

[blowdart]

We have not implemented scenario 3. It’s in the backlog for now. The sql team has ways to configure the Linux client for integrated auth but that’s for a machine account, not via a delegated identity.

…

________________________________ From: Niyam Shah <[email protected]> Sent: Friday, August 30, 2019 1:16:44 PM To: aspnet/AspNetCore <[email protected]> Cc: Barry Dorrans <[email protected]>; Mention <[email protected]> Subject: Re: [aspnet/AspNetCore] xplat Integrated Windows Authentication (ntlm/Kerberos) (#4662) @blowdart<https://github.com/blowdart> In the following comment that you posted, can you explain how to achieve the third scenario in asp.net core mvc 2.1? Basically I have a self-contained .net core mvc app deployed to linux and it needs to be able to connect to an SQL Server with integrated security, both the linux server and sql server being in a corporate intranet. Any help would be much appreciated! @evil-shrike<https://github.com/evil-shrike> when you say "Windows Authentication" what do you mean? Do you want 1. "I want to use Windows Authentication to authenticate against a web site" 2. "I want to use Windows Authentication to authenticate against a web site and then I want to be able to impersonate that user so I can access network resources" 3. "I want to run my web site under a linux account that comes from a domain via kerberos and let it talk to SQL as that account" Or something else altogether. One thing to note up front - it's extremely unlikely we'd implement NTLM, that protocol needs to die and since Win2k it's Kerberos anyway. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4662>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAGCNCWJW5X3UB6D2H3YUYDQHF52ZANCNFSM4GKCZW2Q>.

[nino96]

@blowdart Ah okay, thanks for the quick reply. Any article/page on configuring for a machine account as you mentioned? Might be helpful for figuring out a workaround

[blowdart]

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-auth-overview?view=sql-server-2017

[nino96]

@blowdart Thanks!

[danielleiszen]

Hi,

in my scenario the users log in from a Windows DC to their Windows OSs where they would use a browser based (TS) or desktop (.Net) client for accessing different services. The services and a central IdentityServer4 that issues the tokens and handles other authentication scenarios as well, runs in Linux based docker containers. My aim is to use SSO and authorize against the IdentityServer4 - LDAP using the already logged in Windows account for the user without prompting for user name and password. The IdentityServer4 is a linux based container - so I cannot use the documented and well known method.

Is this scenario possible with the mentioned NegotiateStream release?
There is not much documentation could anyone point me to the right direction with this?

Thank you

[Tratcher]

@danielleiszen the docs are here:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-3.0&tabs=visual-studio#kestrel

Little testing has been done in docker though. Let us know if the docs work for you.

[valorl]

@danielleiszen I'm not sure about the details of how IS4 does LDAP, but I'm assuming the requirement can essentially be reduced to having an ASP.NET Core (3.0) web service (your IS4) be capable to authenticate requests using Negotiate, while running in a Linux container.

As @Tratcher linked, since 3.0, Kestrel can do Negotiate in a Linux environment with the right prerequisites. These are basically:

• Having the Kerberos libs installed (e.g. krb5-user on debian)
• Having the right config (/etc/krb5.conf) for the libs
• Making sure there's always a valid Kerberos TGT available (by requesting/refreshing it using kinit and a keytab)

Setting this up is mostly explained in this article which is also linked in the Kestrel guide.

The issue when you want to do this from Docker, is that you essentially need to run 2 processes: your application and a process that keeps the TGT alive (using kinit). This is a bad practice to do in a container.

A better solution is to have a separate (sidecar) container running that keeps the TGT alive. Your app container and the sidecar container can then share the same Kerberos cache over e.g. a memory volume. Kubernetes helps here, as you can deploy a Pod with those two containers, which means the sidecar is isolated from other applications.

That being said, I would recommend using standard OAUTH and JWT if you can avoid using Kerberos as it adds a lot of complexity and is much harder to debug (the Kerberos mechanism is coupled to a lot of non-HTTP systems like AD and DNS).