Users & groups

Use this section to manage users and groups that can be given access to the Management Console and projects. The security model is role-based; after you create a user, you need to add the user to one or more groups associated with specific roles in one or more projects.

We recommend that you create groups first, because a user cannot log in until the user is added to a group that is granted a Viewer role inside at least one project.

The section contains two tabs:

  • The Users tab helps you create new users and edit, remove, and reset passwords for selected users.
  • The Groups tab helps you create, remove, and edit groups.

User and group names in Kofax RPA must follow the Rules for Logon Names for Microsoft Windows. Such as the names must not contain the following characters:

" / \ [ ] : ; | = , + * ? < >

For information, see Creating User and Group Accounts on technet.microsoft.com.

You can change the way the information for each tab is presented as follows:

  • Filter the lists in the table by applying filters in the Filter text field. See Filtering for more information.
  • Select the table columns to be displayed using the menu icon on the right.
  • Refresh the displayed information by clicking the refresh icon on the right.
  • Reset the custom column settings by clicking the reset icon on the right.
  • Select the number of items to display per page and navigate among pages by using the navigation menu in the bottom right corner.

Users

By default, the following table columns are displayed for each user.

Column Description
User name Name of the user.
User origin Origin of the user depending on the user creation method.
  • unknown: The user is created after restoring a backup.

    If you do not use any of the external identity providers, such as SAML, LDAP, or SiteMinder, you can change unknown origin to internal by clicking Set internal origin for the selected user.

  • internal: The user is created manually on the Users & Groups page.

  • saml: The user is created after logging via SAML.

  • site minder: The user is created after logging via SiteMinder.

  • ldap#{ldapDirectoryIdentifier}: The user is created after logging via LDAP.

For more information about external identity providers and user authentication, see Tomcat Management Console > Advanced Configuration in the Kofax RPA Administrator's Guide.

Full name Full name of the user.
Email Email address of the user.
Login count Number of sessions done by this user.
Last login Date and time when the user last logged in.
Last IP address Last IP address that the user logged in from.
Groups Groups that the user belongs to.

Create New User

If you do not have required groups yet, we recommend that you create them first, because a user cannot log in until the user is added to a group that is granted a Viewer role inside at least one project.

  1. On the Users tab, click the plus sign.

    The "Create new user" dialog box appears.

  2. Specify a user name, password, full name, and email for the user and then select a group or multiple groups that the user will belong to.

  3. Click OK.

    The user appears in the table.

You can edit a user from the context menu.

Groups

By default, the following information is displayed for each group.

Column Description
Group name Name of the group.
Description Description of the group.
Number of users Number of users contained in the group.
Used in projects Projects using this group.

Create New Group

  1. On the Groups tab, click the plus sign.

    The "Create new group" dialog box appears.

  2. Specify a group name, description, and select the users to be included in this group.

  3. Click OK.

    The group appears in the table.

You can edit a group from the context menu.

Reset Password for User
  1. On the Users tab, select the user and click in the upper left corner.

    The "Reset password for" dialog box appears.

  2. Type the new password, type it again to confirm, and then click OK.

    You may select to send an email so the user receives a notification about the password change. The "From address" needs to be pre-configured to send notifications.

Built-in roles

Management Console provides some built-in roles that users can have. Roles are mapped to a user of a security group. User permissions are calculated based on the roles that are mapped to security groups the user is a member of. You can modify built-in roles or add additional roles.

A user cannot assign roles with permissions that this user does not have. For example, Project Administrator cannot assign Kapplet Administrator, Kapplet User, and Process Discovery Client roles.

  • Project Administrator: A user with this role administrates one or multiple projects and has a right to assign a role to a group for these projects. This user has a view right to view RoboServer and cluster settings without changing them. Project Administrator is not a member of the RPA Administrators group (for more information, see later in this section).
  • Developer: Developers have a right to upload, download, and view all resource types in the repository. A user with this role can create, edit, and delete schedules, run robots, view run logs and clusters.
  • Viewer: Viewers have similar view rights as developers and the rights to change or run anything.
  • API (This user logs in only as a service authenticating via the API): A user with this role can use the repository API to read from and write to the repository. A user with this role cannot run robots using REST but is able to run robots using RQL.
  • RoboServer (This user logs in only as a service authenticating via the API): A restricted user that can only read from the repository. This role is used by RoboServers when accessing a cluster, retrieving repository items, and requesting passwords from the password store.
  • Kapplet Administrator: A user who can create, view, run, and edit Kapplets.
  • Kapplet User: A user who can view and run Kapplets. A user with this role cannot access Management Console if this user has no other rights.

    For more information on Kapplets user roles, see Users and User Groups.

  • Kapplets Service User: A user who can only read from the repository. This role is used only to retrieve information about available robots, types, snippets, and resources for the given project and thus is used only for the communication purposes communication between Kapplets and Management Console. This role is automatically applied to all Management Console projects.
  • Password Store client: A user with this add-on role can access the password store. The role is provided on top of other roles, just like the Developer role. This role only provides access to the password store in Management Console.
  • DAS Client User (This user logs in only as a service authenticating via the API): This is a user that is created for remote Desktop Automation Service (DAS) clients, and can only access the DAS API. The DAS client user has a right to announce a DAS to Management Console, and retrieve DAS configuration.
  • VCS Service User (This user logs in only as a service authenticating via the API): The version control service user is granted a special set of rights for the Synchronizer. This role has a right to add, modify, and delete resources. This is the only role that can deploy on behalf of another user to use the "deployer" feature in the version control service.
  • Process Discovery Client (This user logs in only as a service authenticating via the API): This role allows Process Discovery components interact with Management Console.

Built-in "admin" user

admin is a superuser that has access to everything. It is not a member of the RPA Administrators group and cannot be a member of any group. The default admin user password is available (user name - admin, password - admin). You can change the admin user password as described in "Reset password for user" in this section.

In an LDAP integration setup, the admin group is defined as part of the LDAP configuration. admin can then log in and define which LDAP groups should be mapped to the Developer, Project Administrator, RoboServer, and other roles.

In an internal user setup, the admin user is created at first start and can then login and create Administrators, Developers, and other users.

Built-in "admin" user special rights

Beside being the initial user, admin also has special rights, such as:

  • In the RoboServers section, admin can click a RoboServer node and request a stack trace from the corresponding RoboServer.

  • Only admin can create and import backups.

  • In the password store, admin can move passwords to another project.

Built-in group
RPA Administrators: Users belonging to this group have all rights for all projects (excluding special admin user rights), such as creation of new administrators and users in any project. To make a user an administrator, the user has be added to this group.

  • The RPA Administrators group is visible when the internal user management is enabled, and it is empty by default.

  • When restoring a backup created in version prior to 10.7, users with Administrator role become members of the RPA Administrators group.

User management principles

The following information can help you understand some Kofax RPA user management principles.

There are two ways to run Management Console: embedded in a RoboServer with any license and on a standalone Tomcat server (requires enterprise license). For information about Management Console on Tomcat, see "Tomcat Management Console" in Kofax RPA Administrator's Guide.

When Management Console runs in embedded mode, user management is turned on by default to mitigate the potential security risk of having an unauthorized access to a Management Console from other computers. The default administrator name and password are set as follows:

  • User name: admin

  • Password: admin

To change the admin name and password, do the following:

  1. On the Users tab, select the user and click in the upper left corner.

    The "Reset password for" dialog box appears.

  2. Type the new password, type it again to confirm, and then click OK.

    You may select to send an email so the user receives a notification about the password change. The "From address" needs to be pre-configured to send notifications.

    Once you change the password, update the login information in the RoboServer settings.

  3. Start the RoboServer Settings application either by clicking RoboServer Settings on the Windows Start menu or by double-clicking RoboServerSettings.exe in the /bin subfolder of the Kofax RPA installation folder.
  4. On the General tab under Register to a Management Console, specify the new password for Management Console to register to. Click OK to save the changes.
  5. Restart Management Console for the changes to take effect.

    Depending on your license and the way you run Management Console, you can manage user access as follows:

    • Internal user management: Available in both Embedded and Standalone mode

    • External user management (LDAP, SAML, or CA Single Sign-On): Only available in Standalone mode with enterprise license

    When you run the Enterprise version on a Tomcat server, Management Console is always in the multi-user mode and you can choose to manage your users either in Management Console (like in the embedded mode) or get the user credentials from your corporate LDAP server. The authentication method is displayed in the User origin column.

    Check for login attempts

    By default, the check for number of login attempts made by a user and wait time before the next attempt is disabled. To enable this functionality, edit the following section in the authentication.xml file located in: <Tomcat installation folder>\WebApps\Management Console\WEB-INF\spring

    
       <bean id="loginAttemptService"
             class="com.kapowtech.scheduler.server.spring.security.LoginAttemptService" lazy-init="true">
           <constructor-arg type="boolean" value="false"/>
           <constructor-arg type="int" value="3"/>
           <constructor-arg type="int" value="10"/>
       </bean>

    Set the first value to true. The second and third values are for the number of login attempts (3 in this example) and the wait time in minutes before the next attempt (10 in this example), respectively.