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@REALM => HTTP/host@REALM where HTTP/host@REALM is bound to
srv$@REALM => postgres/host2@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@REALM) knows your UPN (client1@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@REALM is
bound to either a machine account (server1$@REALM) or service account
(service@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
