Configuring CUPID (Kerberos)



The Capriza User Proxy and Identification, herein referred to as CUPID, is an HTTP proxy for automatic Kerberos login of users into backend systems for a single sign on experience. It performs Simple and Protected Negotiation Mechanism SPNEGO with any service that supports it by way of protocol transition (S4U2Self) and user impersonation (S4U2Proxy).

How It Works


CUPID acts as a forward proxy between the browser and the accessed service. Every http/https call the browser makes goes through CUPID and CUPID makes the call to the service on behalf of the browser. For any http response other than 401, CUPID returns the response to the browser unchanged.



When CUPID detects an http response of 401 that specifies Negotiate as the required authentication scheme, it will kick in to perform the SPNEGO Kerberos negotiation instead of returning the response to the browser.   Once the SPENGO authentication is complete, it will return the final (and authenticated) response to the browser unchanged. Subsequent http calls flow through CUPID in a similar fashion.


CUPID uses the MIT Kerberos v5 implementation for all Kerberos ticket negotiations ( and requires access to a Key Distribution Center (KDC) for requesting tickets. It does not perform any type of querying against an LDAP or Active Directory.




  • CUPID MUST run under a domain user account that has been assigned “Constrained Delegation” privileges in Active Directory to the desired services.

  • In addition, any service that CUPID accesses, must also run under a domain user account in order for Cupid to properly perform Kerberos ticket negotiations using SPENGO.

  • A user must first login to Cupid before it can have Kerberos authentications automatically handled on its behalf.


Login to Cupid


CUPID login is performed by accessing http://<cupid>:7678/cupid/login and providing login credentials.  CUPID supports three types of logins. In all cases, CUPID contacts the KDC to perform the login and verify the user identity.

  1. Basic - the corporate username and password are sent via the regular “Basic” authentication header

  2. CUPID - a special authentication scheme similar to “Basic” but where the username and password are encrypted using a one-time generated secret key derived from an ECDH operation. This requires specifying a public/private EC pair in the CUPID configuration

  3. SPNEGO - no username and password are presented to CUPID, instead a Kerberos ticket is presented to Cupid via SPNEGO

Upon a successful login,  returns a JSON response containing a signed JSON Web Token (JWT - The JWT is signed using ECDSA P-256, and it contains the expiration stamp as returned by the KDC. The Kerberos ticket itself never leaves CUPID and is not part of the JWT.




Whenever CUPID needs to perform SPNEGO on behalf of a user when accessing a service (when it encounters a response with 401 status code and Negotiate as the required authentication scheme), it first validates the identity of the user by verifying the JWT presented to it.


The JWT MUST be sent to Cupid with every request as the value of the X-Cupid header.


Cupid will not perform SPNEGO if one of the following holds true:

  1. There is no JWT in the request

  2. The JWT signature verification fails

  3. The JWT has expired


Setup and Configuration


To run CUPID (referred to in the Setup & Configuration section as Cupid) under the account of a domain user with “Constrained Delegation”:

  1. Create a domain user account named cupid in Active Directory

  2. Set an HTTP SPN (Service Principal Name) for the cupid service under the cupid user account:

setspn -s http/<cupidfqdn>:7678 cupid

where <cupidfqdn> is the fully qualified domain name of the computer hosting cupid.

  1. Generate a keytab for the cupid service:

ktpass /princ http/<cupidfqdn>:7678@<DOMAIN> /mapuser cupid /pass <PASSWORD> /out cupid.keytab /crypto all /ptype KRB5_NT_PRINCIPAL

where <cupidfqdn> is the fully qualified domain name of the computer hosting cupid, <DOMAIN> is the domain under which the cupid user account is defined and <PASSWORD> is the password for the cupid user

  1. Copy the cupid.keytab file to the cupid host

  2. Edit the krb5.conf file and specify the full path to the cupid.keytab file:

default_keytab_name = FILE:/path/to/cupid.keytab default_client_keytab_name = FILE:/path/to/cupid.keytab

  1. Add “Constrained Delegation” privileges to the cupid user in Active Directory and assign it access to all of the required services
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Please sign in to leave a comment.