Bug 1527937
| Summary: | mod_auth_gssapi does not work with gssproxy backend | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ondrej <ondrej.valousek> |
| Component: | mod_auth_gssapi | Assignee: | Robbie Harwood <rharwood> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | karol.kania, ondrej.valousek, pasik |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-03-08 22:16:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 rpm -qa | egrep 'krb5|gssproxy|mod_auth_gssapi' 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 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. 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? 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?
Yes, separate bug for that please. Thanks! |
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.