Settings of an Authentication Rule

This section describes how to maintain the settings of each individual Authentication Rule in the Authentication Rule sequence of an Authentication Policy. When creating a new or editing an existing Authentication Rule, the following dialog appears:

The dialog contains 3 tabs:

 Basic: This tab contains two basic settings for the rule

 Conditions: This tab is used to define under which conditions this rule should apply.

 Result: This tab is used to define the outcome of the rule, in case it applies.

The settings of the 3 tabs are described below.

Basic:

The Basic tab contains the following two settings:

Setting Explanation

(a) Enabled The checkbox Enable rule specifies whether the rule is currently enabled (active) or not. If the rule is disabled, it will be skipped during evaluation of the

Authentication Rule sequence, i.e. it will then not affect authentication behavior in any way. This might be useful for temporary de-activation of an Authentication Rule.

(b) Description A textbox for entering an optional informative text for your own records. You can use it to describe the purpose of the Authentication Rule.

Conditions:

The Conditions tab groups all the settings defining the conditions when the Authentication Rule should apply to an authentication attempt. By default, all settings are set to “Any”, meaning the Authentication Rule will apply to all authentication attempts. However, by changing one or more of the settings, you can customize the Authentication Rule to apply only under specific

circumstances, according to your specific requirements. Please note that when several conditions are set, all of them must be fulfilled for the rule to apply.

Evaluation of Authentication Rules in case of unknown data

When evaluating the conditions of an Authentication Rule, sometimes it may occur that the data to be evaluated by a condition is not available (“unknown”). In such cases, the Authentication Rule will be skipped and evaluation will continue at the next rule in the Authentication Rule sequence. Below, the descriptions of the individual condition settings highlight, when unknown data can occur and what the consequences will be in each case.

The table below explains the settings of the Conditions tab in more detail.

Condition Explanation

Authentication client IP

The Authentication client IP setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted through an authentication client with a specific IP address. Please note, that wildcards are also allowed, making it possible to define the restriction on an IP-scope instead of a single IP address.

This condition is useful if you would like to define specific authentication behavior for a specific subset of your authentication clients (determined by IP address).

Authentication client type

The Authentication client type setting allows you to define whether the

Authentication Rule should only apply in case authentication is attempted through an authentication client of one or more specific types. Checkboxes allow you to select the allowed types of authentication clients.

This condition is useful if you would like to define specific authentication behavior for a specific subset of your authentication clients (determined by type).

Condition Explanation

End-user IP

The End-user IP setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted from a specific end-user IP address.

Please note, that wildcards are also allowed, making it possible to define the restriction on an IP-scope instead of a single IP address.

This condition is useful if you would like to define specific authentication behavior for a specific subset of end-user IP addresses, e.g. authentication attempts from the internal LAN or from connected branch office networks.

Note regarding Secure Device Provisioning (SDP)

In case of SDP the end-user IP address is the IP address of the ActiveSync device, not the IP address of the browser logging in to the SDP Web Site. These two IP addresses can be different, but will often be the same, since the user will most likely log in to the SDP Web Site from the ActiveSync device itself. If you need to audit the IP address for the browser accessing the SDP Web Site, then please inspect the Windows event log

“SMS PASSCODE Provisioning” on the relevant Exchange CAS. This event log contains audit events with all relevant authentication information; including end-user IP addresses, in case end-user IP collection has been enabled for SDP in the SMS PASSCODE^® Configuration Tool on the CAS (cf. section 20.2, page 392).

Note about “unknown end-user IP”

The end-user IP address might not be available during an authentication request.

Either because an authentication client is configured not to collect it or does not support collecting it. If the end-user IP address is unknown during an authentication attempt and the End-user IP condition is set, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt (you can create another

Authentication Rule taking care of the “unknown” end-user IP cases, by setting the Category of end-user IP condition to “Unknown”, cf. next setting below).

Condition Explanation

Category of

end-user IP Please note, that this condition is only available, if the setting Geo IP and IP history is enabled on the General Settings page.

The Category of end-user IP setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted from an unknown end-user IP address, or an end-user IP address that has been identified as Trusted or Non-Trusted, respectively.

This condition is useful if you would like to define specific authentication behavior for authentications from Trusted or Non-Trusted end-user IP addresses. E.g. you may deny access to specific types of authentication clients from Non-Trusted IP addresses.

Note about “unknown end-user IP”

The end-user IP address might not be available during an authentication request.

Either because an authentication client is configured not to collect it or does not support collecting it. If the end-user IP address is unknown during an authentication attempt and the Category of end-user IP condition is set to Trusted or Non-Trusted, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt.

Condition Explanation

Countries Please note, that this condition is only available, if the setting Geo IP and IP history is enabled on the General Settings page.

The Countries tab allows you to define whether the Authentication Rule should only apply in case authentication is attempted from an end-user IP address located in one or more specific countries or continents. To define the condition, select the required countries/continents in the Available for selection list and click the Incl. button. This will move the selected countries/continents to the Selected as filter list. If you want to remove any countries/continents from the condition again, select the

countries/continents in question in the Selected as filter list, then click the Excl.

button.

This condition is useful if you would like to define specific authentication behavior for authentications originating from specific countries or continents. E.g. from specific locations you may either deny access completely, or only allow restricted access to specific types of authentication clients.

Note about “unknown country of origin”

The country of origin might be unknown during an authentication request. Either because the end-user IP address is not available, due to the authentication client being configured not to collect it or not supporting collection of it; or because the end-user IP address is available, but it is not possible to determine the country of origin from the IP address; e.g. because the IP address is from a private IP scope. If the country of origin is unknown during an authentication attempt and the Countries condition is set, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt.

Condition Explanation

Organization Please note, that this condition is only available, if the setting Geo IP and IP history is enabled on the General Settings page

The Organization setting allows you to define whether the Authentication Rule should only apply in case authentication is attempted from an end-user IP owned by a specific organization. If plain text is entered into the filter textbox, then the Authentication Rule will apply as long as the organization name contains the text anywhere. E.g. if you enter the text “mycompany”, then the rule will apply when authentication is attempted from an end-user IP address owned by for example “MyCompany Ltd.”, “MyCompany Industries” or “CorporationMyCompany”. However, you can also enter a regular expression into the filter textbox in case you need to define the matching condition more exactly. E.g. entering “^MyCompany$” will only match IP addresses owned specifically by “MyCompany”. Please note, that the evaluation of a match is always performed using a case-insensitive comparison.

This condition is useful if you would like to define specific authentication behavior for authentications originating from IP addresses owned by specific organizations.

Note about “unknown organization”

The name of the organization owning the end-user IP address might be unknown during an authentication request. Either because the end-user IP address is not available, due to the authentication client being configured not to collect it or not supporting collection of it; or because the end-user IP address is available, but it is not possible to determine the organization name from the IP address; e.g. because the IP address is from a private IP scope. If the organization name is unknown during an authentication attempt and the Organization condition is set, then the Authentication Rule will be skipped during evaluation of the Authentication Rule sequence, i.e. the Authentication Rule will NOT apply to the authentication attempt.

Result:

All the condition settings described above let you define, when an Authentication Rule should apply to an authentication attempt. As explained previously, the first applying Authentication Rule in the rule sequence of an Authentication Policy is the rule that is selected for controlling the

authentication behavior of an authentication attempt. The behavior or “outcome” of the selected rule is controlled by the settings on the Result tab.

Setting Explanation

Access

The Access setting defines how the authentication attempt should be handled under the circumstances defined by the conditions of the rule.

You may choose between the following three options:

 Allow access, use MFA: This is the default behavior. The user is allowed to log in, but must authenticate using strong, secure SMS PASSCODE^® multi-factor authentication.

 Allow access, bypass MFA: This option allows the user to log in using standard “one-factor” authentication, i.e. by only entering user name and password. Use of this option should be treated with great care, since it lowers security considerably. However, it might make sense during logins from trustworthy locations, e.g. logins from the internal LAN.

Note:

The option Allow access, bypass MFA is only available if Multi-factor authentication bypassing has been allowed on the General Settings page. Otherwise, you will not see this option in the drop-down list.

WARNING (concerning Password Reset Web Site):

Bypassing MFA also applies to logins to the SMS PASSCODE^® Password Reset Web Site (PRWS). This is a new behavior in SMS PASSCODE^® version 7.2. If you have upgraded from a previous version and have any authentication rules set to Allow access, bypass MFA, then please verify whether the login behavior for the PRWS is as expected. Otherwise, please create a distinct authentication rule for PRWS with the required behavior.

 Deny access: This option will deny access, i.e. authentication will always fail immediately, after user name and password has been entered. No passcode will be sent.

Setting Explanation

Influence on the Secure Device Provisioning (SDP) Web Site

When making use of the SDP component for provisioning of ActiveSync devices, please note that the Access setting applies to the SDP Web Site, not to the

ActiveSync traffic. In other words, the setting has the following meanings in this case:

 Allow access, use MFA: The user is granted access to the SDP Web Site and must perform a successful MFA here to provision a new ActiveSync device.

 Allow access, bypass MFA: The user does not need to access the SDP Web Site – instead a new ActiveSync device is approved automatically, without any user actions. This might for example be useful for convenient provisioning of a new ActiveSync device, when the user is in a trusted environment, e.g. when the end-user IP address is within the internal WIFI network of your

organization.

 Deny access: The user is denied access to the SDP Web Site. This means that SMS PASSCODE^® Secure Device Provisioning is disabled and the user will not be able to self-provision a new ActiveSync device. In this case, provisioning of a new ActiveSync device falls back to the standard logic of Microsoft Exchange Server.

Change of IP trust level

Please note, that this setting is only available, if the setting Geo IP and IP history is enabled on the General Settings page

The setting Change of IP trust level lets you define, how much the Trust Level of the end-user IP address should increase, in case the authentication attempt succeeds.

IMPORTANT:

Please note that the Trust Level is only increased in case of a successful multi-factor authentication. I.e. only when the Access setting is set to Allow access, use MFA and a real multi-factor authentication succeeds. “Real” means that an OTP from a passcode message or token was used during authentication, as opposed to using a Personal Passcode.

It is recommended to either use the default setting of 1, or alternatively set it to zero, in case you have a specific authentication scenario that should not contribute to trusting IP addresses. For example you might not want end-user IP addresses in foreign countries to become trusted ever.

Setting Explanation Password reset

flow Password Reset only

This setting is only relevant for the SMS PASSCODE^® Password Reset module and is hidden if you have not acquired any Password Reset CALs. You can just ignore this setting if you are not intending to make use of the Password Reset module.

The Password reset flow setting affects the login behavior of the SMS PASSCODE^® Password Reset Web Site. The effective login behavior is determined by a combination of the Access and the Password reset flow setting. Please read section 17.3.2 (page 293) for more details regarding the possible login flows.

The most secure login flow is achieved by selecting Allow access, use MFA for the setting Access, and selecting Strict flow for the setting Password reset flow.

However, by creating several authentication rules with different Password reset flow values depending on different login conditions (login context), you are able to create an adaptive login behavior, making the login less secure, but more convenient from trusted login contexts.

Setting Explanation

Load Balancing Policy

&

Passcode Policy

By default, the Load Balancing Policy and Passcode Policy used during an

authentication attempt are determined statically by the configuration of the actual user – either by inheriting the Policies from the User Group Policy, or by specific policy overrides on the user itself (cf. section 15.2.1, page 109). However, when an Authentication Rule applies to a specific authentication attempt, you may optionally introduce a dynamic override of those policies, which takes highest precedence. This means, you may introduce context aware switching to a Load Balancing Policy and/or Passcode Policy that makes more sense in the specific context; also called contextual message dispatching. For example switching to a Load Balancing Policy that prefers voice calls before SMS, when logging in from specific countries, or switching to a Load Balancing Policy that calls a fixed line phone number in a branch office (as the

secondary phone number), when logging in from the branch office.

To introduce a dynamic policy override, i.e. perform contextual message dispatching, select the corresponding Override radio button, then select the policy of choice from the drop-down list.

IMPORTANT: Load Balancing Policy override only takes effect when the Dispatch type of a user is set to a Load Balancing Policy. In other words, when a user is set to use a specific dispatch type, e.g. SMS, not taking into account any Load Balancing Policy, then the override will not take effect, since there is no LB Policy to override.