Server not found in Kerberos database

[Eimert]

Hi, running curl with active Kerberos ticket (klist) in verbose mode (-v) gives:

..
< HTTP/1.1 401 Unauthorized
..
* gss_init_sec_context() failed : Server not found in Kerberos database
..

This is the active config:

location /slash/ {
  proxy_pass https://other.domain.name/api/;
  auth_gss on;
  auth_gss_keytab /etc/krb5.keytab;
}

After running kdestroy -A the error changes into:

* gss_init_sec_context() failed : No Kerberos credentials available (default cache: KEYRING:persistent:0)

My impression is that the directive auth_gss_keytab /etc/krb5.keytab; seems to be ignored. It seems that the default active cache (klist) is being used. The keytab file contains the HTTP principal.

Any advice what goes wrong here? Your input is highly appreciated.

[hawicz]

When curl says Server not found in Kerberos database you should believe it. That means that whatever service name curl is trying to use isn't known by your KDC. Nothing you do in nginx will affect that because you're not even getting far enough to do any of the gssapi negotiation with the web server.

[Eimert]

How to find the service name being used? I've got error logs on debug.

How to influence the server name being used by curl with nginx proxy_pass?

Executing a curl request to the upstream server directly gives 200 OK, so that works.

[Eimert]

Hi, found the service name being used by enabling Kerberos trace logging: export krb5_trace=/dev/stderr.

The service name on the failed request differs from the successful request; using Nginx with proxy_pass.

Is there a difference between the machines registered in KDC and AD? Should this machine be added to AD?

For completeness, here's the debug error log:

[root@machine ~]# tail -7 /var/log/nginx/error.log
2022/06/02 16:37:28 [debug] 16580#16580: *5 SSO auth handling IN: token.len=0, head=0, ret=401
2022/06/02 16:37:28 [debug] 16580#16580: *5 Begin auth
2022/06/02 16:37:28 [debug] 16580#16580: *5 Detect basic auth
2022/06/02 16:37:28 [debug] 16580#16580: *5 Detect SPNEGO token
2022/06/02 16:37:28 [debug] 16580#16580: *5 SSO auth handling OUT: token.len=0, head=1, ret=401
2022/06/02 16:37:29 [info] 16580#16580: *5 client 10.36.130.226 closed keepalive connection