LDAP Certificate Identity Providers

  • 5 minute read
Prev Next

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

Appgate SDP 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 SDP 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 look-up times

If the system is configured to be reliant on AD group memberships, then it is recommended to perform an audit of both user and machine group memberships 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, 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 an authenticated user belongs to.

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

      • If the Base DN does not include groups (only 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 showing that sweden-sales is part of sales which is part of commercial.

      • If the Base DN does include 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. This also allows 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:

Configuration settings for user filters and membership for an LDAP Certificate identity provider.

Use of multiple IdPs

The use of multiple IdPs can minimize lookup times. If you have two different classes of users—human users with full clients and headless clients—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 SDP 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 SDP 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.

Certificate details for User1, including expiration date and intended purposes listed.

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 SDP 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.

AppGate Action prompts for additional authentication using a certificate for access.

Password user interaction. The password user interaction will work for LDAP Certificate (in spite of the name). When a password user interaction is triggered, the user will be required to OK the user interactions message assuming the Certificate is still present and valid. If a PIN has been set for the certificate, this will have to be re-entered. Once completed, then the user will be allowed access to that Entitlement.

It is possible to use this method when setting up the Linux Headless Client.

Related articles