Authentication Realm

An authentication realm defines the authentication server with which end user is authenticated and the list of restrictions that must be satisfied on the client machine during sign-in. It also provides role mapping option to administrators for configuring the list of roles that needs to be assigned to the user. Role mapping provides flexibility to administrators in configuring how different set of roles need to be assigned to the user.

Creating an Authentication Realm

To create an authentication realm:

1.Select Administrators > Admin Realms or Users > User Realms.

2.On the respective Authentication Realms page, click New.

3.Enter a name to label this realm and, optionally, a description.

4.Select When editing, start on the Role Mapping page if you want the Role Mapping tab to be selected when you open the realm for editing.

5.Under Servers, specify:

•An authentication server to use for authenticating users who sign in to this realm.

•(Optional) A directory/attribute server to use for retrieving user attribute and group information for role-mapping rules and resource policies.

•(Optional) A RADIUS accounting server to use to track when a user signs in and out.

•Device attributes server to use the device attributes.

6.If you previously selected a RADIUS server for Authentication, the RADIUS Proxy option buttons appear. Select Proxy Outer Authentication or Proxy Inner Authentication to allow the system to proxy EAP authentication methods. Select Do not proxy if you do not want to use RADIUS proxy.

7.Select Enable additional authentication server to specify an additional authentication server.

8.To use dynamic policy evaluation for this realm, select Dynamic policy evaluation to enable an automatic timer for dynamic policy evaluation of this realm’s authentication policy, role-mapping rules, and role restrictions. Then:

•Select the Refresh interval option to specify how often to perform an automatic policy evaluation of all currently signed in realm users. Specify the number of minutes (5 to 1440).

•Select Refresh roles to refresh the roles of all users in this realm. (This option does not control the scope of the Refresh Now button.)

•Select Refresh resource policies to also refresh the resource policies (not including Meeting and e-mail Client) for all users in this realm. (This option does not control the scope of the Refresh Now button.)

•Click Refresh Now to manually evaluate the realm’s authentication policy, role-mapping rules, role restrictions, user roles, and resource policies of all currently signed-in realm users. Use this button if you make changes to an authentication policy, role-mapping rules, role restrictions, or resource policies and you want to immediately refresh the roles of this realm’s users.

•To use session migration for endpoints with the Pulse client, select the Session Migration check box. Then enter the Authentication Group and specify whether you want to receive user attributes from IF-MAP or from a directory server. Note that you must also configure IF-MAP Federation for all of PPS nodes in a session migration network.

•Click Save Changes to create the realm. The General, Authentication Policy, and Role Mapping tabs for the authentication realm appear.

9.Perform the next configuration steps:

•Configure one or more role-mapping rules.

•Configure an authentication policy for the realm.

•After you configure the authentication realm, select Authentication > Signing In > Sign-in Policies, add the realm to a sign-in policy, and associate the realm with an authentication protocol set.

Configuring Admin/User Realm to associate an additional Authentication Server

To configure a user realm:

1.Select Users > User Realms > New User Realm.

2.Complete the settings for the user-realm.

3.Under Additional Authentication Server, select the Enable additional authentication server option.

4.Select any already created authentication-server from the Authentication #2 dropdown.

5.Specify the username and password.

•Username: Specified by user on the sign-in page/Predefined as <USER>

Configure Predefined as <NTUSER> if Primary Authentication server is AD server.

•Password: Specified by user in sign-in page options/Predefined as <PASSWORD>/Mask static password.

6.Click Save Changes.

Certificate Auth Server and SQL Auth Server are currently not supported as secondary authentication server.

Configuring Realm Restrictions

Source IP Access Restriction

Use a source IP restriction at the realm to control from which IP addresses users can access a sign-in page.

To enable Source IP access restriction:

1.Select Users > User Realm > Select Realm > Authentication Policy > Source IP.

2.Select one of the following options:

•Allow users to sign-in from any IP address- You can allow or deny access to any IP address/netmask combination. For example, you can deny access to all users on a wireless network (10.64.4.100), or you can allow access to all other network users (0.0.0.0).

•Allow or deny users from following IP address- Enter the IPv4/IPv6 address, network/prefix length and choose whether to allow or deny access. Click Add.

3.Click Save Changes.

Certificate Access Restriction

Certificate access restriction restricts access only to clients that have a client-side certificates. You can further restrict access using specific certificate attribute and value pairs.

To enable certificate access restriction:

1.Select Users > User Realms > Select Realm > Authentication Policy > Certificate.

2.Select one of the following options:

•Allow all users- Requires no client certificate.

•Allow all users and remember certificate information while user is signed in.-Client certificate information is saved.

•Only allow users with a client certificate signed by Certificate Authority (CA). –Requires client certificate signed by CA.

3.Create a field/value pair check based on attributes within the client certificates. Enter the “Certificate field” and the expected value. Click Add. The value in the field depends on the naming attributes in the Relative Distinguished Name(RDN) in the subject DN of the certificate.

For example, if the subject DN is cn=user1, uid=uid1, sn=lastname, [email protected], OU=QA, O=company, C=US, you can use ‘cn’, ‘uid’, ‘sn’, ‘E’, ‘ou’, ‘o’, ‘c’.

4.Click Save Changes.

Host Checker Restrictions

To specify Host Checker restrictions:

1.Select Users > User Roles > Select Realm > General > Restrictions > Host Checker.

2.Select Allow users whose workstations meet the requirements specified by these Host Checker policies to apply HC restrictions.

3.Select the Host Checker policy from the Available Policies list and click Add.

4.Select the Allow access to role if any ONE of the selected policies is passed check box if you do not want to require users to meet all of the requirements in all of the selected policies.

5.Click Save Changes.

Browser Restriction

To specify browser restrictions:

1.Select Users > User Realms > Select Realm > Authentication Policy > Browser.

2.Select Only allow users matching the following user-agent policy to define browser access control rules.

To create a rule:

•For the user-agent string pattern, enter a string in the format *<browser_string>*

where asterisk (*) is an optional character used to match any character and <browser_string> is a case-sensitive pattern that must match a substring in the user-agent header sent by the browser. You cannot include escape characters

(\) in browser restrictions.

•Select either:

•Allow to allow users to use a browser that has a user-agent header containing the <browser_string> substring.

•Deny to prevent users from using a browser that has a user-agent header containing the <browser_string> substring.

•Click Add.

3.Click Save Changes.

Rules are applied in order, so the first matched rule applies. Literal characters in rules are case sensitive, and spaces are allowed as literal characters. For example, the string *Opera* matches any user-agent string that contains the substring Opera.

Password Access Restriction

You can restrict network and resource access by password-length when administrators or users try to sign in. The user must enter a password whose length meets the minimum password-length requirement specified for the realm. Note that local user and administrator records are stored in the local authentication server. This server requires that passwords are a minimum length of 6 characters, regardless of the value you specify for the realm's authentication policy.

To specify password restrictions:

1.Select Users > User Realms > Select Realm > Authentication Policy > Password.

2.Select one of the following options:

•Allow all users (passwords of any length) — Does not apply password restrictions on password length.

•Only allow users that have passwords of a minimum length — Requires the user to enter a password with a minimum length that you specify.

3.Select Enable Password Management to enable password management.

You must also configure password management on the authentication server configuration page (local authentication server) or through an LDAP server.

4.Select Allow MS-CHAPv2 for Password authentication to perform password authentication using MS-CHAPv2 prtotocol to allow single sign-on for Windows desktop clients.

5.Click Save Changes.

By default, the system requires that user passwords entered on the sign-in page be a minimum of four characters. The authentication server used to validate a user’s credentials might require a different minimum length. For example, the local authentication database requires user passwords to be a minimum length of six characters.

Limits

To limit the number of simultaneous sessions:

1.Select Users > User Realms > Select Realm > Authentication Policy > Limits.

2.To limit the number of concurrent sessions, select the check box for Limit number of concurrent sessions, and type either a Guaranteed minimum and/or Guaranteed maximum.

3.To limit the number of sessions for users, select Limit the number of concurrent sessions for users.

4.Specify the number of sessions permitted for users in the Session Limit text box. By default, the number is 1 if the realm maximum is greater than 0; otherwise, the default is 0. The maximum number must be no greater than the maximum number of concurrent users for the realm.

5.Click Save Changes.

RADIUS Request Policies

You can create RADIUS request attribute policies to require authentication requests to contain specific RADIUS attribute values. If an endpoint attempts to access a realm with a RADIUS request attribute policy, the endpoint must meet the conditions specified in the policy.

To add a RADIUS request attribute policy to a realm:

1.Select a user realm on which you want to implement a RADIUS request attributes policy by selecting Users > User Realms > Select Realm > Authentication Policy > RADIUS Request Policies.

2.Click Add to populate the Selected RADIUS Request Attributes Policies list from the available RADIUS Request Attribute Policies.

The RADIUS request policies selected must be passed to allow users to access a realm. To configure RADIUS request policies, see here.

3.Select the Allow access to realm if any ONE of the selected policies are passed check box if you would like to allow access if any one of the selected policies is passed.

4.Click Save Changes.

Configuring Role Mapping

Role-mapping rules are conditions a user must meet to map to user roles.

To specify role-mapping rules for an authentication realm:

1.Select Administrators > Admin Realms, Users > User Realms.

2.Select a realm and then click the Role Mapping tab.

3.Click New Rule to access the Role Mapping Rule page. This page provides an inline editor for defining the rule.

4.In the Rule based on list, select one of the following:

•Username—The system username entered on the sign-in page. Select this option if you want to map users to roles based on their usernames. If this is a RADIUS realm, and you are using RADIUS proxy for outer authentication, you cannot configure a role-mapping rule with a username.

•User attribute—A user attribute from a RADIUS, LDAP, or SiteMinder server. Select this option if you want to map users to roles based on an attribute from the corresponding server. This type of rule is available only for realms that use a RADIUS server for the authentication server, or that use an LDAP or SiteMinder server for either the authentication server or the directory server. After choosing the User attribute option, click Update to display the Attribute list and the Attributes button. Click the Attributes button to display the server catalog.

•Certificate or Certificate attribute—Certificate or Certificate attribute is an attribute supported by the users’ client-side certificate. Select this option to map users to roles based on certificate attributes. The Certificate option is available for all realms. The Certificate attribute option is available only for realms that use LDAP for the authentication or directory server. After choosing this option, click Update to display the Attribute text box.

•Group membership—Group membership is group information from an LDAP or native Active Directory server that you add to the server catalog Groups Tab. Select this option to map users to roles based on either LDAP or Active Directory group information. This type of rule is available only for realms that use an LDAP server for either the authentication server or directory server or that use an Active Directory server for authentication. (Note that you cannot specify an Active Directory server as an authorization server for a realm.)

•Custom Expressions—Custom Expressions is one or more custom expressions that you define in the server catalog. Select this option to map users to roles based on custom expressions. This type of rule is available for all realms. After you select this option, click Update to display the Expressions lists. Click the Expressions button to display the Expressions tab of the server catalog.

•Anomaly Attribute-Select this option for behavioral analytics.

5.Under Rule, specify the condition to evaluate, which corresponds to the type of rule you select and consists of the following:

•If you are creating a role mapping rule for a MAC address authentication realm, the attributes list cannot be edited. If there is an LDAP server assigned to this MAC authentication server and you want to use and edit the attributes assigned to that LDAP server, please specify the LDAP server as the Directory/Attribute server.

•Specifying one or more usernames, SiteMinder user attribute cookie names, RADIUS or LDAP user attributes, certificate attributes, LDAP groups, or custom expressions.

•Specifying to what the value must equate, which might include a list of usernames, user attribute values from a RADIUS, SiteMinder, or LDAP server, client-side certificate values (static or LDAP attribute values), LDAP groups, or custom expressions.

For example, you can choose a SiteMinder user attribute cookie named “department” from the Attribute list, choose is from the operator list, and then enter "sales" and "eng" in the text box.

Alternatively, you can enter a custom expression rule that references the SiteMinder user attribute cookie named department:

<userAttr.department = ("sales" and "eng")>

6.Under ...then assign these roles:

•Specify the roles to assign to the authenticated user by adding roles to the Selected Roles list.

•Select Stop processing rules when this rule matches if you want the system to stop evaluating role-mapping rules if the user meets the conditions specified for this rule.

7.Click Save Changes to create the rule on the Role Mapping tab. When you finish creating rules, be sure to order role-mapping rules in the order in which you want the system to evaluate them. This task is particularly important when you want to stop processing role-mapping rules when a match is identified.

User Role Evaluation

Administrator can configure the role mapping rules for determining the list of roles that need to be assigned to the users. In case of multiple role assignment, PPS merges the various role settings using permission merge. Administrators can also configure how different rules can be evaluated and merged using the options provided on role mapping rules page.

If you assign a role to a RADIUS proxy realm, role restrictions cannot be enforced. Host Checker policies, source IP restrictions, and any other limits that have been assigned are bypassed. Use RADIUS proxy only if no restrictions have been applied. Additionally, outer proxy cannot be used if a role-mapping rule based on usernames is being used, because the system cannot see the username, and a session cannot be created.

A permissive merge is a merge of two or more roles that combines enabled features and settings according to the following guidelines:

•Any enabled access feature in one role takes precedence over the same feature set to disabled in another role. For example, if a user maps to two roles, one of which disables the Host Enforcer while the other role enables the Host Enforcer, the system enables the Host Enforcer for that session.

•In the case of user interface options, the system applies the settings that correspond to the user’s first role.

•In the case of maximum session lengths, the system applies the greatest value from all the roles to the user’s session.

•If more than one role enables the Roaming Session feature, then the system merges the netmasks to formulate a greater netmask for the session

The system performs the following security checks before creating a session for a role:

1.The system begins rule evaluation with the first rule on the Role Mapping tab of the authentication realm to which the user successfully signs in. During the evaluation, the system determines if the user meets the rule conditions. If so, then:

•The system adds the corresponding roles to a list of eligible roles available to the user.

•The system determines if the “stop on match” feature is configured. If so, then the engine proceeds.

2.The system evaluates the next rule on the authentication realm’s Role Mapping tab according to the process in Step 1 and repeats this process for each subsequent rule. When the system evaluates all role-mapping rules, it compiles a comprehensive list of eligible roles.

3.The system evaluates the definition for each role in the eligibility list to determine whether the user complies with any role restrictions. The system then uses this information to compile a list of valid roles, whose requirements the user also meets.

If the list of valid roles contains only one role, then the system assigns the user to that role. Otherwise, the system continues the evaluation process.

4.The system evaluates the setting specified on the Role Mapping tab for users who are assigned to more than one role:

•Merge settings for all assigned roles—If you select this option, the system performs a permissive merge of all the valid user roles to determine the overall (net) session role for a user session.

•User must select from among assigned roles—If you select this option, the system presents a list of eligible roles to an authenticated user. The user must select a role from the list, and the system assigns the user to that role for the duration of the user session.

•User must select the sets of merged roles assigned by each rule—If you select this option, the system presents a list of eligible rules to an authenticated user (that is, rules whose conditions the user has met). The user must select a rule from the list, and the system performs a permissive merge of all the roles that map to that rule.

If you use automatic (time-based) dynamic policy evaluation or if you perform a manual policy evaluation, the system repeats the role evaluation process described in this section.