1

My customer requires SSO in Windows domain for my Linux-based web/application server. Server have its own keytab installed and it all does work fine. Windows domain (EXAMPLE.ORG) have a service user account with SPN HTTP/server.example.org associated. My application server (WildFly) require Kerberos authentication and deny NTLM authentication.

I have test domain (2016-based) which was created with default settings. I am trying to repeat this setup in test domain and I can't make Kerberos work. I see negotiation request from server, but client always return NTLM ticket.

WWW-Authenticate: Negotiate                 (request)
Authorization: Negotiate TlRMTVNTU.....     (reply)

In customer infrastructure I see the same with Kerberos ticket

WWW-Authenticate: Negotiate                 (request)
Authorization: Negotiate YIIHmAYGKw....     (reply)

The only difference (besides GPO) that I see is that my SPN is not inside same DNS domain. My AD domain is tdm.sample.org and server is server.sample.org, I don't know if that matters.

A while ago I had same problem within domain too. Both IE client and Windows Server 2016 with IIS joined in same domain were using NTLM too.

I believe there are few GPO settings regulating how client may or may not authorize, but none of documents I've read helped.

Is there any clear description what restrictions Kerberos client authentication have or any hint or debugging strategy that can be applied?

kab00m
  • 498
  • 3
  • 10
  • Not sure if we can determine why your client is sending an NTLM token right out of the gate. In a straight Windows environment it's actually hard to not at least *attempt* a Kerberos authentication. Sometimes too many group memberships/too small a token size can cause failures but that shouldn't be a problem for a vanilla test environment. You can try maxing the token size out to 64k to test. http://woshub.com/kerberos-token-size-and-issues-of-its-growth/ – Greg Askew Dec 23 '22 at 18:51
  • Your IIS example is actually pretty good and worth a test. Put up a simple IIS web site and require authentication and see what the Edge browser sends it for the 401 challenge. That would be simpler than the keytab with Linux. – Greg Askew Dec 23 '22 at 18:58
  • It was SPN issue. SPN should point to PTR record of the server, not the name you point browser at. – kab00m Dec 24 '22 at 11:18
  • For IIS issue it was non-domain name was used. – kab00m Dec 24 '22 at 11:33

1 Answers1

0

There are several restrictions when Windows do not even attempt Kerberos authorization.

1. SPN point to PTR, not web alias

If your non-domain-member webserver have an alias you have no need to assign SPN on that alias. It would be checked against real DNS record of that server.

Let's say you have this:

A record server.example.org -> 10.0.0.1
PTR record 10.0.0.1 -> server.example.org
CNAME record webapp.example.org -> server.example.org

Accessing webapp.example.org you do not need SPN HTTP/webapp.example.org, you should assign HTTP/server.example.org to the service record ONLY. I believe it should be an IP address if there is no PTR record as well.

2. Domain members should NOT be called by any other name.

I have a domain member server with IIS and Windows Integrated Authentication enabled. Due to my network setup it has DNS setup in both non-domain and domain network:

srv.example.org -> 10.0.0.1
10.0.0.1 -> srv.example.org

And it also registered in domain:

srv.tdm.example.org -> 10.0.0.1

This server would not allow Kerberos if being accessed as srv.example.org, Kerberos will work only if it is been accessed as srv.tdm.example.org. It even will not work if it is accessed via IP address.

I guess the nature of this fact caused by windows name resolution in domain which usually happens before DNS.

I will continue searching and will update this answer.

kab00m
  • 498
  • 3
  • 10