Returning 403 after successful negotiate

[evanfrey2]

Not sure what is going on here. I have debugged until I am blue in the face.

nginx.conf entry

  location /{
       root   /html;
       index  index.html;
       auth_basic off;
       auth_gss on;
       auth_gss_keytab /etc/nginx/svckerberos2.keytab;
       auth_gss_allow_basic_fallback off;
   }

/html and /html/index.html are both owned by the nginx user. Daemon is running as the nginx user. Perms are 777 for both dir and file (i was at the end of my rope...).

With auth_gss off; I get a 200 with the file data returned as expected. With auth_gss on;, I get a 403. When I debug kerb I see

[17746] 1739912414.529003: ccselect module realm chose cache KCM:0 with client principal **USERNAME**@**REALM** for server principal HTTP/**HOSTNAME**.ad.centivacapital.com@**REALM**
[17746] 1739912414.529004: Getting credentials **USERNAME**@**REALM** -> HTTP/**HOSTNAME**@ using ccache KCM:0
[17746] 1739912414.529005: Retrieving**USERNAME**@**REALM** -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found
[17746] 1739912414.529006: Retrieving **USERNAME**@**REALM** -> HTTP/**HOSTNAME**@ from KCM:0 with result: -1765328243/Matching credential not found
[17746] 1739912414.529007: Retrying **USERNAME**@**REALM** -> HTTP/**HOSTNAME**@**REALM** with result: -1765328243/Matching credential not found
[17746] 1739912414.529008: Retrieving **USERNAME**@**REALM** -> krbtgt/**REALM**@**REALM** from KCM:0 with result: 0/Success
[17746] 1739912414.529009: Starting with TGT for client realm: **USERNAME**@**REALM** -> krbtgt/**REALM**@**REALM**
[17746] 1739912414.529010: Requesting tickets for HTTP/**HOSTNAME**@**REALM**, referrals on
[17746] 1739912414.529011: Generated subkey for TGS request: aes256-cts/2E58
[17746] 1739912414.529012: etypes requested in TGS request: aes256-sha2, aes128-sha2, aes256-cts, aes128-cts
[17746] 1739912414.529014: Encoding request body and padata into FAST request
[17746] 1739912414.529015: Sending request (4047 bytes) to **REALM**
[17746] 1739912414.529016: Initiating TCP connection to stream 10.22.134.14:88
[17746] 1739912414.529017: Sending TCP request to stream 10.22.134.14:88
[17746] 1739912414.529018: Received answer (4024 bytes) from stream 10.22.134.14:88
[17746] 1739912414.529019: Terminating TCP connection to stream 10.22.134.14:88
[17746] 1739912414.529020: Response was from primary KDC
[17746] 1739912414.529021: Decoding FAST response
[17746] 1739912414.529022: FAST reply key: aes256-cts/15E1
[17746] 1739912414.529023: TGS reply is for **USERNAME**@**REALM** -> HTTP/**HOSTNAME**@**REALM** with session key aes256-cts/B226
[17746] 1739912414.529024: TGS request result: 0/Success
[17746] 1739912414.529025: Received creds for desired service HTTP/**HOSTNAME**@**REALM**
[17746] 1739912414.529026: Storing **USERNAME**@**REALM** -> HTTP/**HOSTNAME**@ in KCM:0
[17746] 1739912414.529027: Creating authenticator for **USERNAME**@**REALM** -> HTTP/**HOSTNAME**@, seqnum 24440067, subkey aes256-cts/711C, session key aes256-cts/B226

furthermore, I can see the ticket in my cache

Ticket cache: KCM:0
Default principal: **USERNAME**@**REALM**

Valid starting       Expires              Service principal
02/18/2025 16:00:13  02/19/2025 02:00:13  krbtgt/**REALM**@**REALM**
        renew until 02/25/2025 16:00:10
02/18/2025 16:00:14  02/19/2025 02:00:13  HTTP/**HOSTNAME**@
        renew until 02/25/2025 16:00:10
        Ticket server: HTTP/**HOSTNAME**@**REALM**

• Without a TGT I get a 401 Unauthorized (as expected
• With a TGT I get a 403 Forbidden
• With auth_gss turned off I get a 200 and the expected data

Strace looked normal, except when getting to the end when nginx returns the 403.

At a loss, hoping someone can shed some light on this...

[hawicz]

Does nginx's access log show the authenticated principal?
Perhaps the keytab doesn't contain a key for the spn of the token you're sending? I suggest checking what's there with klist -k or ktutil, or even try to manually feed the negotiate header from the request into the gss-token cli.