Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help with warning messages please #304

Open
rtresidd opened this issue Apr 30, 2024 · 5 comments
Open

Help with warning messages please #304

rtresidd opened this issue Apr 30, 2024 · 5 comments

Comments

@rtresidd
Copy link

I'm using gssapi to authenticate access to a viewvc instance and I'm getting these warnings in the logs.

[auth_gssapi:warn] [pid 14398:tid 14439] [client xxx.xxx.xxx.xxx:52682] Subrequest authentication bypass on location with different configuration!

This is the apache config file for viewvc:


ScriptAlias /viewvc /var/www/viewvc-1.3.0/bin/cgi/viewvc.cgi

<Directory /var/www/viewvc-1.3.0>
SSLOptions +StrictRequire
SSLRequireSSL
SSLRequire ( %{HTTP_HOST} eq "domain.com.au" )
ErrorDocument 403 https://domain.com.au/viewvc
SSLVerifyClient require

AuthType GSSAPI
AuthName "GSSAPI Login"
GssapiBasicAuth On
GssapiNegotiateOnce on

Require valid-user

Options +ExecCGI
AddHandler cgi-script .cgi


I believe I've also seen another error that is a few lines further down in the mod_auth_gssapi.c code
"Failed to lookup env table in subrequest"

I'm just not sure what the root cause of these errors is?
What is the Main Request vs Sub request in these cases

These are what the requests look like in ssl_request_log:


[30/Apr/2024:12:54:33 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /viewvc/docroot/scripts.js HTTP/1.1" 401 381 0 2
[30/Apr/2024:12:54:33 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /viewvc/docroot/scripts.js HTTP/1.1" 200 49 0 3
[30/Apr/2024:12:54:33 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /favicon.ico HTTP/1.1" 401 381 0 4
[30/Apr/2024:12:54:34 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /favicon.ico HTTP/1.1" 404 196 0 5


There is always a 401 followed by a 200 or 404 depending on the outcome
I think the 401 is due to Firefox being setup to use the MIT Kerberos tool for SSO. So I think it fails login before trying that each time for some reason..

@simo5
Copy link
Contributor

simo5 commented May 2, 2024

Browsers do not know how to do opportunistic authentication or how to remember that a directory is protected by authentication to do so.

Whenever you have a resource protect by GSSAPI the request will come with no Authorization token, and GSSAPI will send back a 401 with a Negotiate Header, at which point the broswer understand SPNEGO/GSSAPI is required and fetches a ticket (if it doesn't have one yet) from the KDC and then sends an init context token in an Authorization header back to the same URL.

On the second time the GSSAPI module can read the token and authenticate the request returning a 200 for existing underlying resources or a 404 when the resource is not found.

Because of this browser sillyiness, what most people do is to have a dedicated login page (say /login.html) and they only protect that page via GSSAPI.
That page will do this dance, but only once, the result of the dance will be a secure cookie sent back to the browser that carry temporary authorization and that is used to authenticate access to all other pages.

If the cookie is not present the Error Document is customarily resolved to a redirect to the login page so authentication can be perfomed once, and that pages redirects back to the refferal page.

mod_auth_gssapi can be configure to handle some of this automatically (ie without a special redirect page) via direct use of Session Cookies, see the Gssapi[Use]Session[Key] directives, requires installation of mod_session.

@rtresidd
Copy link
Author

rtresidd commented May 3, 2024

Hi Simo
Thankyou for your detailed reply, I'll have to look into that session option a bit more.
I hadn't noticed this behaviour when we had previously basic auth.

I'm still wondering about these two mostly:
[Thu May 02 15:02:15.174826 2024] [auth_gssapi:warn] [pid 26562:tid 26714] [client <ip_addr>:52178] Subrequest authentication bypass on location with different configuration! referer: https:///viewvc
[Thu May 02 15:02:15.174893 2024] [auth_gssapi:warn] [pid 26562:tid 26714] [client XXX.XXX.XXX.XXX:52178] Failed to lookup env table in subrequest

The "Subrequest" line repeats for every different path viewed in viewvc.
I can imagine that is maybe referring to the Kerberos token being used again at a different path level? but I don't get the "location with different configuration!" part or how to fix that or even if I need to?

And I'm not sure how to fix the "Failed to lookup env table" one either.

Thanks for your help and have a great weekend
Cheers
Richard

@simo5
Copy link
Contributor

simo5 commented May 3, 2024

Sorry but these are all Apache Httpd questions, not mod_auth_gssapi ones.
The only thing I know is that mod_auth_gssapi can't really re-authenticate on sub-requestes, but I rarely encountered them and couldn't find clear docs on when to expect them.

The location thing just means you have some configuration both in a <Directory> statement and a <Location> statement that change the same endpoint and Httpd is complaining about that.

I suggest you use either Directory or Location and not mix the two. Generally Location is the more flexible option.

HTH.

@rtresidd
Copy link
Author

rtresidd commented May 6, 2024

Hi Simo
Thanks and no probs I'll pop over to an apache forum and ask, just thought given the [auth_gssapi:warn] on each log line they were related to mod_auth_gssapi.
Yep I thought that location with different config related to that, but I can't see anywhere else in the configs were I have the things different for that path.. it's all under the one directory tag.. I'll keep looking though.

Cheers
Richard

@simo5
Copy link
Contributor

simo5 commented May 6, 2024

If it turns out mod_auth_gssapi is doing something wrong, please let me know, I am happy to address any deficiencies in it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants