Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJoseph C. Sible
2020-01-03 18:01:51 UTC
Description of problem:
When using mod_auth_gssapi with Negotiate, GssapiLocalName and gssproxy, authentication fails.
Version-Release number of selected component (if applicable):
mod_auth_gssapi 1.6.1-6.el8
gssproxy 0.8.0-14.el8
How reproducible:
always
Steps to Reproduce:
1. Set up gssproxy, with configuration like this:
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = 48
krb5_principal = HTTP
2. Set up httpd and mod_auth_gssapi, with configuration like this:
AuthType GSSAPI
AuthName "Login"
GssapiCredStore keytab:/etc/krb5.keytab
GssapiLocalName On
GssapiBasicAuth On
Require valid-user
3. Create /etc/systemd/system/httpd.service with this content:
.include /usr/lib/systemd/system/httpd.service
[Service]
Environment=GSS_USE_PROXY=1
4. Try to connect with a browser with Negotiate authentication
Actual results:
I get a 401 error, and a message like this appears in error_log:
[Fri Jan 03 12:35:22.497355 2020] [auth_gssapi:error] [pid xxx:xxx] [client xxx:xxx] GSS ERROR gss_localname() failed: [A required input parameter could not be read (Unknown error)]
Expected results:
I expect authentication to succeed.
Additional info:
This problem only occurs because all of gssproxy, GssapiLocalName, and Negotiate authentication are in use. If I do any one of the following, then it will work:
1. Unset GSS_USE_PROXY, and give Apache permission to read the keytab directly
2. Set "GssapiLocalName Off"
3. Connect with HTTP Basic authentication
Also, it's unrelated to SELinux, as it happens even with it in permissive mode.
To test that fix myself, I got our SRPM and added the patch to it. Two oddities I noticed in the process:
1. mod_auth_gssapi has a build dependency on gssntlmssp-devel, which seems to be missing from the RHEL 8 repos. I worked around that by building gssntlmssp from source, which produced the -devel package.
2. The patch said it was fixing a regression from 9c555e2, but the changes from that commit weren't in the current version of the RHEL RPM. (And in fact, I needed to take the 9c555e2 patch first, or this new patch wouldn't apply.)
Unfortunately, it didn't work for me. With the new mod_auth_gssapi RPM I built, I still have the same problem.
I also thought the issue might be with something else that was fixed upstream, so I tried 1.6.2 straight from upstream without involving an RPM at all, but it also still has the problem on my system.
Sounds like I misdiagnosed the problem, sorry.
Is GSS-proxy always integral to the problem?
Have you tried GssapiLocalName On but gssproxy off
and
gssproxy enabled but GssapiLocalName Off
do any of these combinations work?
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (mod_auth_gssapi bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:7534
Description of problem: When using mod_auth_gssapi with Negotiate, GssapiLocalName and gssproxy, authentication fails. Version-Release number of selected component (if applicable): mod_auth_gssapi 1.6.1-6.el8 gssproxy 0.8.0-14.el8 How reproducible: always Steps to Reproduce: 1. Set up gssproxy, with configuration like this: [service/HTTP] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U euid = 48 krb5_principal = HTTP 2. Set up httpd and mod_auth_gssapi, with configuration like this: AuthType GSSAPI AuthName "Login" GssapiCredStore keytab:/etc/krb5.keytab GssapiLocalName On GssapiBasicAuth On Require valid-user 3. Create /etc/systemd/system/httpd.service with this content: .include /usr/lib/systemd/system/httpd.service [Service] Environment=GSS_USE_PROXY=1 4. Try to connect with a browser with Negotiate authentication Actual results: I get a 401 error, and a message like this appears in error_log: [Fri Jan 03 12:35:22.497355 2020] [auth_gssapi:error] [pid xxx:xxx] [client xxx:xxx] GSS ERROR gss_localname() failed: [A required input parameter could not be read (Unknown error)] Expected results: I expect authentication to succeed. Additional info: This problem only occurs because all of gssproxy, GssapiLocalName, and Negotiate authentication are in use. If I do any one of the following, then it will work: 1. Unset GSS_USE_PROXY, and give Apache permission to read the keytab directly 2. Set "GssapiLocalName Off" 3. Connect with HTTP Basic authentication Also, it's unrelated to SELinux, as it happens even with it in permissive mode.