S4U2self and one-way trusts

[Singh, Sundeep]

Hi,

I am trying to test S4U2self with one-way trusts between Windows domains and seem to be running into an issue.

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.
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?

Regards,
Sundeep

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Singh, Sundeep]

Hi,

I am trying to test S4U2self with one-way trusts and seem to be running into an issue.

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.
In fact, the krbtgt account that would exist on both domains is is krbtgt\***@DOMAINB (when DOMAINA trusts DOMAINB).

So two questions:

1. Is S4U2self expected to work in a one-way trust scenario?

2. If so, shouldn't the TGT request for the foreign realm for S4U2self be for krbtgt\***@DOMAINB?

Regards,
Sundeep
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Rick van Rein]

Hello Sundeep,

Post by Singh, Sundeep
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.
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/***@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.

Post by Singh, Sundeep
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
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev