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.
Bug 1527937 - mod_auth_gssapi does not work with gssproxy backend
Summary: mod_auth_gssapi does not work with gssproxy backend
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mod_auth_gssapi
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-20 14:07 UTC by Ondrej
Modified: 2018-03-08 22:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-08 22:16:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ondrej 2017-12-20 14:07:44 UTC 
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.
Comment 2 Ondrej 2017-12-20 14:58:00 UTC 
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
Comment 3 Robbie Harwood 2017-12-20 18:05:01 UTC 
rpm -qa | egrep 'krb5|gssproxy|mod_auth_gssapi'
Comment 4 Ondrej 2017-12-21 13:11:14 UTC 
HOME  100 > rpm -qa | egrep 'krb5|gssproxy|mod_auth_gssapi'
mod_auth_gssapi-1.5.1-2.el7.x86_64
krb5-workstation-1.15.1-8.el7.x86_64
gssproxy-0.7.0-4.el7.x86_64
sssd-krb5-1.14.0-43.el7_3.18.x86_64
krb5-libs-1.15.1-8.el7.x86_64
krb5-libs-1.15.1-8.el7.i686
sssd-krb5-common-1.14.0-43.el7_3.18.x86_64
Comment 5 Robbie Harwood 2018-01-09 23:19:31 UTC 
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.
Comment 6 Robbie Harwood 2018-03-07 16:35:53 UTC 
Hi, we've had beta out for a bit.  Is this still an issue for you in RHEL-7.5, or can we close this bug?
Comment 7 Ondrej 2018-03-08 09:01:43 UTC 
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?
Comment 8 Robbie Harwood 2018-03-08 22:16:28 UTC 
Yes, separate bug for that please.  Thanks!
Note You need to log in before you can comment on or make changes to this bug.