RFR 8005819: Support cross-realm MSSFU

[Michael Osipov]

Am 2019-10-31 um 21:40 schrieb Martin Balao:
> Hi Michael,
> 
> Thanks for having a look at this proposal.
> 
> On 10/29/19 12:35 PM, Osipov, Michael wrote:
>> * In handleS4U2ProxyReferral():
>>> +        sname = new PrincipalName(PrincipalName.KRB_NT_PRINCIPAL,
>>> +                sname.getNameStrings(), sname.getRealm());
>>
>> Why do you use here KRB_NT_PRINCIPAL? Is that the assumption that in AD
>> all services are bound to regular accounts compared to MIT Kerberos?
>>
> 
> The backend PrincipalName is constructed from a string, so we really
> don't know the type and KRB_NT_UNKNOWN is used. I've not found any issue
> in my tests with KRB_NT_PRINCIPAL but it should look less arbitrary to
> keep KRB_NT_UNKNOWN. I'll do some more testing and change it if there
> are no issues.
> 
>> client1 at REALM => HTTP/host at REALM where HTTP/host at REALM is bound to
>> srv$@REALM => postgres/host2 at REALM and the transition is done with
>> srv$@REALM?
>>
> 
> I'm not sure of what you mean here. Can you please elaborate a bit more?

Yes, sure. The spot just made we wonder. My understanding for S4U2self 
(my knowledge is limited to the AD KDC, may be different in MIT 
Kerberos). You may or may not sign onto a service with Kerberos, the 
service (HTTP/host at REALM) knows your UPN (client1 at REALM). Now the 
service wants to connect to a PostgreSQL DB with your credentials by 
using S4U2self and then S4U2proxy. Since the SPN HTTP/host at REALM is 
bound to either a machine account (server1$@REALM) or service account 
(service at REALM) you have to impersonate with that account and not with 
the SPN, then as soon as you have the TGT, you can request the sevice 
ticket for the target service.
The confusion was 'sname' combined with 'PrincipalName.KRB_NT_PRINCIPAL'.

Hope this helps to understand.

Michael