Perhaps this is a bug. Gss_init_sec_context did return GSS_S_COMPLETE for me.
-Original Message-
From: Greg Hudson [ghud...@mit.edumailto:ghud...@mit.edu]
Sent: Wednesday, October 08, 2014 11:10 PM Eastern Standard Time
To: Xie, Hugh; Kerberos@mit.edu
Subject: Re: Not getting delegation
On 10/09/2014 07:12 AM, Xie, Hugh wrote:
Perhaps this is a bug. Gss_init_sec_context did return GSS_S_COMPLETE
for me.
I don't think we have a bug such that gss_inquire_context on an
established context would return GSS_S_NO_CONTEXT, no; that would show
up in our automated tests. Make sure
Found the issue. It is order the function calls that matters:
Here is the order of call that produced the error:
1. gss_init_sec_context
2. gss_release_cred on the deleted_cred_handle (passed to #1 call)
3. gss_release_cred on output_token
4. gss_inquire_context
If I switch the order to either
Correction. #3 is gss_release_buffer on output_token.
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Thursday, October 09, 2014 1:45 PM
To: Greg Hudson; 'Kerberos@mit.edu'
Subject: RE: Not getting delegation credential
hi,
When implementing rsyslog with gssapi
(http://www.rsyslog.com/doc/gssapi.html) I came accross the issue
that the rsyslog software expects the credentials cache of the host
principal in /tmp/krb5cc_0; the centos 6.5 hosts joined to a freeipa
kerberos domain save that to /var/tmp/host_0 .
I
Natxo Asenjo natxo.ase...@gmail.com writes:
When implementing rsyslog with gssapi
(http://www.rsyslog.com/doc/gssapi.html) I came accross the issue
that the rsyslog software expects the credentials cache of the host
principal in /tmp/krb5cc_0; the centos 6.5 hosts joined to a freeipa
On Thu, 2014-10-09 at 23:10 +0200, Natxo Asenjo wrote:
hi,
When implementing rsyslog with gssapi
(http://www.rsyslog.com/doc/gssapi.html) I came accross the issue
that the rsyslog software expects the credentials cache of the host
principal in /tmp/krb5cc_0; the centos 6.5 hosts joined to
