Followup on the referral discussion

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Followup on the referral discussion

Isaac Boukris
Hi Greg, all

Later last week, I had a call with metze in which he corrected me
about a couple of things I mentioned in our discussion. In short,
unlike what I said, referrals should always work in windows env, for
both forest and external trusts.

He also suggested that making assumption based on the name type, on
the client side is not correct, and that we should not override the
realm when requested but rather chase referrals to krbtgt/srealm and
then chase again referrals to server (and that could be made to work
with netbios realms, if canonicalize is set).

These two stages can easily be applied to cross-realm S4U2Self, just
s/srealm/icrealm, but not to RBCD as far as I can think of.

Isaac
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Followup on the referral discussion

Greg Hudson
On 12/21/19 2:37 PM, Isaac Boukris wrote:
> Later last week, I had a call with metze in which he corrected me
> about a couple of things I mentioned in our discussion. In short,
> unlike what I said, referrals should always work in windows env, for
> both forest and external trusts.

I can interpret this in two different ways, and I'm not sure which is meant:

1. For an external trust, the client has to be told the external realm,
but will then follow any referrals issued by that realm.

2. The local KDC knows how to issue referrals to external realms (how
does it decide which SPNs to do this for?), so the client doesn't behave
any differently than it would for a forest trust.

> He also suggested that making assumption based on the name type, on
> the client side is not correct, and that we should not override the
> realm when requested but rather chase referrals to krbtgt/srealm and
> then chase again referrals to server (and that could be made to work
> with netbios realms, if canonicalize is set).

"Chase referrals to krbtgt/srealm" means asking the local KDC for
krbtgt/srealm, and keep following the issued TGTs until we get there?
If so, that isn't actually a referrals chase in the sense of requiring
RFC 6806 extensions; following alternate TGTs to a realm is specified in
RFC 4120 section 3.3.3.  The second part (following referrals issued by
srealm for the server name) of course requires RFC 6806.

MIT krb5 implements the first part in a pretty complicated way, because
it is supposed to work if either the client or the KDC knows a path to
the specified realm (via [capaths] configuration).
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Followup on the referral discussion

Isaac Boukris
On Sun, Dec 22, 2019 at 8:32 AM Greg Hudson <[hidden email]> wrote:

>
> On 12/21/19 2:37 PM, Isaac Boukris wrote:
> > Later last week, I had a call with metze in which he corrected me
> > about a couple of things I mentioned in our discussion. In short,
> > unlike what I said, referrals should always work in windows env, for
> > both forest and external trusts.
>
> I can interpret this in two different ways, and I'm not sure which is meant:
>
> 1. For an external trust, the client has to be told the external realm,
> but will then follow any referrals issued by that realm.
>
> 2. The local KDC knows how to issue referrals to external realms (how
> does it decide which SPNs to do this for?), so the client doesn't behave
> any differently than it would for a forest trust.

The latter. To my understanding the KDC decides how to refer based on
spn suffix table negotiated at trust establishment (short spns for
instance can't be referred, and i think might be duplicated).

> > He also suggested that making assumption based on the name type, on
> > the client side is not correct, and that we should not override the
> > realm when requested but rather chase referrals to krbtgt/srealm and
> > then chase again referrals to server (and that could be made to work
> > with netbios realms, if canonicalize is set).
>
> "Chase referrals to krbtgt/srealm" means asking the local KDC for
> krbtgt/srealm, and keep following the issued TGTs until we get there?
> If so, that isn't actually a referrals chase in the sense of requiring
> RFC 6806 extensions; following alternate TGTs to a realm is specified in
> RFC 4120 section 3.3.3.  The second part (following referrals issued by
> srealm for the server name) of course requires RFC 6806.

Right, alternate TGTs.

> MIT krb5 implements the first part in a pretty complicated way, because
> it is supposed to work if either the client or the KDC knows a path to
> the specified realm (via [capaths] configuration).

Yeah, it is like MIT in that we only follow referrals, and respect in
a way the app requested realm.

I still can't think of a clean way to apply it to rbcd, say we follow
alternate TGTs to proxy realm (normally), then what do we do?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev