Authentication Nodes

An authentication (auth) node is any RADIUS client, agent, or application that sends authentication requests to the Virtual Server. Only requests from an Auth Node are processed by the Virtual Server.

The number of Auth Nodes cannot exceed the allowed number set by your service provider. The Virtual Server will not process authentication requests received from devices or applications that are not in the list.

If there is a single organization (Virtual Server) and no Auth Nodes are configured, the system allows for authentications to be accepted from any source (all IP addresses are allowed).

Depending on the network conditions, the Virtual Server accepts authentication requests from an Auth Node for processing within approximately five minutes of configuration.

You can view the RADIUS integration guides in the Support Portal.

Considerations if using the RADIUS protocol

Using the RADIUS protocol over the internet with SAS may leak RADIUS request and response information. To take advantage of this opportunity, an attacker needs to intercept the RADIUS traffic between the customer data center and the SafeNet Authentication Service (SAS) server that is hosting the RADIUS server.

This type of attack may occur because the RADIUS traffic is protected by the RADIUS shared secret and a hiding mechanism that is based on a combination of stream cipher and md5 hash, rather than a standard encryption scheme. In particular:

• In PAP mode, the password data is protected by the RADIUS shared secret.

• In MSCHAPv2 mode, the password data is further protected by the MS-CHAP authentication protocol.

Where possible, Thales recommends using one of the following alternatives to avoid the above risks. Refer to the appropriate sections of this documentation for configuration details about each of these solutions:

• Use SAML or OIDC as an alternative to RADIUS for user authentication. This can be achieved using SafeNet Keycloak Agent.

• Terminate the RADIUS traffic in the customer data center by configuring an on-premise RADIUS server, such as Microsoft NPS or FreeRADIUS with the SafeNet Agent.

• Use the SAS VPN service to tunnel RADIUS traffic over IPSEC between your data center and the authentication service.

• Use the SAS SDK and API for integration with the authentication validation service.

Configure Auth Nodes

You can configure RADIUS IP and port numbers, as well as RADIUS clients, SafeNet agents, and applications (such as VPN or Outlook Web Access), so that they can authenticate against the account’s Virtual Server.

1. On the SAS console, select Comms > Auth Nodes and select the Auth Nodes link.

   

2. Click the Add button and enter the information on the Auth Nodes tab.

   

   • Auth Node Name - Must be unique. For example, the name can identify the vendor and model of the Auth Node product.

   • Resource Name - Identifies which authentication node a push notification relates to, to help the user determine whether they are authenticating a valid node. By default, this is the Auth Node Name. Unlike the Auth Node name, the resource name does not have to be unique.

     If authentication nodes are shared, the resource name is inherited from the parent account. If authentication nodes are shared with child accounts, make sure that the resource name is also meaningful to users of these child accounts.

   • Host Name: (Optional) Indicates the fully qualified domain name (FQDN) of the Auth Node.

   • Low IP Address In Range and High IP Address In Range - Specify the external IP address of the RADIUS client (such as an SSL VPN) or agent (such as SafeNet Agent for Microsoft Outlook Web App). This is the address that the account's Virtual Server receives authentication requests from.

   • Exclude from PIN change requests - If selected, the Virtual Server does not enforce server-side PIN changes during authentication through this Auth Node. Some RADIUS clients are not fully RADIUS-compliant and do not support challenge-response, which is a requirement for server-side PIN changes. If your RADIUS client does not support challenge-response and you have configured your server-side PIN policy to require the user to periodically change their PIN, select this check box to prevent a forced PIN change with the non-compliant RADIUS client.

     If no Auth Nodes support challenge-response, a better option is to disable server-side PIN changes or select a different form of PIN management.

   • Configure FreeRADIUS Synchronization - If checked, changes to Auth Nodes will be effective in less than 5 minutes on managed services or on instances using the FreeRADIUS plugin.

   • Shared Secret: - Is used with RADIUS clients and must match the shared secret configured in the RADIUS client. It is not required for Agents.

3. Click Save to save your changes or click Cancel to discard your changes.

   The Auth Nodes section lists the configured Auth Nodes.

   • Index - View Auth Node configuration
   • Description - The data entered in the Description field when the Auth Node was added.
   • Host Name - The data entered in the Host Name field when the Auth Node was added.
   • IP Address - The external IP address of the Auth Node (i.e., the address from which the Accounts Virtual Server will receive authentication requests).
   • FreeRADIUS Synchronization - If set to True, changes to Auth Nodes will be effective in less than five minutes on managed services or on instances using the FreeRADIUS plugin. This value has no effect if using Microsoft NPS as the RADIUS server.
   • Edit - Click this link to edit the corresponding Auth Node configuration.
   • Remove - Click this link to remove the corresponding Auth Node configuration.

Configure sharing and realms

Sharing and realms is an optional service feature that allows an Auth Node to be shared with two or more Virtual Server. Essentially, a realm is a group of Virtual Server.

For example, Org 1 manages a web application and its own users for authentication. Org 1 wants users from three of its subsidiaries (Org 2, 3, 4), each with their own Virtual Server, to be able to log in to the web application. In addition, each Org has protected applications to which only its users should have access. Using sharing and realms, Org 1 can share the web application with other organizations while restricting access to other Auth Nodes to its own users.

An account’s Auth Node can be shared with an external user (Account Manager) only if it is within the external user account’s scope.

It is not possible to share an Auth Node of a Subscriber account with any other Virtual Server. Subscriber accounts under the same parent account (service provider) can share an Auth Node only if the Auth Node is added to the parent account.

1. On the SAS console, select Comms > Auth Nodes > Edit Auth Node > Sharing & Realms.

   

2. Configure the options as required:

   • Allow account lookup based on user name: The submitted user ID will be used to authenticate the user. The Virtual Server will search the Shared Auth Node list in descending order. The first matching user ID is used to authenticate the user. Use the up and down arrows to move a selected realm up or down in the priority list. Effectively, this means that all user IDs must be unique across all realms.

   • Enable Realms: Use this option where user IDs may not be unique across all realms. If enabled, additional user ID information will be used to determine to which realm the user belongs. Typically, the user ID will be an email address. Use this feature in conjunction with the Selected Account and Realm Identifier options.

   • Strip Realm from UserID: Strips all data starting with the delimiter character from the user ID. This allows a submitted user ID, such as an email address (UserID@myco.com), to be authenticated as the UserID.

   • Delimiter character—Character that separates a username from a realm name (for example, @). Typically, @ is used when the realm is on the right (user@domain.com), while \ is used when the realm is on the left (DOMAIN\user).

   • Delimiter Instance: Specifies where to split up when multiple delimiter characters are present. Uses the first instance of the delimiter (left to right) or the last instance of the delimiter (right to left). In the example user@realm1@realm2: 

     • Split at First delimiter instance: user | realm1@realm2

     • Split at Last delimiter instance: user@realm1 | realm2

   • Realm First: Specifies which part of the string is the realm versus the user ID, after splitting at the delimiter character. In the DOMAIN\user example, the delimiter character is \. When Realm First is enabled, user is sent, and when Realm First is disabled DOMAIN is sent.

   • Selected Account: Specifies the particular account.

   • Realm Identifier: Specifies the particular realm. You can define only one realm identifier for a given account on a single Auth Node.

3. Select Save.