ASP.NET hosted on CentOS 7 with Windows authentication - GSSAPI: Feature not available

[lbalusek]

Hello,

we have ASP.NET backend server running on .NET 5, its hosted on CentOS 7 and we have some issues with Windows AD authentication.

We have followed this tutorial, meaning that we have added AddAuthentication + AddNegotiate and UseAuthentication to our Startup.cs, host machine - CentOS 7 is in domain, we have also set the KRB5_KTNAME, it points to the existing keytab file, which we have generated on the domain controller.

When i use command kinit username@DOMAIN.COMPANY.COM and then fill out my password, everything seems to be ok, i also see some ticket, when i invoke klist command.

But for some reason, our ASP.NET server is unable to authenticate me, when i open its url in a browser, fill out my credentials, i get the following error:
2021-06-21 07:51:55.4321|ERROR|Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler|An exception occurred while processing the authentication request. Interop+NetSecurityNative+GssApiException: GSSAPI operation failed with error - Unspecified GSS failure. Minor code may provide more information (Feature not available).

I have completely no idea what this error means and i am unable to google any meaningful results, do you have any ideas?
Thank you!

I have also posted this question on StackOverflow

[Tratcher]

@wfurt?

[Tratcher]

Check out #19397 for more information and debugging steps.

[wfurt]

what exactly do you type as user @lbalusek? Do you use whole domain that exist in KRB5 config? And is the keytab really readable by the server? I think part of the mystery is to figure out if the server can talk to KDC or not.

Note that .NET will throw if user/password is invalid on Linux dotnet/runtime#416
That may cover cases when wrong/unexpected SPN is generated.

And there is very old dotnet/runtime#16576 that may be applicable.

The issue @Tratcher linked has lot of chatter about NTLM. For now, I'll assume that is not applicable.
To move forward I would suggest to enable .NET tracing and possibly set KRB5_TRACE=/dev/stdout before starting server and verify basic assumptions about SPN being used for authentication and ability of the server to talk to KDC.

Unfortunately, I don't think there is any easy answer.

[lbalusek]

Hello, sorry for the delay, i was doing a little research related to this issue.
I have tried it again on clean machine and i have got error GSSAPI operation failed with error - An unsupported mechanism was requested. which i have previously solved by installing gssntlmssp package. Could it be possible that it uses NTLM instead of Kerberos?
Another thing i have found out is that guys from our IT department probably forgot to call setspn commands mentioned in this tutorial, and if i am not mistaken, these commands should somehow enforce use of Kerberos, am i right?

[Tratcher]

If kerberos fails (due to missing spns) then negotiate tries to fall back to ntlm and hits these errors.

[lbalusek]

Glad to hear that, we will try to fix spns on the domain controller and try it again, i will let you know. For now, thank you both for your help.

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.