Limitations

After successful authentication, Airlock IAM instructs Airlock Gateway through the Control API for which Kerberos user a Kerberos ticket must be requested, in order to propagate to the back-end server.

• The following rule applies to the Identity Propagator configuration in Airlock IAM:
• Only one Kerberos user without a Mapping name set is allowed per Airlock Gateway session.
• As many as required Mapping-specific Kerberos users can be set.

Resource-Based Kerberos Constrained Delegation (RBKCD) allows propagating users' identity from one domain to a Back-end in another domain. Airlock Gateway uses a privileged system user to do that. In theory, there are many possible combinations in which domain these three identities (user, Back-end service and system user) could be members of. Nevertheless, not all combinations are possible because of restrictions within Active Directory. The simplified explanation below explains the possibilities:

If the system user and the Back-end server are not in the same forest, then the impersonated user must be from the same forest as the system user. In other words, the Active Directory domain controller would not allow a system user from another forest to impersonate users from its own forest.

The mentioning on the website (Microsoft) Updates to TGT delegation across incoming trusts in Windows Server underlines this restriction:
Applications that rely on round-trip authentication across trusts are not supported by using constrained delegation. For example, a delegation fails if a user in Forest A authenticates to an application in Forest B and the application in Forest B is trying to delegate a ticket back to Forest A.

Windows does not allow by default Kerberos delegation for system administrators. For security reasons, domain administrators should be flagged as sensitive and therefore will not be able to use this propagation. Make sure that the authenticating user is not a member of the administration group.

Kerberized web applications are most probably deployed in Microsoft’s IIS. Nevertheless, it is also possible to have non-Microsoft web servers that understand Kerberos as an authentication scheme. The documentation here describes how to integrate Microsoft’s IIS. As this is the most common scenario, non-Microsoft web servers are not described and not tested, but we expect that they work as well.