How to use LdapSdk to delegate existing kerberos ticket to LdapConnection bind?

[gredwhite]

I have the following architecture:

• Samba(AD)
• Web App (it sends requests to Samba) which is spring boot 3 application
• Client

Client sends Kerberos ticket to web application and SpnegoAuthenticationProcessingFilter can handle it.

I've read about AD feature called Unconstrained delegation

Unconstrained delegation is a feature in Active Directory that allows a computer, service, or user to impersonate any other user and access resources on their behalf across the entire network, completely unrestricted.

And I need exactly that. I want user which login initially

• Send requests to webapp with kerberos ticket
• Webapp takes kerberos ticket and create LdapConnection( using existing kerberos ticket to make a bind).

I see the class GSSAPIBindRequest:
https://docs.ldap.com/ldap-sdk/docs/javadoc/com/unboundid/ldap/sdk/GSSAPIBindRequest.html

But in example it uses username and password.

So my question is: Is there way to delegate existing ticket to LdapConnection ?

[dirmgr]

I’m far from an expert on Kerberos, and especially on Active Directory’s usage of it. However, my best guess is that this could probably be accomplished in one of two ways:

• Through the use of a ticket cache. If a client already has a valid Kerberos session on the system, then the ticket from that existing session could be reused without the need for separate authentication. The GSSAPIBindRequestProperties class provides methods for indicating whether you want to use a ticket cache, whether to require the use of a cached ticket instead of creating a new authentication session, and the path to the ticket cache file to use.

• Through the use of an alternative authorization identity. When authenticating via GSSAPI, you need to specify the Kerberos principal (that is, the authentication identity) for the user that is authenticating, but you can also specify an optional authorization identity. If specified, then the authorization identity indicates that although the connection is authenticated as one user, requests should be authorized as if they had been requested by a different user.

If it is one of these two things, then I’d certainly hope that it’s the second one rather than the former, since the first one has absolutely horrific security implications if the initial Kerberos session is created by a remote client, and there can be many such sessions active at the same time. The second option, in which the requester has to actually authenticate as themselves before they can authorize requests as someone else, seems like the far more secure option.

I don’t believe that Active Directory supports anything like the proxied authorization mechanism described in RFC 4370 that is used by more traditional LDAP servers to specify an alternative authorization identity on a per-request basis.

[gredwhite]

Well it is hard for me now.

Now I have an instance of KerberosTicketValidation

It has method

getDelegationCredential

I suppose that I have to pass it to unboundId somewhere.

Could you please give me any peace of advice ?

[gredwhite]

If it is one of these two things, then I’d certainly hope that it’s the second one rather than the former, since the first one has absolutely horrific security implications if the initial Kerberos session is created by a remote client, and there can be many such sessions active at the same time.

Actually exactly the first option is desired by business

[gredwhite]

@dirmgr any ideas ?

[dirmgr]

I’m not really an expert with GSSAPI, and I’ve only ever used it to authenticate against the MIT Kerberos daemon on Linux and Solaris. However, the LDAP SDK’s implementation is really just a wrapper around the JVM’s GSSAPI support, so as long as Microsoft’s implementation is standards-compliant and supported by the JVM, then it should work. The LDAP SDK exposes a fairly extensive set of properties with regard to the GSSAPI-related options that the JVM provides, so it may be a matter of finding the right set of properties.

In general, the approach that I would recommend would be to have an account that your web application uses to authenticate itself to the LDAP server, and then to use the authorization identity to have operations requested after that bind processed as if they had been requested by the target user.

For the account that you use to authenticate to the LDAP server, you can obtain the credentials in one of three ways:

• You can provide a password for the account.
• You can use a keytab file that contains the credentials.
• You can require the account to already have a valid Kerberos session on the system, and to use the ticket cache.

Note that these options aren’t necessarily mutually exclusive. For example, you can use the ticket cache to authenticate with an existing session, but then fall back to a password or keytab if there isn’t a valid session available. This is probably the best of both worlds.

If it turns out that the end users authenticating to the web application are actually getting valid Kerberos sessions on the host system that is also the LDAP client, and you want to authenticate directly as that user without an intermediate account, then that would almost certainly require using the ticket cache.

[gredwhite]

I’m not really an expert with GSSAPI, and I’ve only ever used it to authenticate against the MIT Kerberos daemon on Linux and Solaris. However, the LDAP SDK’s implementation is really just a wrapper around the JVM’s GSSAPI support, so as long as Microsoft’s implementation is standards-compliant and supported by the JVM, then it should work. The LDAP SDK exposes a fairly extensive set of properties with regard to the GSSAPI-related options that the JVM provides, so it may be a matter of finding the right set of properties.

In general, the approach that I would recommend would be to have an account that your web application uses to authenticate itself to the LDAP server, and then to use the authorization identity to have operations requested after that bind processed as if they had been requested by the target user.

For the account that you use to authenticate to the LDAP server, you can obtain the credentials in one of three ways:

• You can provide a password for the account.
• You can use a keytab file that contains the credentials.
• You can require the account to already have a valid Kerberos session on the system, and to use the ticket cache.

Note that these options aren’t necessarily mutually exclusive. For example, you can use the ticket cache to authenticate with an existing session, but then fall back to a password or keytab if there isn’t a valid session available. This is probably the best of both worlds.

If it turns out that the end users authenticating to the web application are actually getting valid Kerberos sessions on the host system that is also the LDAP client, and you want to authenticate directly as that user without an intermediate account, then that would almost certainly require using the ticket cache.

For now I have no idea how to extract ticket from HTTP request and put it to the ticket cache. Do you have any idea about that suff ?

[dirmgr]

My only (limited) experience with GSSAPI and Kerberos has been in conjunction with LDAP, so I have no idea how it would work for an HTTP client. I do know that in LDAP, a typical GSSAPI authentication process needs three round trips between the client and the server, so I assume that there would be a similar requirement for clients using other protocols.

At any rate, GSSAPI authentication in LDAP doesn’t directly take the Kerberos ticket as input. As I understand it, you either need to leverage an existing session already established on the system, or you establish a new session by providing the necessary credentials to do so. But that’s all done behind the scenes by the JVM’s underlying GSSAPI implementation, so I don’t know the specifics.