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.
Description of problem:
If I do not specify GssapiCredStore in for of:
...
GssapiCredStore keytab:/etc/httpd/httpd.keytab
...
I am no longer able to authenticate via Kerberos.
If I comment the line above out, then with GSSProxy enabled apache complains this way:
[Wed Dec 20 13:53:09.350617 2017] [auth_gssapi:error] [pid 14860] [client 192.168.60.181:61213] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ((null))]
With GSSProxy Disabled it complains this way:
[Wed Dec 20 14:00:47.834423 2017] [auth_gssapi:error] [pid 15985] [client 192.168.60.181:61339] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information (Keytab FILE:/etc/krb5.keytab is nonexistent or empty)]
---> most likely because only root can access /etc/krb5.keytab
When I uncomment the GssapiCredStore settings above, it works in both cases OK.
Version-Release number of selected component (if applicable):
latest
How reproducible:
always
Expected results:
I would expect that with GssProxy enabled, mod_auth_gssapi does not need direct access to to the kerberos keytab.
Looks like this is not a problem with gssproxy as krb_trace show:
[23572] 1513781631.357063: Retrieving HTTP/carney.dublin.s3group.com.S3GROUP.COM -> Encrypted/Credentials/v1@X-GSSPROXY: from KEYRING:persistent:348:348 with result: 0/Success
Awesome, thanks. I think this should be fixed in the 7.5 release. (You can get an idea of what this will look like from the Fedora version. Unfortunately due to needed changes in dependencies I can't just give you a test RPM.) In the event that it's not we'll revisit it then, of course.
Tried, works for me. Great!
Just a small hitch - when I specify a certain debug level for gssproxy, it still says (level: 0):
● gssproxy.service - GSSAPI Proxy Daemon
Loaded: loaded (/etc/systemd/system/gssproxy.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2018-03-08 08:28:39 GMT; 5s ago
Process: 42751 ExecStart=/usr/sbin/gssproxy -D -d --debug-level=2 (code=exited, status=0/SUCCESS)
Main PID: 42752 (gssproxy)
CGroup: /system.slice/gssproxy.service
└─42752 /usr/sbin/gssproxy -D -d --debug-level=2
Mar 08 08:28:39 carney systemd[1]: Starting GSSAPI Proxy Daemon...
Mar 08 08:28:39 carney gssproxy[42751]: [2018/03/08 08:28:39]: Debug Enabled (level: 0)
Mar 08 08:28:39 carney systemd[1]: Started GSSAPI Proxy Daemon.
Also, the option --debug-level is not mentioned in the man page for gssproxy. Shall I open a separate bugzilla for it?
Description of problem: If I do not specify GssapiCredStore in for of: ... GssapiCredStore keytab:/etc/httpd/httpd.keytab ... I am no longer able to authenticate via Kerberos. If I comment the line above out, then with GSSProxy enabled apache complains this way: [Wed Dec 20 13:53:09.350617 2017] [auth_gssapi:error] [pid 14860] [client 192.168.60.181:61213] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ((null))] With GSSProxy Disabled it complains this way: [Wed Dec 20 14:00:47.834423 2017] [auth_gssapi:error] [pid 15985] [client 192.168.60.181:61339] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information (Keytab FILE:/etc/krb5.keytab is nonexistent or empty)] ---> most likely because only root can access /etc/krb5.keytab When I uncomment the GssapiCredStore settings above, it works in both cases OK. Version-Release number of selected component (if applicable): latest How reproducible: always Expected results: I would expect that with GssProxy enabled, mod_auth_gssapi does not need direct access to to the kerberos keytab.