Lighttpd

Please have a look in the code where that error message is emitted:
https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/mod_authn_gssapi.c#L397
The call to gss_accept_sec_context() (from the kerberos library) fills in acc_flags

Disclaimer: I haven't looked at the kerberos-specific code for years, and I do not have a Kerberos realm set up in which to test.

The original commit of mod_authn_gssapi.c is in https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/1c1a63786eebd509674e445a0db3307ffa3e284c and the commit message says:

    [mod_auth] mod_authn_gssapi Kerberos auth backend (fixes #1899)

    module status: experimental; more testing and review needed

    Kerberos library calls have been preserved from original patch set
    and should be reviewed.

    module has been quickly tested with Basic auth (Use over TLS!)

    SPNEGO -has not- been tested.  Again, kerberos library calls have
    been preserved from original patch set.  YMMV. (Use over TLS!)

    x-ref:
      "Kerberos/GSSAPI Delegation Support" 
      https://redmine.lighttpd.net/issues/1899

As the commit from 2016 states, SPNEGO has not been tested. If you're willing and able to assist, maybe we can get that working.

I am willing to help test and get something working. It says that "module has been quickly tested with Basic auth" but that "SPNEGO has not been tested". Do I need to change my configuration to not use SPNEGO? My config looks like:

server.modules += ( "mod_authn_gssapi" )
auth.backend = "gssapi" 
auth.backend.gssapi.keytab = "/etc/lighttpd/lighttpd.keytab" 
auth.backend.gssapi.principal = "HTTP/XXX@XXX" 

auth.require = ( "" =>
                 (
                 # method must be either basic or digest
                   "method"    => "gssapi",
                   "realm"     => "test",
                   "require"   => "valid-user" 
                 )
               )

It says that "module has been quickly tested with Basic auth" but that "SPNEGO has not been tested".

I am not sure what is unclear there.

For comparison, have you tested with "method" => "basic" ?

I tried with `"method" => "basic"` and I am still prompted for username/password in Edge/Chrome but I do not see the "No confidentiality for user" message in the log.

Switching back to "method" => "gssapi", to see if things work without the confidentiality test, you can try testing with this patch, which skips the check for GSS_C_CONF_FLAG:

--- a/src/mod_authn_gssapi.c
+++ b/src/mod_authn_gssapi.c
@@ -411,10 +411,12 @@ static handler_t mod_authn_gssapi_check_spnego(request_st * const r, plugin_data
         goto end;
     }

+#if 0
     if (!(acc_flags & GSS_C_CONF_FLAG)) {
         log_error(r->conf.errh, __FILE__, __LINE__, "No confidentiality for user: %s", (char *)token_out.value);
         goto end;
     }
+#endif

     /* check the allow-rules */
     if (!http_auth_match_rules(require, token_out.value, NULL, NULL)) {

I do not understand why GSS_C_CONF_FLAG is checked in the patch contributed in #1899 for lighttpd 1.4.32 (https://raw.githubusercontent.com/GrayTShirt/phoenix-overlay/master/www-servers/lighttpd/files/lighttpd-1.4.32-gssapi.patch) since GSSAPI is used for authentication and not for message transport; lighttpd mod_authn_gssapi never uses gss_unwrap(). Therefore, I plan to remove the check for GSS_C_CONF_FLAG if you test the above patch successfully with "method" => "gssapi"

Does this mean that I will need to recompile the entire lighttpd from source? If so, are there a recommended set of configure options? I haven't compiled lightttpd from source before.

Please see InstallFromSource.

You need not run the install step to be able to run lighttpd for testing.

To run lighttpd in the foreground from the source tree:
cd src; ./lighttpd -D -f /etc/lighttpd/lighttpd.conf -m $PWD/.libs
(Ctrl-C to stop)

I did the steps and now it fails here:

 log_error(r->conf.errh, __FILE__, __LINE__, "Unable to delegate credentials for user: %s", (char *)token_out.value);

If I comment out the following if check block for the store_creds then the rest of the gssapi auth works as expected and the AD username is logged in the access logs. Can we get these changes pushed into the main branch so it will be resolved in the next release?

 if (p->conf.auth_gssapi_store_creds) {

If I comment out the following if check block for the store_creds then the rest of the gssapi auth works as expected

If you do not need to store creds (e.g. for use by CGI), then you should not store creds. Configure lighttpd.conf with:
auth.backend.gssapi.store-creds = "disable"

Can you please elaborate on that? I do not need the creds for CGI but I want to pass the creds as a header in X-REMOTE-USER to a backend service running on the machine. My use case is to use lighttpd as a proxy that performs Windows authentication and then passes the user credentials to a backend service. Does that require the store-creds flag to be set to enable or disable?

I do not need the creds for CGI but I want to pass the creds as a header in X-REMOTE-USER to a backend service running on the machine.

X-REMOTE-USER is not Kerberos credentials. Your X-REMOTE-USER is simply a label of the username. Since you do not need the Kerberos creds, please add auth.backend.gssapi.store-creds = "disable" to your lighttpd.conf.

lighttpd mod_auth provides REMOTE_USER in the environment for successfully authenticated requests, but REMOTE_USER is not added to the HTTP request headers sent to backend by mod_proxy. To include REMOTE_USER in HTTP request headers sent to the backend, you can use mod_proxy proxy.forwarded with "remote_user" if your backend understands RFC 7239 Forwarded. Alternatively, you can set REMOTE_USER from env into request header X-REMOTE-USER using mod_magnet and few lines of Lua.

I can confirm that setting store-creds = "disable" resolved the second issue. At this point I think the only change that needs to be pushed upstream is the change to disable the check for GSS_C_CONF_FLAG

FYI: Five days ago, I changed the Status of this issue to "Patch Pending" and Target version: 1.4.66, and posted

..., I plan to remove the check for GSS_C_CONF_FLAG if you test the above patch successfully with "method" => "gssapi"

Thank you for testing the change and confirming the desired behavior.

You are welcome. Thank you for assisting me through it. Any idea when the next version will be released?

Any idea when the next version will be released?

Likely in the next week or two -- by mid-Aug -- since I want to get fixes out for #3160, #3161, and #3164