Understanding User Accounts

Download this manual as a PDF file

This section describes the types of user accounts, access keys and user policies, and how the latter two affect user accounts.

Use the following menu options to navigate the SL1 user interface:

  • To view a pop-out list of menu options, click the menu icon ().
  • To view a page containing all of the menu options, click the Advanced menu icon ().

What is a User Account?

A user account allows you to access SL1 GUI. You access this GUI by opening a browser session and connecting to an Administration Portal. From the GUI, you can interact with SL1, view data, status, and reports, and define policies, as well as administer SL1.

Users and Organizations

For an overview of the relationship between an organization and its users, see the section on Organizations and Their Relationships.

Account Types

In SL1, there are two broad types of user accounts:

  • Administrators. By default, users of type "administrator" are granted all permissions available in SL1. Administrators can access all tabs and pages, and perform all actions and tasks on all entities, regardless of organization.

  • Users. Accounts of type "user" are assigned key privileges. Key privileges are customizable by the administrator and grant users access to pages and tabs and permit users to view information and perform tasks in SL1. These key privileges are defined by the SL1 system administrator from the Access Keys page (System > Manage > Access Keys).

For more information, see the section on Access Permissions.

An account of type "user" can be granted the privileges that allow him/her to create or modify other users' accounts. However, for accounts of type "user", certain restrictions apply:

  • An account of type "user" cannot create or modify an account of type "administrator".
  • An account of type "user" cannot change his/her own account to type "administrator" or change another user's account to type "administrator".
  • An account of type "user" cannot add additional Access Keys to his/her own account.
  • An account of type "user" cannot grant or remove Access Keys to other accounts that he/she has not also been granted.

Regardless of access keys, accounts of type "user" can access only pages and actions associated with their organization. For example:

  • Suppose your organization includes three regional offices. Suppose you define three organizations: Northeast, Headquarters, and West Coast.
  • Suppose each organization includes the hardware located at the corresponding office.
  • Now suppose the account "JohnDoe" is of type "user" and is a member of the organization "West Coast". User JohnDoe would be able to view and act upon only devices that are included in the organization "West Coast". User JohnDoe would not be able to view or act upon the hardware at the other offices.
  • SL1 allows you to assign each user a primary organization and optional additional organizations.
  • Now suppose that user "JohnDoe" needs to view the status of a device at headquarters. If you add "Headquarters" as a secondary organization in JohnDoe's account information, that user will now be able to view and act upon all the devices in the "Headquarters" organization.

NOTE: You can use Access Keys to further limit the access of each user, even within his/her own organization.

Organizations also affect credentials. To support multi-tenancy, SL1 allows credentials to be aligned with organizations.

  • For each credential that is aligned with an organization, only administrators and users who are members of the aligned organization will be able to see the credential in the Credential Management page.

  • In SL1, in any field or column that displays the name of the credential, users who are not members of the aligned organization will not see the credential name. Instead, these users will see either a dash character (-) or the text "Restricted Credential".
  • In SL1, in any list from which users can select a credential, users who are not members of the aligned organization will not see the credential as an entry in the list.

To learn more about credentials, see the Discovery and Credentials section.

Understanding Access Keys

There are two broad types of user accounts: administrators and users.

By default, users of type "administrator" are granted all permissions available in SL1. Administrators can access all tabs and pages and perform all actions and tasks.

Accounts of type "user" are assigned privileges. These privileges are defined by the SL1 system administrator in the Access Keys page (System > Manage > Access Keys). Access Keys are customizable by the administrator, grant users access to pages and tabs, and permit users to view information and perform tasks in SL1.

Access Keys control the pages a user can navigate to and the actions the user can perform in each page. For details on access keys, see the Access Permissions section.

Understanding User Policies

User Policies allow you to define a custom set of account properties and privileges (from the Account Permissions page) and then save them as a policy, for reuse. When you create a user account, you can use the User Policy to quickly apply settings to the new account.

A user policy allows you to define:

  • Login State
  • Authentication Method
  • Ticket Queue Memberships
  • Primary Organization and Additional Organization Memberships
  • Theme
  • Time Zone
  • Privilege Keys

User Policies have a dynamic relationship with their member user accounts. You can make a change to a user policy and SL1 will automatically update the account settings for each member account.

For example:

  • Suppose you create a user account called "John Doe" on the first of the month and use the user policy named "NOC users" to create the user account.

  • Suppose you create another user account called "Jane Smith" on the fifth of the month and again use the user policy "NOC users".
  • Suppose on the 15th of the month, you add an additional Key Privilege to the "NOC users" policy.
  • That additional Key Privilege will appear in the account for John Doe and Jane Smith as soon as the "NOC users" policy is saved.

If you create a user account with a user policy, the fields in the Account Permissions page for that user account are grayed out. If you want to manually edit fields in the Account Permissions page for the user account, you must disassociate the user account from the user policy. Any future changes made to the user policy will not appear in the disassociated user account.

If you want to automatically import user accounts from LDAP or Active Directory, you must create at least one user policy. To use user policies in this way, special configuration is required. This configuration is described in the Using LDAP or Active Directory section.

For details on creating a user policy, see the section on user policies.

Understanding User Sessions

SL1 lets multiple users log into the same SL1 system at the same time. The time a user spends logged into SL1 is known as a user session. You can end a user's session in SL1, and you can also limit the number of users that can be simultaneously logged into an SL1 system.

The Access Sessions page allows administrators to monitor user logins and logouts to the user interface.

From this page, you can also:

  • End a user's session.
  • View a list of accounts that are locked out of the user interface due to invalid username and password.
  • Unlock accounts that are locked out of the user interface.

Viewing Information about Each Access Session

The Access Sessions page displays a list of recent logins to the user interface. To view the Access Sessions page:

  1. Go to the Access Sessions page (System > Monitor > Access Logs).
  1. For each session, the Access Sessions page displays:
  • User Account. Username of person logging in to the user interface.
  • User Display Name. The username, email address, or preferred display name. This value is determined by the user's authentication resource settings.
  • Last Address. IP address from which the user accessed the user interface.
  • State. Current status of the user. The choices are:
  • Active. User is currently logged in to the user interface.
  • Expired. User's session in the user interface was killed.
  • Logged Out. User logged out of the user interface.
  • Never Used. User logged in to the user interface and did not perform any tasks before the session was killed.
  • Login Time. Date and time at which the user logged in.
  • Last-Hit Time. Date and time at which the user last loaded a page in the user interface.
  • Logout Time. Date and time at which the user logged out.
  • Session Duration. Length of time between login and logout.
  • Session ID. Unique numeric ID assigned to each user session.

Deleting a User's Session

From the Access Sessions page, you can end a user's session in the user interface. The user must log in again to access the user interface. The status of the session will be "expired".

To end a user's session:

  1. Go to the Access Sessions page (System > Monitor > Access Logs).
  1. In the Access Sessions page, find the session you want to end. Click the checkbox () for that session.
  2. Click the Select Actions field (in the lower right of the page) and then select Kill user session. Click the Go button
  3. Each selected session is ended. The user associated with each selected session is logged out of the user interface. The status of the session changes to "expired".

NOTE: After ending a user's session, that user can immediately log in to the user interface again. To prevent a user from logging in to the user interface, you must disable the user's account. For information on user accounts, see the Organizations and Users section.

Limiting the Number of Simultaneous User Sessions

Starting with SL1 12.1.1, the maximum number of simultaneous user sessions was set to 300 by default. If you get an "HTTP Response code was 429 (Too Many Requests)" error or a "User sessions at maximum" in SL1, you can adjust the USER_MAX_SESSIONS value in the /opt/em7/nextui/nextui.conf file:

  1. SSH to the SL1 appliance and log in as user em7admin.

  2. At the command line, open the nextui.conf file in the vi editor:

    sudo vi /opt/em7/nextui/nextui.conf

  3. In the NextUI configuration file, set a new value for USER_MAX_SESSIONS, such as USER_MAX_SESSIONS=1000 for 1,000 concurrent user sessions.

  4. Save your changes and restart the NextUI service:

    sudo systemctl restart nextui

Viewing Lockouts and Unlocking Lockouts

If a user enters incorrect login information multiple times in a row, that username, the user's IP address, or both will be locked out of the user interface.

To view lockouts or restore login privileges to locked out users:

  1. Go to the Access Sessions page (System > Monitor > Access Logs).
  2. In the Access Sessions page, click the Lockouts button.
  3. The Account Lockouts modal page allows administrators to view a list of locked-out accounts and to restore login privileges to locked out users.
  4. The Account Lockouts modal page displays the following about each lockout:
  • Attempt Account. Username that caused the lockout.
  • From Address. IP address from which the failed login attempts originated.
  • Attempt Time. Date and time at which lockout occurred.
  • Tries. Number of times user tried to log in to the user interface.
  1. To remove the lock for the user account and allow logins from the username and/or IP address, click the bomb icon ().

Global Settings for Lockouts

The platform includes global settings that define how lockouts behave. In the Behavior Settings page (System > Settings > Behavior), the following fields affect lock-outs:

  • Account Lockout Type
  • Account Lockout Attempts
  • Account Lockout Duration
  • Lockout Contact Information

Audit Logs

For additional information about users and their actions in the platform, you can view the Audit Logs page. The Audit Logs page provides a complete audit trail for the platform. The Audit Logs page displays a record of all actions in the platform that are generated by users or by managed elements. For details, see the section on Audit Logs.

Understanding Authentication

Authentication is the method by which SL1 determines if a user can access the SL1 system. There are three methods of authentication:

  • EM7 Session. An administrator must define the user account in SL1. The user account has a username and password. During login, SL1 checks its own databases to make sure the username and password are legitimate and accurate.
  • LDAP/Active Directory. If the user has an account in Active Directory or on an LDAP server, the user can log in to SL1 with the AD or LDAP username and password. SL1 will communicate with Active Directory or the LDAP server to determine if the username and password are legitimate and accurate.
  • SSO Authentication. If the user has a Single Sign-On (SSO) account, the user can enter a URL to access SL1. A SAML IdP will authenticate the user with the user's browser acting as an intermediary. If the user is already logged in to the SAML IdP, SL1 will display the default page for the user. If the user is not yet logged in to the SAML IdP, the user will be prompted to log in to the SAML IdP and then redirected to the default page in SL1.

NOTE: To use Active Directory authentication or LDAP authentication, special configuration is required. For details, see the Using LDAP or Active Directory section.

NOTE: To use SSO authentication, special configuration is required. For details on configuring SL1 to use SSO authentication, see the section on using Using Single Sign-On (SSO).