User Verification and Key Concepts

User verification is the process that is supported to identifying a user, authorize and then determine whether a user can take specific actions. The following sections describe the concept and steps behind how user role, sign-in policy and authentication work in Pulse Connect Secure.

Verifying User Accessibility

Before you access your device, you need to create a user account in the system authentication server for verifying the user accessibility. After creating the account through the admin console, sign in as the user on the user sign-in page.

To verify user accessibility:

1.From the admin console, choose Authentication > Auth. Servers.

2.Select the System Local link.

3.Select the Users tab.

4.Click New.

5.Type testuser1 as the username and enter a password, and then click Save Changes. The testuser1 account is now created.

6.Use another browser window to enter the machine's URL to access the user sign-in page. The URL is in the format: https://a.b.c.d, where a.b.c.d is the machine IP address you entered in the serial console when you initially configured your device.

7.Click Yes when prompted with the security alert to proceed without a signed certificate. The user sign-in page appears, indicating that you have successfully connected to your device.

8.Enter the username and password you created for the user account and then click Sign In to access the home page for users.

9.Enter the URL to an internal web server in the Address box and click Browse. The PCS opens the web page in the same browser window, so to return to the PCS home page, click the center button on the toolbar that appears on the target web page.

10.Enter the URL to your external corporate site on the PCS home page, and click Browse. A web page opens in the same browser window, so use the button on the toolbar to return to the PCS home page.

11.Click Browsing > Windows Files on the PCS home page to browse through available Windows file shares or Browsing > UNIX/NFS Files to browse through available UNIX/NFS file shares.

Creating a Test Scenario to Learn Concepts and Best Practices

The PCS provides a flexible access management system that makes it easy to customize a user's remote access experience with roles, resource policies, authentication servers, authentication realms, and sign-in policies.

To enable you to quickly begin working with these entities, your device ships with PCS defaults for each entity that you will work with. You can create each access management entity by performing the tasks in the following sub-sections.

The PCS supports two types of users:

•Administrators-An administrator is a person who may view or modify PCS's configuration settings. You create the first administrator account through the serial console.

•Users-A user is a person who uses the PCS to gain access to corporate resources as configured by an administrator.

Defining a User Role

Your device is preconfigured with one user role called “Users.” This predefined role enables the web and file browsing access features, enabling any user mapped to the Users role to access the Internet, corporate web servers, and any available Windows and UNIX NFS file servers.

You can view this role on the User Roles page after you enable an access feature for a role, configure the appropriate corresponding options that are accessible from the access feature's configuration tab.

To define a user role:

1.In the admin console, choose Users > User Roles.

2.Click New Role.

3.Enter Test Role in the Name box and then click Save Changes.

4.Wait for the PCS to display the Test Role page with the General tab and Overview link selected.

5.Select the Web check box under Access features and then click Save Changes.

6.Select Web > Options.

7.Select User can type URLs in the IVE browse bar check box, and then click Save Changes.

After completing these steps, you have defined a user role. When you create resource profiles, you can apply them to this role. You can also map users to this role through role mapping rules defined for an authentication realm.

To quickly create a user role that enables web and file browsing, duplicate the Users role, and then enable additional access features as desired.

Defining a Resource Profile

A resource profile is a set of configuration options that contain all the resource policies, role assignments, and end-user bookmarks required to provide access to an individual resource.

Within a resource profile, a resource policy specifies the resources to which the policy applies (such as URLs, servers, and files) and whether the PCS grants access to a resource or performs an action. Note that the PCS is preconfigured with two types of resource policies:

Web Access - The predefined web Access resource policy, Initial Policy for Local Resources, allows access only to hosts belonging to domains within the secured network.

Windows Access - The predefined Windows Access resource policy enables all users mapped to the Users role to access all corporate Windows file servers. By default, this resource policy applies to the Users role.

To define a resource profile:

1.In the admin console, choose Users > Resource Profiles > Web.

2.Click New Profile.

The Web Applications Resource Profile page appears.

3.

The PCS adds Test Web Access to the web Application Resource Policies page and automatically creates a corresponding bookmark that links to google.com.

After completing these steps, you have configured a web Access Resource profile. Even though the PCS comes with a resource policy that enables access to all web resources, users mapped to Test

Role are still prohibited from accessing http://www.google.com. These users are denied access because the auto policy you created during the resource profile configuration takes precedence over the default web access policy that comes with the PCS.

Defining an Authentication Server

An authentication server is a database that stores user credentials - username and password - and typically group and attribute information. When a user signs into the host, the user specifies an authentication realm, which is associated with an authentication server. The PCS forwards the user's credentials to this authentication server to verify the user's identity.

The PCS supports the most common authentication servers, including Active Directory, RADIUS, LDAP, NIS, RSA ACE/Server, SAML Server, and CA SiteMinder, and enables you to create one or more local databases of users who are authenticated.

The PCS is pre-configured with one local authentication server for users called “System Local.” This predefined local authentication server is a system database that enables you to quickly create user accounts for user authentication. This ability provides flexibility for testing purposes and for providing third-party access by eliminating the need to create user accounts in an external authentication server.

You can view the default local authentication server on the Authentication Servers page.

The PCS also supports authorization servers. An authorization server (or directory server) is a database that stores user attribute and group information. You can configure an authentication realm to use a directory server to retrieve user attribute or group information for use in role mapping rules and resource policies.

To define an authentication server:

1.In the admin console, choose Authentication > Auth. Servers.

2.Select Local Authentication from the New list and then click New Server.

The New Local Authentication page appears.

3.Enter Test Server in the Name box and then click Save Changes.

Wait for the PCS to notify you that the changes are saved, after which additional configuration tabs appear.

4.Click the Users tab and then click New.

The New Local User page appears.

5.Enter testuser2 in the Username box, enter a password, and then click Save Changes to create the user's account in the Test Server authentication server.

After completing these steps, you have created an authentication server that contains one user account. This user can sign in to an authentication realm that uses the Test Server authentication server.

The admin console provides last access statistics for each user account on the respective authentication server pages, on the Users tab under a set of columns titled Last Sign-in Statistic. The statistics reported include the last successful sign-in date and time for each user, the user's IP address, and the agent or browser type and version.

Defining an Authentication Realm

An authentication realm is a grouping of authentication resources, including:

•An authentication server, which verifies a user's identity. The PCS forwards credentials submitted on a sign-in page to an authentication server.

•An authentication policy, which specifies realm security requirements that need to be met before the PCS submits credentials to an authentication server for verification.

•A directory server, which is an LDAP server that provides user and group attribute information to the PCS for use in role mapping rules and resource policies (optional).

•Role mapping rules, which are conditions a user must meet for the PCS to map a user to one or more roles. These conditions are based on information returned by the realm's directory server, the person's username, or certificate attributes.

Your PCS is pre-configured with one user realm called “Users.” This predefined realm uses the System Local authentication server, an authentication policy that requires a minimum password length of four characters, no directory server, and contains one role mapping rule that maps all users who sign in to the Users realm to the Users role.

The “testuser1” account you created is part of the Users realm, because this account is created in the System Local authentication server. The “testuser2” account you created is not part of the Users realm, because you create the user account in the new “Test Server” authentication server, which is not used by the Users realm.

You can view the default user authentication realm on the User Authentication Realms page.

To define an authentication realm:

1.In the admin console, choose Users > User Realms.

The User Authentication Realms page appears.

2.Click New.

The New Authentication Realm page appears.

3.Enter Test Realm in the Name box.

4.Select Test Server from the Authentication list.

5.Click Save Changes.

Wait for the PCS to notify you that the changes are saved and to display the realm's configuration tabs.

6.Click the Role Mapping tab if it is not already selected, and then click New Rule.

The Role Mapping Rule page appears.

7.Enter testuser2 in the text box.

8.Under “...then assign these roles”, select Test Role from the Available Roles list and click Add to move it to the Selected Roles box.

9.Click Save Changes.

After completing these steps, you have finished creating an authentication realm. This realm uses Test Server to authenticate users and a role mapping rule to map testuser2 to Test Role. Because the Test Web Access resource policy applies to Test Role, any user mapped to this role cannot access http://www.google.com

Defining a Sign-In Policy

A sign-in policy is a system rule that specifies:

•A URL where a user may sign in to the host.

•A sign-in page to display to the user.

•Whether or not the user needs to type or select an authentication realm to which the PCS submits credentials.

•The authentication realms where the sign-in policy applies.

You can view the default user sign-in policy on the Signing In page. The */meeting sign-in policy is also listed on this page. This policy enables you to customize the sign-in page for Pulse Collaboration meetings.

To define a sign-in policy:

1.In the admin console, choose Authentication > Signing in > Sign-in Policies.

The Signing In page appears.

2.Click */ under User URLs.

The */ page appears.

3.Enter test after */ in the Sign-in URL box.

4.Under Authentication realm, select the User picks from a list of authentication realms option button

5.Select Test Realm from the Available Realms list. Click Add to move it to the Selected Realms box. (Repeat this process for the Users role if it is not already in the Selected Realms box.)

6.Click Save Changes.

After completing these steps, you have finished modifying the default users sign-in policy.

Optional Steps

All PCS devices are pre-configured with one sign-in policy that applies to users:

*/. This default user sign-in policy (*/) specifies that when a user enters the URL to the host, it displays the default sign-in page for the user and requires the user to select an authentication realm (if more than one realm exists). The */ sign-in policy is configured to apply to the Users authentication realm, therefore this sign-in policy does not apply to the authentication realm you created.

Using the Test Scenario

The test scenario enables you to do the following tasks:

•Access the user console using the modified default sign-in policy.

•Sign in as the user created in the Test Server to map to the Test Realm.

•Test your web browsing capabilities, which are dependent upon the proper configuration of Test Role and Test Web Access.

To use the test scenario:

1.In a browser, enter the User URL followed by /test to access the user sign-in page. The URL is in the format: https://a.b.c.d/test, where a.b.c.d is the machine IP address you entered in the serial console during initial configuration.

2.Click Yes when prompted with the security alert to proceed without a signed certificate. If the user sign-in page appears, you have successfully connected to your device.

If you performed the optional configuration steps in "Defining a Sign-In Policy", the header color is red.

3.Enter the username and password you created for the user account in Test Server, type Test Realm in the Realm box, and then click Sign In to access the PCS home page for users.

The PCS forwards the credentials to Test Realm, which is configured to use Test Server. Upon successful verification by this authentication server, the PCS processes the role mapping rule defined for Test Realm, which maps testuser2 to Test Role. Test Role enables web browsing for users.

4.In the browser Address bar, enter the URL to your corporate web site and click Browse. The web page opens in the same browser window, so to return to the PCS home page, click the Home icon in the browsing toolbar that appears on the target Web page.

5.On the PCS home page, type www.google.com and click Browse. An error message appears because the Test Web Access resource policy denies access to this site for users mapped to Test Role.

6.Return to the PCS home page, click Sign Out, and then return to the user sign-in page.

7.Enter the credentials for testuser1, specify the Users realm, and then click Sign In.

8.On the PCS home page, type www.google.com and click Browse. The web page opens in the same browser window.

•The test scenario demonstrates the basic access management mechanisms. You can create very sophisticated role mapping rules and resource policies that control user access depending on factors such as a realm's authentication policy, a user's group membership, and other variables.

•To learn more about access management, we recommend that you take a few minutes to review the Online Help to familiarize yourself with its contents.

•When you configure your device for your enterprise, we recommend that you perform user access configuration. Before you make your device available from external locations, we recommend that you import a signed digital certificate from a trusted certificate authority (CA).

Default Settings for Administrators

Just like for users, the PCS provides default settings that enable you to quickly configure accounts for administrators. This list summarizes the PCS default settings for administrators:

•Administrator roles - There are two built-in administrator roles.

•Administrators - This built-in role permits administrators to manage all aspects of the device. The administrator user you create through the serial console is mapped to this role.

•Read-Only Administrators - This built-in role permits users mapped to the role to view (but not configure) all settings. You need to map administrators to this role if you want to restrict their access.

•Administrator local authentication server is a database that stores administrator accounts. You create the first administrator account in this server through the serial console. (All administrator accounts created through the serial console are added to this server.) You cannot delete this local server.

•Admin Users authentication realm uses the default Administrators local authentication server, an authentication policy that requires a minimum password length of 10 characters, no directory server, and one role mapping rule that maps all users who sign in to the Admin Users realm to the Administrators role. The administrator account you create through the serial console is part of the Admin Users realm.

From 9.1R3 release onwards, minimum password length should be 10 characters when deploying PCS/PPS VA on Azure Cloud, AWS Cloud, or AliCloud.

•*/admin sign-in policy is the default administrator sign-in policy. The */admin specifies that when a user enters the URL to the host followed by /admin, the PCS displays the default sign-in page for administrators. This policy also requires the administrator to select an authentication realm (if more than one realm exists).
The */admin sign-in policy is configured to apply to the Admin Users authentication realm, therefore this sign-in policy applies to the administrator account you create through the serial console.