Limitations

• Back-side Kerberos SSO with standard KCD only works if the following resources are within the same Active Directory domain:
• System user
• Kerberos user
• Back-end service

Airlock Gateway 7.3 and newer supports RBKCD (Resource Based Kerberos Constrained Delegation) which allows having these resources within different Active Directory domains. The configuration for RBKCD is described in the cross-domain setup.

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.

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.