---
title: User Verification and Key Concepts
slug: ps/help/en_us/ics/25x/ag/user-verification-and-key-concepts
docTags: 
createdAt: 2026-08-27T06:20:55.735Z
---

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 Ivanti 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 ICS opens the web page in the same browser window, so to return to the ICS 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 ICS 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 ICS home page.
11. Click **Browsing > Windows Files** on the ICS home page to browse through available Windows file shares.

### Creating a Test Scenario to Learn Concepts and Best Practices

The ICS 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 ICS 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 ICS supports two types of users:

- **Administrators**-An administrator is a person who may view or modify ICS's configuration settings. You create the first administrator account through the serial console.
- **Users**-A user is a person who uses the ICS 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 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 ICS 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 ICS grants access to a resource or performs an action. Note that the ICS 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.

:::hint{type="info"}


- For a fresh installation, this predefined "Initial Policy for Local Resources" policy is in "Deny" state by default.
- To allow access to IPv6 hosts belonging to domains within the secured network, add the \[fd00\::/8]:\*/\* resource to the predefined Web Access resource policy, if not present already.


:::

**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.

:::hint{type="info"}


- For a fresh installation, this predefined "Initial File Browsing Policy" is in "Deny" state by default.
- Delete the Windows Access resource policies if you are concerned about users having access to all your web and file content.


:::

To define a resource profile:

1. In the admin console, choose **Users > Resource Profiles > Web.**
2. Click **New Profile.**

:::Paragraph{indent="1"}
The **Web Applications Resource Profile** page appears.
:::

3. Fill in the following information:
   - In the **Type** box, keep the default option (**Custom**).
   - In the **Name** box, type **Test** **Web Access**.
   - In the **Base URL** box, type [http://www.google.com](https://www.google.com/?gws_rd=ssl)
   - Under **Autopolicy: Web Access Control**, select the check box next to the default policy (http\://www\.google.com:80/\*) and choose **Delete**.
   - In the **Resource** box, type [http://www.google.com,](https://www.google.com/?gws_rd=ssl) select **Deny** from the **Action** list, and click **Add**.
   - Click **Save** and **Continue**. The Test Web Access page appears.
   - Click the **Roles** tab.
   - Select **Test Role** in the **Available Roles **box and click **Add** to move it to the **Selected Roles** box.
   - Click **Save** **Changes**.

The ICS 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 ICS 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. ](https://www.google.com/?gws_rd=ssl)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 ICS.

### 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 ICS forwards the user's credentials to this authentication server to verify the user's identity.

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

The ICS 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.

:::hint{type="info"}
The ICS 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**.

:::Paragraph{indent="1"}
The New Local **Authentication** page appears.
:::

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

:::Paragraph{indent="1"}
Wait for the ICS to notify you that the changes are saved, after which additional configuration tabs appear.
:::

4. Click the **Users** tab and then click **New**.

:::Paragraph{indent="1"}
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 ICS 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 ICS 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 ICS for use in role mapping rules and resource policies (optional).
- Role mapping rules, which are conditions a user must meet for the ICS 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 ICS 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**.

:::Paragraph{indent="1"}
The User Authentication Realms page appears.
:::

2. Click **New**.

:::Paragraph{indent="1"}
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**.

:::Paragraph{indent="1"}
Wait for the ICS 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 Rul**e.

:::Paragraph{indent="1"}
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 ICS submits credentials.
- The authentication realms where the sign-in policy applies.

To define a sign-in policy:

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

:::Paragraph{indent="1"}
The Signing In page appears.
:::

2. Click **\*/** under User URLs.

:::Paragraph{indent="1"}
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.**

:::Paragraph{indent="1"}
After completing these steps, you have finished modifying the default users sign-in policy.
:::

:::Paragraph{indent="1"}
**Optional Steps**
:::

:::Paragraph{indent="1"}
You can perform these following optional steps to define a new sign-in page that is associated with the \*/test/ sign-in policy.
:::

7. Select **Authentication > Signing In > Sign In Pages,** and then click** New Page**.
8. Enter **Test Sign-in Page** in the **Name** field, type **#FF0000 (red)** in the **Background color **box, and then click **Save Changes**.
9. Select **Authentication > Signing In > Signing In Policies**, and then click **New URL.**

:::Paragraph{indent="1"}
The New Sign-In Policy page appears.
:::

10. Type **\*/test/** in the **Sign-in URL** box.
11. Select **Default Sign-in Page** from the **Sign-in Page **list, and click **Save Changes**.
12. Select **Authentication > Signing In > Sign In Policies**, and then click **\*/test/ under User URLs**.

:::Paragraph{indent="1"}
The \*/test/ page appears.
:::

13. Select **Test Sign-in Page from the Sign-in page** list and then click **Save Changes**.

All ICS 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

:::Paragraph{indent="1"}
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.

:::hint{type="info"}
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 ICS home page for users.

:::Paragraph{indent="1"}
The ICS forwards the credentials to Test Realm, which is configured to use Test Server. Upon successful verification by this authentication server, the ICS 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 ICS home page, click the Home icon in the browsing toolbar that appears on the target Web page.
5. On the ICS 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 ICS 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 ICS 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

:::Paragraph{indent="1"}
Just like for users, the ICS provides default settings that enable you to quickly configure accounts for administrators. This list summarizes the ICS 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.

:::hint{type="info"}
Minimum password length should be 10 characters when deploying ICS VA on Azure Cloud or AWS Cloud.
:::

- \*/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 ICS 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.