Pre-authentication rules
Pre-authentication rules determine the conditions that must be satisfied before a user is allowed to authenticate.
Just because a user is able to provide a valid one-time passcode does not necessarily mean that they should be granted access to the network. Other conditions might be important in allowing or denying access, such as their network access point, group membership, account status, and other attributes.
To authenticate against an LDAP user source, users need either a direct LDAP connection from SAS or a synchronized password. LDAP authentication is not supported through the SafeNet Synchronization Agent.
Security administrators can use pre-authentication rules to apply additional conditions that must be met for authentication to succeed.
Advantages of pre-authentication rules
The key advantages of pre-authentication rules include:
-
Rules can be applied to LDAP or Active Directory user account attributes.
-
Rules can be applied to user accounts that are maintained in the internal SQL user data source.
-
Rules can be applied based on network access points (source IP, Agent).
-
Rules can be used to modify the authentication sequence (OTP, LDAP, LDAP + OTP).
-
Changes to user attributes that are made in LDAP or in the internal user data source are immediately effective on SafeNet Authentication Service (SAS).
-
Rules can have a fixed day of the week, start or stop date, or start or stop time, which is useful for transitioning from static passwords to OTP authentication.
Authentication sequence with pre-authentication rules
The authentication proceeds in the following sequence:
-
UserID is validated.
-
If the UserID is valid, pre-authentication rules are applied.
-
If any rule is satisfied, password is validated.
-
If the password is valid, access is granted.
Configure pre-authentication rules
There are few limitations to how pre-authentication rules can be used. Rules can be relatively simple, checking a single attribute such as time of day restrictions, or they can be complex, checking multiple attributes such as group membership, network access point, and token state.
The key concepts to consider when creating rules are:
-
Multiple rules can be configured, however a user’s attributes needs to satisfy only one rule for authentication to proceed.
-
Initially, SAS is configured with an Allow All rule.
Pre-authentication rules must be enabled for the restrictions to be in effect.
Filters for pre-authentication rules
When you configure a pre-authentication rule, you select a filter. Each filter has different options.
Agent is
This filter specifies which agents are allowed to authenticate against the Virtual Server. When you select the Agent is filter, you set a condition for the filter. For example, selecting IAS allows RADIUS authentication from all Microsoft IAS/NPS servers with the appropriately configured SafeNet Agent for IAS/NPS.
-
Authentication API: Required to allow authentication from third-party applications that added authentication using the SafeNet Authentication API.
-
Citrix: Required to allow authentication via the SafeNet Agent for Citrix Web Interface.
-
Console: Required to allow remote management connections to the SAS server.
-
IAS: Required to allow authentication via the SafeNet Agent for IAS/NPS.
-
IIS: Required to allow authentication via the SafeNet Agent for IIS.
-
Juniper / Funk SBR: Required to allow authentication via the SafeNet Agent for Juniper/Funk Steel Belted RADIUS.
-
Remote Management API: Required to allow the Command Line Interface (CLI) to connect to the SAS server.
-
Windows Logon: Required to allow authentication via the SafeNet Agent for Windows Logon.
Date Restrictions
This filter limits the lifetime of a rule. This rule is always used in conjunction with another filter. For example, it could be used with the LDAP/AD Password Validation filter to facilitate migration from LDAP passwords to token authentication, so that LDAP passwords would be valid against SafeNet Authentication Service until the rule expires or a token is activated.
-
Begin this rule on: If enabled, the rule is not active until the indicated date. If disabled, the rule is immediately effective.
-
Expire this rule on: If enabled, the rule stops being enforced on this date. If disabled, the rule remains active.
Day of Week Restrictions
If enabled, SafeNet Authentication Service processes authentication requests only on the selected days of the week. Unlike the Access Restrictions module on the Assignment tab, this rule can enforce restrictions on groups or destinations.
- Day of week: If enabled, the rule will be enforced on the selected days of the week.
IP
If enabled, SafeNet Authentication Service does not process authentication requests from NAS devices, such as VPNs and firewalls, that have an IP address outside of the defined range. This filter is usually used in conjunction with another filter. For example, if combined with a group membership attribute, only members of a specific group could authenticate at a NAS device in the IP range. Conversely, in the absence of any other contravening rule, members of the group would not be able to authenticate at a NAS device that is not in the IP range. This filter supports IPv4 and IPv6 addressing.
-
Is equal to: Specifies a single valid IP address.
-
Is in the range of: Specifies an IP address range.
-
Is in mask: Specifies an IP address range using a mask.
LDAP/AD Password Validation
This filter determines when SafeNet Authentication Service should validate a password or pass it through to LDAP for validation. It also determines how SafeNet Authentication Service handles LDAP authentications that fail.
This function is available with SAS PCE with a direct LDAP connection (this requires
SAS v3.5.1 or later).
MSCHAPv2 authentication protocol is not supported for LDAP/AD passwords.
The primary purpose of this filter is the transparent migration of users from static passwords to token authentication. For users that meet the conditions, authentication will “pass through” SafeNet Authentication Service to LDAP, or use the synchronized Active Directory password for validation. This filter also determines the action that SafeNet Trusted Access takes after LDAP authentication. This filter is often combined with Date Restrictions and Agent or IP attributes.
For example, enabling LDAP/AD Password Validation if a user has no token or temporary password means that any user with a token must use it to authenticate. Those without a token continue to use their LDAP password until they receive or enroll their token, or until the date restriction disables this attribute.
-
Always: All passwords are passed to LDAP for validation against the AD hash.
-
When user has no SafeNet Authentication Service token or password: Passwords are passed to LDAP for validation against the AD hash only if the user does not have a token that is in the Active, Suspended, or Locked state, or has a SAS temporary password.
-
When user has an active SafeNet Authentication Service token or password: Passwords are passed to LDAP for validation against the AD hash only if the user has a token that is in the Active, Suspended, or Locked state, or has a SAS temporary password.
-
If LDAP authentication fails, reject the authentication: Access is denied if LDAP authentication fails.
-
If LDAP authentication fails, forward request back to SafeNet Authentication Service: SafeNet Authentication Service attempts to validate the password.
-
If LDAP authentication succeeds, the user is authenticated: SafeNet Authentication Service grants access based on the AD password alone.
-
If LDAP authentication succeeds, when challenge is automatically triggered.: If a MobilePASS+ token is available, then SAS sends a MobilePASS+ push notification to the user, requesting authentication authorization.
If the MobilePASS+ token is absent, then SAS challenges the user to authenticate with their SAS token or password.
This option is useful for end-to-end automated flows, minimal user intervention, and high token delivery success rates.
Force challenge response is renamed to automatically trigger challenge.
-
If LDAP authentication succeeds, enforce a challenge prompt for manual trigger: Users can manually trigger a challenge, such as when a push-based token is not delivered.
Click here to see the impact of multi-mode settings in different scenarios.
Time of Day Restrictions
If enabled, SafeNet Authentication Service processes authentication requests only within the selected time range. Unlike the Access Restrictions module on the Assignment tab, this rule can enforce restrictions on groups or destinations.
-
Start time: If enabled, the rule is not active until the indicated time. If disabled, the rule is immediately effective.
-
End time: If enabled, the rule stops being enforced at this time. If disabled, the rule remains active.
User is a member of
This filter requires group membership for authentication to proceed. It is normally used in conjunction with Agent or IP filters so that a user must be a member of a specified LDAP group when authenticating at the defined agent or IP address.
This filter does not require group membership to be configured in SafeNet Authentication Service. LDAP group memberships can be checked with each authentication. This means that group memberships can be managed from LDAP. Use * as a wildcard to filter available groups.
The user must be a member of the specified group in the list. To create a list, use the arrows to move the groups to the Used by rule list, and then select Add to add the groups to the Conditions.
Add a pre-authentication rule
-
On the SAS Token Management console, select the Comms tab, expand the Authentication Processing module, and then select Pre-authentication rules.
-
Select the New Rule button.
The Add New Pre-Auth Rule options are displayed.
-
Enter the Rule Name and Description.
-
Select a Filter from the above list.
-
Configure the conditions for the filter, and then select the Add button.
-
To enforce the pre-authentication rules, select the Enable Pre-Auth Rules check box.
This check box allows an administrator to spend time creating the rules, and to enable the enforcement of the rules when the rules are ready. If the feature is enabled, but no pre-authentication rules are defined, then all authentications are blocked and fail.
