General settings

Before you start, you may wish to review the Checklist and Background Information for configuring identity providers (IdP). When you're ready this page will take you through the various fields which are shares across several of the IdP types.

The Specific IdP settings page takes you through the various fields specific to each new IdP type.

The Built-in IdP settings page takes you through the various fields that can be edited.

Add Identity Provider

Name

Enter a name for the Identify Provider; which cannot be changed later.

Sign-in Settings

Prevent new devices registrations that exceed this per user limit

All new devices are registered by the Controller. This prevents users registering more devices than the set limit. After registration is done, this number can be set to 0 to block all new devices. The registration of new devices (when valid credentials are presented) helps to prevent one of the most common forms of breach, namely when stolen credentials are used to sign-in to a system from a new device.

A cookie is created at sign-in and saved by the Controller and the Client (to present at subsequent connection attempts). This allows the Controller to perform additional checks at sign-in using this information. In the first instance the device count is checked and access will not be allowed if the set limit been exceeded. If this check passes then there is the option to require that users perform MFA at sign-in; either to register a new device (once), or for new and registered devices (always).

From time to time it may be required to remove a registered device.

The cookie can be deleted from the Client. See Device registration for details of this.
The matching record on the Controller can also be deleted. See Registered Devices.

MFA at Sign-in

Provides an additional restriction in respect of device registration. MFA can optionally be used with new devices or with new/registered devices. There are three modes available:

Not required (automatically register all devices)
Once (MFA required to register all new devices)
Required to register any new device, as long as the new device registration count has not been exceeded
Always (MFA required at every sign-in)
Required whether a device has been registered or not, as long as the new device registration count has not been exceeded

The recommended mode of operation is Once which means a user can on-board their own devices and will be required to provide additional authentication at that time. Thereafter the device effectively counts as a second factor when authenticating, mitigating the requirement for users to use MFA at every sign-in. See MFA for more details. For Once or Always an MFA provider must have been pre-configured:

MFA Provider

Choose which MFA provider to use for MFA at Sign-in.

Message

Message displayed to the user for 'Require MFA'. Defaults to localized message in Client. Client will replace "%RADIUS_MESSAGE%" with the message from radius server (if any).

Claim Suffix

Enter a claim name for this 'Require MFA' user interaction which will be passed to the Gateways in the Claims Token. If you are configuring MFA at sign-in and also plan to use an MFA user interaction, then if you use the same user response claim suffix for both - you can avoid the user having to perform MFA twice over a short period of time.

Use for admin UI access

When Enabled, this will be included in the list of identity providers presented to the administrator.

Client Settings

Client Inactivity

Desktop Clients will be signed out automatically when inactive.

Inactivity Timeout in Minutes

Set the inactivity timeout period after which the user will be signed out.

Timeout Trigger

Select between User Inactivity Only or User or Network. The latter triggers when either are inactive. This feature is designed mainly to drop the open tunnels to the Gateways and prevent any background traffic being sent from unattended machines. It is not designed as a user security feature since the Client often is configured to sign-in automatically. The user will see "Your session has timed out after being idle for too long."

DNS Configuration

DNS is set up in a number of places in Appgate SDP. This configuration is used as a fall-back if there is no DNS Policy set for the user. Unless you are using the Client DNS auto-configuration option, you need to add an Entitlement so the user's application is able to access the DNS server(s) you have specified. Leave access control set to Always Allow Action(s).

DNS Servers

DNS Servers to be used by the Client when authenticated by this identity provider.

NOTE
Linux will only try the 1st DNS server configured.

DNS Domains

DNS Domains are used by the Client after authentication. Windows uses these as search domains; other operating systems use these as match domains. For details about the use of the DNS Domains field, refer to DNS and name resolution.

Block Local DNS Requests

When enabled, all DNS requests will be sent via the Appgate SDP tunnel. Applies to Windows and macOS Clients only. This is not actually a DNS setting at all but is a Ringfence rule. When enabled local traffic on UDP53, UDP443, TCP53, TCP443 & TCP853 is blocked. This may be required if you have a situation where the IP addresses of (protected) hosts may (wrongly) be resolved by local DNS servers.

NOTE
The Windows multi-user Client does not use any of these settings; instead it relies on the default DNS configuration applied by the operating system.

Enforce Appgate connection as Domain network profile

Tries to set the Client's network adapter to run with a Domain network profile. This could then be used to influence local firewall settings. The network profile appears to use the following registry value but this is unsupported & undocumented by Microsoft. Its use is therefore not guaranteed and outcomes may depend on the version and build number of the underlying Client operating system.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\{<Network GUID>}

The value of Category can be set as follows; Public = 0, Home = 1, Work = 2. When checked the value is set to 2.

IP Pools

IPv4 Pool

Select a pre-configured pool of IP addresses to assign to Clients authenticated through this identity provider.

IPv6 Pool

Select a pre-configured pool of IP addresses to assign to Clients authenticated through this identity provider.

Claims

Attributes Mapped to User Claims

Attributes mapping defines how the user attributes in this identity provider directory will be mapped to Appgate SDP user claim names. This defines additional user claims that will be available to use when defining Access Criteria. For the local provider and Connector provider, a default list of mapped attributes is included. For the LDAP providers an example list of AD mapped attributes is included. As well as adding your own attributes, the included attributes can be edited/deleted.

Now is a good time to change or add any user claims you might want to use when you move on to configure user access.

User claims explains how to map extra claims and there is a list of the default user claims used in the Appgate SDP system.

User Claim Scripts

These scripts can be used to make REST calls to external systems and return values which are mapped to user claims. User claims explains how to use these scripts and there is a list of all user claims used in the Appgate SDP system.

Commands Mapped to On-Demand Device Claims

These scripts run on the users device and return values which are mapped to device claims. Device claims explains how to use these scripts and there is a list of all device claims used in the Appgate SDP system.