S4U2self and one-way trusts

[Rick van Rein]

Hello Sundeep,

Singh, Sundeep wrote:
> I have a test setup where DOMAINA trusts DOMAINB. Server1 exists in DOMAINA, and user1 exists in DOMAINB. Given the direction of the trust, it should be possible to get a service ticket for Server1 for user1.

Agreed.  I don't know about Windows, but this is how trust on Kerberos
is designed.

> >From the TRACE calls in the Kerberos library when S4U2self functionality is triggered on Server1 for user1, Server1 attempts to get a TGT to DOMAINB by using the principal "krbtgt\DOMAINB at DOMAINA". This request is sent to the KDC for DOMAINA. My understanding is that this krbtgt account will not exist for this one-way trust, and the request fails with "server not found in Kerberos database" in my setup.

S4U2Self is a pretty special extension, let's begin with that, and it
was added later/independently AFAIK.

When your user contacts the service (and with S4U2Self that probably
uses some other mechanism), the server must somehow obtain a Kerberos
identity for that user.  It sounds reasonable to me that it needs to
contact the user's realm for that purpose, and so it builds up the
connection by requesting the crossover ticket.

This is where S4U2Self is a bit "upside down" relative to how trust was
designed.  Normally, the client would do the work; it finds that it
needs to contact the server in the other realm and requests
krbtgt/DOMAINA at DOMAINB which is supported by the trust setting that you
describe.  But turn it upside-down by letting the service connect to the
user, and I am not surprised to hear that you (also) need the opposite
direction.

> So, is S4U2self expected to work in a one-way trust scenario? If so, what should be the principal for the TGS request to get the TGT to the user's realm?

I didn't know, but I'm not surprised by your findings that it doesn't
work in your one-way trust setup.  Nature of the beast, I suppose.

-Rick