I try to implement unconstrained delegation in my spring boot application. Based on the article:

Client sends 2 tickets to the web server: TGT + TGS(service ticket)

I've configured wireshark to check network traffic and I see the following:

How many tickets are where ? How can I check ?

In spring In debug I see the following:

In AD service account is configure in that way:

So my question are:

1. How many tickers are in request ?

if there are 2: please point me out to them. And how to accept them on server side ?

if there is 1: How should I add one more ticket ?

UPDATE

klist result is:

I try to implement unconstrained delegation in my spring boot application. Based on the article:

Client sends 2 tickets to the web server: TGT + TGS(service ticket)

I've configured wireshark to check network traffic and I see the following:

How many tickets are where ? How can I check ?

In spring In debug I see the following:

In AD service account is configure in that way:

So my question are:

1. How many tickers are in request ?

if there are 2: please point me out to them. And how to accept them on server side ?

if there is 1: How should I add one more ticket ?

UPDATE

klist result is:

• java
• active-directory
• kerberos
• kerberos-delegation
• spring-security-kerberos

1 Answer 1

How many tickets are where ? How can I check ?

There is always one ticket (the service ticket) under ap-req > ticket. It's sent in the clear, but always paired with a one-time authenticator that proves the client knows the session key.

When delegation is enabled, the second ticket (delegated) is stored within the encrypted area of that authenticator, under ap-req > authenticator > cipher > authenticator > cksum > krb-cred.

How many tickers are in request ?

Impossible to tell from the screenshot.

if there are 2: please point me out to them. And how to accept them on server side ?

It should be automatically stored as part of the server's (acceptor's) GSSContext. That seems to be happening here and here.

if there is 1: How should I add one more ticket ?

In HTTP, at least as far as I understand it, the client needs to perform delegation proactively (since only one step is possible for GSSAPI so the server can't request it).

1. The client's klist needs to show a TGT that is forwardable.

   Also, the user principal needs to not have any KDC-side restrictions. For example, Domain Admins on Windows might have the "This account is sensitive and cannot be delegated" flag set on them.

2. If the HTTP service ticket happens to be cached in klist, then it should show the ok_as_delegate flag, corresponding to "Trust this user for delegation[...]".

   Windows and some other clients require that flag (treating it as admin-set policy), other clients ignore that flag and always delegate if configured; e.g. a Java client could use requestDelegPolicy().

3. The HTTP client needs to be configured to do delegation.

   In Firefox, network.negotiate-auth.delegation-uris would be set to https:// for example or to .example (or a combination) to make the browser initiate delegation. (Make sure you don't make the 'delegation' list too broad; it should only allow a few specific hosts.)

   With curl you would specify curl --negotiate --delegation always or --delegation policy (doesn't work for me on Windows, but does work on Linux).

   If you were making a custom HTTP client in Java, I think you would call .requestCredDeleg(true) on the GSSContext object before getting a token.