Bug 1285012 - Fix multiple keys in keytab
Fix multiple keys in keytab
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gssproxy (Show other bugs)
Unspecified Unspecified
low Severity medium
: rc
: ---
Assigned To: Robbie Harwood
Abhijeet Kasurde
Depends On:
  Show dependency treegraph
Reported: 2015-11-24 11:33 EST by Ondrej
Modified: 2017-08-01 16:55 EDT (History)
8 users (show)

See Also:
Fixed In Version: gssproxy-0.6.2-4.el7
Doc Type: Bug Fix
Doc Text:
Cause: krb5_principal option is not implemented. Consequence: When multiple keys are present in a keytab, gssproxy will use the first which breaks some applications. Fix: krb5_principal has been implemented to match existing documentation. Result: Multiple keys in keytab works as expected.
Story Points: ---
Clone Of:
Last Closed: 2017-08-01 16:55:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
console.log (4.25 KB, text/plain)
2017-06-01 06:24 EDT, Abhijeet Kasurde
no flags Details

  None (edit)
Description Ondrej 2015-11-24 11:33:14 EST
Description of problem:
Unable to use ldapsearch -Y GSSAPI to obtain TGT based on machine credentials via gssproxy

How reproducible:

Steps to Reproduce:
1. join machine to AD domain using "net ads join" command, storing machine credentials in /etc/krb5.keytab

2. Configure GSSPROXY to impersonate user trying to run ldapsearch:

   mechs = krb5
   debug = yes
   krb5_principal = MYHOST$@EXAMPLE.COM
   cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
   cred_store = keytab:/etc/krb5.test.keytab
   cred_usage = initiate
   euid = 1000

3. Use ldapsearch:
bash$ export GSS_USE_PROXY=yes
bash$ ldapsearch -h dcduba.dublin.ad.s3group.com
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
	additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (No Kerberos credentials available)

Actual results:
ldapsearch fails

Expected results:
ldapsearch should succeed

Additional info:
running 'gssproxy -i -d' does not provide enough debug information to troubleshoot the problem
Comment 1 Ondrej 2015-11-25 06:05:57 EST
Update: it starts to work if I replace:

   cred_store = keytab:/etc/krb5.test.keytab
   cred_store = client_keytab:/etc/krb5.test.keytab

Also note that krb5_principal parameter is still being ignored, i.e. if keytab also contains SPNs, it is quite a big chance it won't work.

Can we fix it?
Comment 2 Robbie Harwood 2016-04-22 12:24:39 EDT
Fixed merged upstream.
Comment 3 Ondrej 2016-05-06 09:23:31 EDT
Ok, will the fix be available in RHEL7 at some stage, too?
Comment 4 Robbie Harwood 2016-05-06 14:03:23 EDT
(In reply to Ondrej from comment #3)
> Ok, will the fix be available in RHEL7 at some stage, too?

Hopefully.  We're not sure when yet.
Comment 8 Kaleem 2016-09-21 01:30:33 EDT
krb5_principal option still not working, hence marking as FailedQA.

[root@dhcp207-130 ~]# rpm -q gssproxy
[root@dhcp207-130 ~]# 

Please find the attached file for verification steps with console output for reference.
Comment 12 Abhijeet Kasurde 2017-06-01 06:23:25 EDT
Verified using gssproxy :: gssproxy-0.7.0-3.el7.x86_64

Marking BZ as verified. See attachment for console.log.
Comment 13 Abhijeet Kasurde 2017-06-01 06:24 EDT
Created attachment 1284111 [details]
Comment 14 errata-xmlrpc 2017-08-01 16:55:26 EDT
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, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.