Confusion about delegation

John Byrne jhnbyrn at
Fri Feb 1 14:54:39 EST 2019

Thanks, this helps a lot.

I think the reason it appeared to be working for me when I used the wrong
name HTTP/ is because I incorrectly had that principal in
the keytab of the other service. An in the second case, where I omitted the
creds altogether, you are correct, it just authenticated as HTTP/ and not kerbtestjohn.

So, I have set ok_to_auth_as_delegate in my KDC for the intermediate
service principal HTTP/, but now I'm getting this error on
the step() call:

Feb 01 14:47:14 localhost.localdomain krb5kdc[6376](info): TGS_REQ (8
etypes {18 17 20 19 16 23 25 26}) NOT_ALLOWED_TO_DELEGATE:
authtime 0,  HTTP/ at EXAMPLE.COM for HTTP/ at EXAMPLE.COM, Plugin does not support the operation

I couldn't find any info on this, but I did some reading in the source code
and it looks like the necessary function 'check_allowed_to_delegate' is
only defined for the ldap plugin. Have I got that right - I have to use
ldap to get this feature to work with the krb5 server? Or is there another

Thanks again for the info on this!


On Fri, Feb 1, 2019 at 12:26 PM Greg Hudson <ghudson at> wrote:

> On 1/31/19 1:32 PM, John Byrne wrote:
> > The client_ctx.step() call returns this error: gssapi.raw.misc.GSSError:
> > Major (851968): Unspecified GSS failure.  Minor code may provide more
> > information, Minor (2529639053): Matching credential not found
> This is a bad error message, and we have an open ticket noting the need
> to improve it:
> Because you haven't set the ok_to_auth_as_delegate bit on
> HTTP/, the KDC issues a non-forwardable service ticket in
> the creds.impersonate() step.  The GSSAPI layer stores this as a regular
> cred object containing a user -> HTTP/ service ticket,
> not an impersonator cred.  Such a credential can be interrogated for
> name attributes to get PAC information (if it came from a KDC supporting
> PACs) or to authenticate to the intermediate service itself, but it
> can't be used to authenticate to any other service.
> When gss_init_sec_context() tries to authenticate with this credential,
> it can't find either a client -> target or client -> krbtgt/REALM
> credential, so it fails with the uninformative error message.
> Release 1.16 added the ability to query a credential for whether it is
> an impersonator credential, as noted in the documentation page you
> referenced.
> > I've made sure that the target_name principal is in the default keytab
> Only the target service should have a target_name keytab entry.  Giving
> out that keytab to other parties poses a security issue, allowing those
> parties to impersonate (in the attacker sense, not the S4U2Proxy sense)
> the target service.
> > The surprising thing is that if I initialize the context with the other
> > name instead (HTTP/, then this code works perfectly, and
> > authenticates me as 'kerbtestjohn' to
> I would expect this to authenticate from kerbtestjohn to
> HTTP/  How would it authenticate to if
> you didn't ask gss_init_sec_context() to do so?
> > Even stranger, if I omit the proxy_creds from the
> > SecurityContext, then it also works, using either of the 2 service names.
> > So I can impersonate users without the proxy creds!? Shouldn't that be
> > rejected?
> If you omit proxy_creds, then it should authenticate from whatever
> client is in the default ccache (probably HTTP/ to the
> target service.  It shouldn't authenticate as krbtestjohn.

More information about the Kerberos mailing list