curl：如何在 Windows 上使用 Kerberos 而不是 NTLM 身份验证？

Question

I'm trying to connect to a Livy REST service under Kerberos security. On Linux CentoS curl works fine with negotiate , after receiving a Kerberos kinit ticket the connection through

curl --negotiate -u : http://service_link

The problem I'm facing is trying to do the same on remote Windows desktop. I'm using MIT Kerberos for Windows, which is able to do a successful kinit . However, curl seems to be negotiating using the NTLM SSL tickets instead of Kerberos, which results in the following error:

AuthenticationFilter: Authentication exception: org.apache.hadoop.security.authentication.client.AuthenticationException

I've tried using the official curl release for windows , having these features ( curl --version ):

Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy

and the gow 0.8.0 version of curl :

Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SPNEGO SSL SSPI libz

Both of these use NTLM SLL when negotiating.

Question: Is there a way to force using Kerberos instead of NTLM? Is it possible to debug the Negotiator to see whether (and where) it is looking for Kerberos (and possibly not seeing) tickets?

Concerning the Kerberos, it seems to be storing the keytabs on its api, so I've set the KRB5CCNAME environment variable to API:Initial default ccache ; klist is able to see the ticket, however, maybe curl needs additional specification?

Also -- are there alternative methods to curl for such connection with Kerberos security?

Answer 1

http://service_link is a silly URL for Kerberos. As that is a single label name, a client will only look for the service ticket in its default Realm. It is best to use and FQDN so that the host can be parsed and the domain portion be matched to a realm.

Also, there is no mention of an SPN in your post. If curl can guess the right KDC to talk to, you need the SPN HTTP/service_link registered on the account that runs auth on your web server.

Finally, have you used Fiddler or the like to confirm that your web server is sending back the WWW-Authenticate:negotiate header ? curl does have proxy settings.

You can't force Kerberos if all the settings aren't right. IF they are right, curl will try it first and succeed. Depending on what is wrong, it may try Kerb and then revert to NTLM.

Answer 2

The name of the service, and its consequent SPN is critical to understanding Kerberos AUTH, and can be quite tricky. To understand the issue, you should understand that the Challenge that comes back from the Web server (or a Proxy) is essentially "I like Kerberos, GIVE ME A TICKET" ... The Web server offers no hint as to what Tickets it would be prepared to accept, nor does it tell the client how to obtain a suitable one.

So the Client needs to work out the name of the service (the SPN that is expected), and it then needs a Kerberos configuration that tells it how to obtain suitable tickets (if not from its local Kerberos Domain).

So for a Client accessing http://www.github.com/ the SPN would be HTTP/www.github.com but the client first needs to check that name to see how it resolves. Its actualy a CNAME that resolves via github.com then the actual SPN would be HTTP/github.com - and then the Client needs to check its Kerberos configuration to see if the name is in a foreign Kerberos Domain (which adds extra complications). For the Local kerberos domain, the client will present the krbtgt/ @ to its local Kerberos Ticket Granting service, requesting a ticket for the SPN HTTP/github.com @ <LOCAL_DOMAIN>.

Provided that SPN is registered in the Local Kerberos Ticket Granting service, then it will issue the Ticket, and the Client will present it to the Web site. The Website will accept it , provided it has the correct SPN, and the correct issuing Domain.

If the Web service you connected to is actually a local fake of github.com, and accepts tickets from your Local domain then this could work. But for a Website outside your own local environment, the added complications of a Foreign Kerberos domain, configurtaion and Trust relationship would come into play.

Even in your local environment, the Client needs to be able to derive the correct SPN from the name used to access the target resource, and the SPN needs to be registered and associated with the Webservice (so that it can decrypt the Kerberos tickets when they are presented).