What are the NSP user management requirements and restrictions?

Remote users in NSP

Remote users have a local account instance created in the NSP database. Remote users appear in Users and System Security, Users list, flagged with the remote authentication source. Remote users continue to use their login credentials, as defined on the remote server. System administrators can edit certain fields of a remote user local account instance, including first and last name, description and email address; see How do I modify a user account?. Remote users are subject to the same global user session limits as locally defined NSP users.

Active Directory

If NSP is configured for remote user authentication with an Active Directory server, the AD users also appear as local accounts in the NSP database. However, AD users are bulk-imported to NSP at system startup. The bulk import of AD users into NSP is automatic and cannot be avoided, but you can manage the scope of the import by defining remote NSP users with a unique distinguished name or user filter, and limiting the user search to that DN only, rather than the subtree.

LDAP, RADIUS, and TACACS

As LDAP, RADIUS, and TACACS users log in to NSP, local account instances are created in the NSP database. Only the remote users that have logged into NSP appear in Users and System Security.

Identity providers

NSP supports Single sign-on (SSO) for NSP users via identity providers (IDPs) that comply with the SAML 2.0 or OpenID Connect standards supported by KeyCloak. The IDP login process may include multi-factor authentication, account verification, and password management policies which are not controlled by any NSP user management settings. IDP users accessing NSP are subject to session management restrictions such as inactivity timeouts and max sessions.

The IDP provides a separate user login interface to grant user access to NSP. The NSP login page is configured with redirect links to one or more IDPs. Users enter their login credentials through the IDP and are then redirected to the NSP GUI. NSP also supports OpenID Connect user access to the NSP OSS with a foreign access token.

The following limitations apply to OpenID Connect OSS users:

  • Enforcement of maximum OSS sessions is supported.

  • Use of the NSP default user group is supported for OpenID Connect accounts with no user group (assuming that a default user group is configured in NSP).

  • Access control with RBAC permissions is supported for APIs.

Using multiple remote authentication sources

Consider the following information when working with multiple remote authentication sources.

LDAP (including Active Directory)

  • User accounts should not be duplicated across multiple LDAP servers. Local user account instances are associated to the highest-priority authentication source they exist on, and there is no login failover for a user to a different LDAP server.

  • When an LDAP source is configured as unavailable or is unreachable by NSP, all local users for that source are suspended and unable to login to NSP. Users on other LDAP authentication sources will still be able to login.

Note: In an NSP deployment that uses Keycloak with multiple LDAP servers, if the highest-priority LDAP server goes down, users on the second LDAP server will only be able to login to NSP if they already have a local account instance created in the Keycloak database. Otherwise, their login attempts will fail.

As a workaround for this scenario, an administrator can disable the operationally-down LDAP server as an authentication source. Then, users on the second LDAP server can login, even if they do not have a local account instance.

RADIUS and TACACS

  • Multiple RADIUS or TACACS servers are supported. The address field supports multiple comma-separated address:port entries. Each server entry requires a shared secret. The secret field is a comma separated list, and the number of entries must match the numbers of servers in address field. The secret for any server must not contain a comma character.

  • The RADIUS server port must be for RADIUS authentication and authorization (default port 1812). The RADIUS accounting port (default port 1813) is not supported.

  • Only RADIUS or TACACS servers can be configured, not RADIUS and TACACS.

  • A RADIUS/TACACS configuration can be enabled or disabled, but not individual servers in a multi-server configuration.

  • If a RADIUS/TACACS configuration is disabled, then all local users associated with the server configuraton will be suspended and unavailable for login to NSP.

  • In a multi-server configuration, if the first server is unreachable, the second server is used, and so on.

  • A user account can be duplicated across multiple servers, but it must have the same user group assignment on each server.

E-mail verification

After you enable the Verify Email setting, each local and remote NSP user with a configured e-mail address—not just new users—must complete a verification process. During a subsequent login attempt, the sign-in page directs the operator to open a verification e-mail and click on the enclosed link to complete the process.

After the verification, the user account is tagged as ‘email verified’, and no further verification is required, even if the e-mail address changes.

Note: In order to acquire an API access token, an OSS user that has an e-mail address must first complete the e-mail verification process by signing in to the NSP UI.

Forgotten passwords

The NSP sign-in page has a Forgot Password option. If a user clicks this option, they are prompted for their username. A message "You should receive an e-mail shortly ..." appears on the sign-in page. In order to ensure that the Forgot Password option works for local users, configure all local user accounts with e-mail addresses. The Forgot Password feature functions only for local NSP users; remote users cannot reset a password through NSP.

User account lockout messaging

The NSP provides the ability to automatically send an e-mail message to users whose accounts have been locked. A user receives an e-mail when they are temporarily or permanently locked out through Brute Force Detection protection mechanisms. Local user accounts must be configured with an e-mail address to be sent lockout messages.

The lockout e-mail function is enabled through the NSP system settings; see How do I configure an e-mail server for notifications?. You can specify the Subject line and body text for the e-mail message.

Note: Lockout messages are not sent to users whose accounts have been set to Suspended status by an administrator. That is a separate function.