Thanks, this helps a lot.
I think the reason it appeared to be working for me when I used the wrong
name HTTP/www.example.com 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/
www.example.com and not kerbtestjohn.
So, I have set ok_to_auth_as_delegate in my KDC for the intermediate
service principal HTTP/www.example.com, 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}) 192.168.0.22: NOT_ALLOWED_TO_DELEGATE:
authtime 0, HTTP/www.example....@example.com for HTTP/
datastore.example....@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
way?
Thanks again for the info on this!
-John
On Fri, Feb 1, 2019 at 12:26 PM Greg Hudson <ghud...@mit.edu> 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:
>
> http://krbdev.mit.edu/rt/Ticket/Display.html?id=8586
>
> Because you haven't set the ok_to_auth_as_delegate bit on
> HTTP/www.example.com, 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/www.example.com 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/www.example.com), then this code works perfectly, and
> > authenticates me as 'kerbtestjohn' to www.datastore.com.
>
> I would expect this to authenticate from kerbtestjohn to
> HTTP/www.example.com. How would it authenticate to www.datastore.com 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/www.example.com) to the
> target service. It shouldn't authenticate as krbtestjohn.
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
