Use Curl with Kerberos Negotiate Authentication

This article explains how to use the curl command-line tool to authenticate against a web server using the Kerberos and SPNEGO (Negotiate) protocols. You will learn how to acquire a Kerberos ticket, construct the correct curl command, and use the necessary flags to successfully authenticate and troubleshoot your connection.

Step 1: Acquire a Kerberos Ticket

Before using curl with Kerberos, you must have a active Kerberos ticket on your local machine. curl relies on your system’s underlying GSS-API (Generic Security Services Application Program Interface) to handle the cryptographic handshake, meaning it cannot generate a ticket itself.

To obtain a ticket, open your terminal and run the kinit command followed by your Kerberos principal (username):

kinit username@YOUR-REALM.COM

You will be prompted to enter your password. Once authenticated, verify that you have a valid active ticket by running:

klist

Step 2: Run the Curl Command

Once you have a valid Kerberos ticket in your credentials cache, you can make an HTTP request to the protected server. To enable Kerberos authentication, use the --negotiate flag along with the -u flag.

The standard syntax is:

curl --negotiate -u : http://your-secure-server.com/api

Key Parameter Breakdown:

• --negotiate: This flag tells curl to use the GSS-Negotiate (SPNEGO) security method.
• -u :: The user option is required for authentication, but by leaving the username and password blank (separated by just a colon), you instruct curl to automatically retrieve the credentials from your local Kerberos ticket cache.

Step 3: Handling Redirections and Cookies

In many enterprise environments, Kerberos authentication is followed by a redirect or session creation using cookies. If the server requires session persistence, include the -b (cookie input) and -c (cookie output) flags, and allow redirects with -L:

curl --negotiate -u : -b cookies.txt -c cookies.txt -L http://your-secure-server.com/api

Troubleshooting Common Issues

If your request fails, you can debug the Kerberos handshake by adding the verbose flag (-v or --verbose):

curl -v --negotiate -u : http://your-secure-server.com/api

During a successful handshake, look for the following headers in the verbose output: 1. Server response: WWW-Authenticate: Negotiate (The server states it supports Kerberos). 2. Client response: Authorization: Negotiate YII... (The client sends the base64-encoded Kerberos token). 3. Server response: HTTP/1.1 200 OK (Authentication succeeded).

Common Errors: * 401 Unauthorized: Ensure your Kerberos ticket hasn’t expired (klist) and that you are using the exact Fully Qualified Domain Name (FQDN) of the server. Kerberos authentication often fails if you use an IP address instead of the domain name. * Could not resolve host: Ensure your system is pointed to the correct DNS server that can resolve both the target server and the Kerberos Key Distribution Center (KDC).