CODEWITHSUNDEEP
javaspringsecuritytomcatkerberos
Olga D
Olga D

Reputation: 11

Is SPNEGO/GSS-API required for Kerberos or "WWW-Authenticate: Negotiate" is enough?

I am trying to implement Kerberos authentication. I have windows server with ad, windows client and application server with tomcat and Spring.

The problem is I got NTLM ticket instead of kerberos.

On applicatin server side I just return 401 with "WWW-Authenticate: Negotiate". Is it enough to force windows client choose Kerberos and the problem of NTLM somewhere on windows client/ windows server with ad configuration?

Or using SPNEGO or GSS-APi is required for getting Kerberos token?

I can't cofigure application server as in this tutorial https://docs.spring.io/spring-security-kerberos/docs/current/reference/htmlsingle/.

We do not use web dependency, just spring security and custom authentication/authorization logic. We have some authorization providers (Basic, LDAP and Kerberos has to be next), if one accepts - user authorized. Also there is no way to use SPNEGO filter or any other Filter. Only AbstractPhaseInterceptor and InterceptionProvider.

I tried cofigure tomcat with krb5.conf, krb5.ini adding spnego.jar to libs with no affect.

Upvotes: 1

Views: 1342

Answers (1)

grawity_u1686
grawity_u1686

Reputation: 16532

Well, "WWW-Authenticate: Negotiate" literally means SPNEGO will be used for authentication – on the server side, you're supposed to validate the token using a SPNEGO implementation. (And when SPNEGO validates a Kerberos ticket, it always does that via GSS-API, even if that stays internal to the implementation.)

However, it all starts on the client side – Windows on the client machine requests a token specifying SPNEGO as the mechanism, and the mechanism decides whether to attempt Kerberos first, or whether to try NTLM.

If the client starts by sending an NTLM token instead of Kerberos, that is not because of a missing header – instead it usually means it has failed to obtain a Kerberos ticket for HTTP/<fqdn>, e.g. because you haven't registered a SPN for the server within Active Directory. (You would normally have done this as part of creating the service account or keytab which Tomcat/Spring needs to actually validate the Kerberos tickets.)

Test from Windows clients using klist get HTTP/<fqdn> (the FQDN must exactly match the name that's in the URL – note that IP addresses will not work).

Upvotes: 0

Related Questions