LDAP Certificate Identity Providers

This section explains how to configure AppGate ZTNA to work with LDAP(AD) Certificate identity providers (IdPs).

AppGate ZTNA supports certificate authentication through standard enterprise IdPs such as Active Directory (Entra ID). Authentication is supported for Windows, macOS, and Linux Clients. Authentication is not supported for administrators using the admin UI.

Use the Identity Providers UI to configure LDAP.

By specifying more than one LDAP server, AppGate ZTNA will choose one at random. This provides LDAP load balancing and failover capability.

Prerequisites

It is strongly recommended that your LDAP server is configured for encrypted communication. If SSL is enabled and the LDAP server has a valid certificate, the Controller will automatically establish an encrypted session with the directory server. A separate integration guide is available to assist with setting this up.

Configuration

Shortening lookup times

If the system is configured to be reliant on AD group memberships, then it is strongly recommended to perform an audit of both user and machine group memberships well in advance of deployment, and clean up the structure to suit this new use case. The system has a powerful policy assignment capability which can be used to simplify the number of groups used in a directory.

Look up times are critical. The Controller will give up waiting for a reply after five seconds and move on to the next LDAP server if several have been specified (10 seconds in the case only one is configured). In the case of the headless client, they are programmed to keep trying to sign in until they succeed. If you have a large estate of headless (which includes always-on), then this can start to bombard the Controllers with sign-in requests further compounding any issues you might have with the directory servers.

To mitigate this situation it is important to fully configure the IdP, taking advantage of the Base DN, Membership Filter, and Membership Base DN fields. If these are not used then all searches will span the entire directory tree.

• Base DN should be used to define the part of the LDAP tree that includes all users. It might also include the groups that users belong to. The smaller this is, the better.

• Membership Base DN should be used to define the part of the LDAP tree that includes the groups that users belong to. This will be used in a subsequent call by the Controller to identify the groups that an authenticated user belongs to.

  • If nothing is defined then the Base DN will be used.

    • If the Base DN does not include the groups (only the users) then the member of record will be taken from the user record, so it will include only the exact groups defined there. The user record might show just 'sweden-sales'. There is no information there showing that 'sweden-sales' is part of 'sales' which is part of 'commercial'.

    • If the Base DN does include the users and groups, then the member of record will be taken from the groups records and show the user in 'sweden-sales', 'sales', and 'commercial'.

The use of Membership Base DN allows Base DN to be minimized (shortening search times), while also allowing for the separate Membership Base DN to be used for the group search. This ensures all relevant groups are returned from further up the tree. Its use has the additional advantage of minimizing the span of the second group search.

The span of the second group search can be further restricted by using the Membership Filter. Any filter added here will be concatenated with the assumed search base and used in the subsequent call by the Controller to identify the groups.

The following is an example of an LDAP configuration:

Use of multiple IdPs

The use of multiple IdPs can minimize look-up times. If you have two different classes of users (human users with full clients and headless clients), then you can create two different IdPs and use different Base DN, Membership Filter, and/or Membership Base DN against an optimized tree structure. If your users were everywhere but the headless client users were recently added, then a filter like objectCategory=appgate-headless.* could be used.

Attributes

Attributes can also be mapped into the AppGate ZTNA system, so it is worth having an up-to-date list of all attributes that might be useful for defining access rights.

Certificate Prerequisites

AppGate ZTNA requires the use of an RSA based certificate that meets the following requirements:

• has the clientAuthentication extended key usage extension

• has a subjectAlternativeName field that is valid

• includes the private key

Hardware-based certificates as well as soft certificates are supported, as long as they both use the standard Windows certificate storage system. All certificates must be located in Certificates - Current User > Personal > Certificates.

In the example below, there are two valid certificates with the correct “Intended Purpose”, one from a smartcard-based certificate and the other a locally-stored soft certificate.

Authentication

When trying to sign in using a certificate IdP, the list of valid certificates will be presented. This is done in slightly different ways depending on the operating system used and whether it is the client or the admin UI.

Admin UI sign-in. Select the LDAP Certificate provider from the identity provider list. Signing in will attempt to use the certificate selected previously.

Client sign-in. When the client profile specifies a certificate IdP, AppGate ZTNA will attempt to sign in using the certificate selected previously. The Controller will map attributes based on the subjectAlternativeName to populate user claims and issue claims and entitlement tokens.

Claims token renewal. When the user's claims token expires, the client uses the cached choice of certificate to handle token renewal automatically, which is transparent to the user.

It is possible to use this method when setting up the Linux headless client.