Windows authentication in linux docker container

Question

i am trying to use windows authentication in linux docker container under kubernetes.

I am following this settings: https://docs.microsoft.com/en-us/aspnet/core/secu

Answer 1

In dotnet runtime git they tell us that gss-ntlmssp is required for this to work even that it is not mentioned anyhow in the aspnet core documentation.

The 'gss-ntlmssp' package is a plug-in for supporting the NTLM protocol for the GSS-API. It supports both raw NTLM protocol as well as NTLM being used as the fallback from Kerberos to NTLM when 'Negotiate' (SPNEGO protocol) is being used. Ref: https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-SPNG/f377a379-c24f-4a0f-a3eb-0d835389e28a

From reading the discussion above and the image you posted, it appears that the application is trying to actually use NTLM instead of Kerberos. You can tell because the based64 encoded token starts with "T" instead of "Y".

ASP.NET Core server (Kestrel) does NOT support NTLM server-side on Linux at all. It only provides for 'Www-Authenticate: Negotiate' to be sent back to clients. And usually that means that Kerberos would be used. Negotiate can fall back to using NTLM. However, that doesn't work in ASP.NET Core except in .NET 5 which has not shipped yet.

Are you expecting your application to fall back to NTLM? If not, then perhaps the Kerberos environment is not completely set up. This can be caused by a variety of issues including the SPNs and Linux keytab files not being correct. It can also be caused by the client trying to use a username/password that is not part of the Kerberos realm.

This problem is being discussed here: https://github.com/dotnet/aspnetcore/issues/19397

I recommend the conversation continue in the aspnet core repo issue discussion.

Answer 2

This article is a good example of misunderstanding how things work. I don't recommend to follow the way(like I did) author described here at all .

Instead, I would recommend learning about Kerberos authentication, how it works, what settings it requires. This article visualizes it good.

First, If you profile http traffic coming from browser(user Fiddler, for example) you can find a TGS token in the second request.

• If it starts with Negotiate TlR then you're doing auth over NTLM.
• If it starts with Negotiate YII then you're doing auth over Kerberos.

Second, Like David said before ASP.NET Core 3.1 doesn't support NTLM on Linux at all. So if you have TlR token and ntlm-gssapi mechanism you will get "No credentials were supplied, or the credentials were unavailable or inaccessible." error. If you have TlR token and use default Kerberos mechanism you will get "An unsupported mechanism was requested."

Next, The only way to get your app works well is to create SPNs and generate keytab correctly for Kerberos authentication. Unfortunately, this is not documented well. So, I gonna give an example here to make things more clear.

Let's say you have:

• AD domain MYDOMAIN.COM
• The web application with host webapp.webservicedomain.com. This can ends with mydomain.com, but not in my case.
• Windows machine joined to AD with name mymachine.
• Machine account MYDOMAIN\mymachine

Regarding the instructions described here you need to do:

1. Add new web service SPNs to the machine account:

• setspn -S HTTP/webapp.webservicedomain.com mymachine
• setspn -S HTTP/webapp@MYDOMAIN.COM mymachine

2. Use ktpass to generate a keytab file

• ktpass -princ HTTP/webapp.webservicedomain.com@MYDOMAIN.COM -pass myKeyTabFilePassword -mapuser MYDOMAIN\mymachine$ -pType KRB5_NT_PRINCIPAL -out c:\temp\mymachine.HTTP.keytab -crypto AES256-SHA1*.

*Make sure MYDOMAIN\mymachine has AES256-SHA1 allowed in AD.

Finally, After making all above things done and deploying the app into Linux container with keytab the Integrated Windows Authentication is supposed to worked well. My experiment showed you can use keytab wherever you want not only on the host with name "mymachine".