This section describes how AppGate ZTNA works with LDAP(AD) and RADIUS identity providers (IdPs).
AppGate ZTNA supports standard enterprise IdPs such as Active Directory (Entra ID). These are used to authenticate users connecting through the client, and also to authenticate administrators logging in to the Controller Management interface.
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.
Use the Identity Providers UI to configure RADIUS.
Only the most basic functional integration is offered when interfacing to RADIUS server. You should ensure that AppGate ZTNA can meet your specific requirements before selecting this option.
Operation
With this IdP type:
The client passes the user's credentials to the Controller.
The service account (bind account) is used to locate the user in AD. The service account is needed because username alone is not enough to bind.
This provides the Controller with the userPrincipalName for that user.
Using that information the Controller now binds as using username and password.
If the bind is successful, then accept the user's authentication as a success.
The Controller then queries AD for attributes/group memberships.
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.
Configuration
Shortening lookup 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 thatsweden-salesis part ofsaleswhich is part ofcommercial.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, andcommercial.
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:
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 ZTNA system, so it is worth having an up-to-date list of all attributes that might be useful for defining access rights.
Client authentication
Client sign-in. When one of these IdPs has been selected on the client sign-in screen, the username and password must be entered and the user can select the Keep me signed in option. This will remember the credentials and use them to auto-start the client and automatically sign in the user next time. The Controller will map attributes based on the user name entered 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 username/password credentials to handle token renewal automatically. When the user credentials no longer match, the user will be prompted to re-authenticate in order to renew the token.
Password user interaction. If a password user interaction is triggered, the client will ask the user to type in a password. This might be from the IdP used for signing in or it could be a different IdP.
Administrator authentication
These methods can also be used to authenticate an administrator signing in to the Controller admin UI and for REST API calls.