Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

User Authentication

When authentication is configured and a user enters an invalid username and password combination, a message is displayed to indicate that the login was invalid.

If the user attempts to access the system multiple times with invalid information, the user must wait the configured amount of time before they can attempt to access the system again. You can configure console settings to determine the maximum number of failed logins, and other related settings. For more information about configuring console settings for authentication, see JSA System Time.

JSA supports the following authentication types:

  • System authentication - Users are authenticated locally. System authentication is the default authentication type.

  • RADIUS authentication - Users are authenticated by a Remote Authentication Dial-in User Service (RADIUS) server. When a user attempts to log in, JSA encrypts the password only, and forwards the username and password to the RADIUS server for authentication.

  • TACACS authentication - Users are authenticated by a Terminal Access Controller Access Control System (TACACS) server. When a user attempts to log in, JSA encrypts the username and password, and forwards this information to the TACACS server for authentication. TACACS Authentication uses Cisco Secure ACS Express as a TACACS server. JSA supports up to Cisco Secure ACS Express 4.3.

  • Microsoft Active Directory - Users are authenticated by a Lightweight Directory Access Protocol (LDAP) server that uses Kerberos.

  • LDAP - Users are authenticated by an LDAP server.

  • SAML single sign-on authentication – Users can easily integrate JSA with your corporate identity server to provide single sign-on, and eliminate the need to maintain JSA local users. Users who are authenticated to your identity server can automatically authenticate to JSA. They don't need to remember separate passwords or type in credentials every time they access JSA.

Prerequisite Checklist for External Authentication Providers

Before you can configure an authentication type, you must complete the following tasks:

  • Configure the authentication server before you configure authentication in JSA. For more information, see your server documentation.

  • Ensure that the server has the appropriate user accounts and privilege levels to communicate with JSA. For more information, see your server documentation.

  • Ensure that the time of the authentication server is synchronized with the time of the JSA server.

  • Ensure that all users have appropriate user accounts and roles to allow authentication with the vendor servers.

Configuring Inactivity Timeout for a User

If you have users who require longer periods of inactivity before they are logged out of the system, you can configure their inactivity timeout threshold individually.

  1. On the Admin tab, click Users.

  2. Select a user from the list and click Edit.

  3. In the User Details pane, enable the Override System Inactivity Timeout setting.

  4. Enter the number of minutes of inactivity before the user is logged out, and click Save.

External Authentication Guidelines

You can configure an external authentication provider to allow JSA to authenticate users without JSA storing passwords locally for those users.

Note:

You cannot configure more than one external authentication provider for JSA at a time. If you have set up one external authentication provider and you set up another external authentication provider, the configuration for the first external authentication provider is deleted.

When you choose to use an external authentication provider, consider these points:

  • Ensure that your external provider is trustworthy because you are delegating an important security decision to this external provider. A compromised provider might allow access to your JSA to unintended parties.

  • Ensure that the connection to the external provider is secure. Choose only secure communications protocols, by using LDAPS instead of LDAP, for example.

  • Consider whether you want to enable a local authentication fallback in case the external provider is unavailable. If the external provider is compromised, it might be used as a denial of access attack.

  • The decision to configure an external authentication provider applies to all administrator and nonadministrator JSA users. There is no such thing as a "local-only user" in JSA.

  • If you enable auto-provisioning of JSA accounts, a compromised provider might be used to force the creation of a rogue JSA account, so use caution when you are combining these features.

  • JSA users that do not have an entry in the external provider are relying on the fallback feature to check the local password. A compromised external authentication provider might be used to create a "shadow" for an existing JSA account, providing an alternative password for authentication.

Local authentication fallback

Each non-administrator user can be configured for local authentication fallback. Local authentication fallback is turned off by default. If enabled, a non-administrator JSA user can access the system by using the locally stored password even if the external provider is unavailable, or if the password in the external provider is locked out or is unknown to the user. This also means that a rogue JSA administrator might change the locally stored password and log in as that user, so ensure that your JSA administrators are trustworthy. This is also the case if an external authentication provider is not configured.

The default administrator account, named admin, is always configured for local authentication fallback by default. This prevents the administrative user from being locked out of the system, but also means you must ensure that the configured external authentication provider has the correct entry for the admin user, and that the password is known only to the authorized JSA administrator. If you cannot maintain control of the admin entry in the external authentication provider, disable the admin account within JSA to prevent unauthorized users from logging in to JSA as admin. When you enable autoprovisioning, such as when you use LDAP group authentication, any user account that matches the LDAP query are created or reactivated with the appropriate roles as mapped. To prevent this from happening, disable auto-provisioning by using LDAP local.

For other privileged JSA users (users with the admin role), you can choose on a user-by-user basis whether to enable local authentication fallback. The ENABLE_FALLBACK_ALL_ADMINS setting (disabled by default) can be used to force all privileged users to use local authentication fallback. If local authentication fallback is configured, the same considerations apply as for the admin account.

When you configure an external authentication provider and create a new user, that user doesn't automatically have a local password set for JSA. If a user needs a local password, then you must configure local authentication fallback for that user. Local authentication fallback allows a user to authenticate locally if external authentication fails for any reason, including invalid passwords. Fallback users can then access JSA regardless of the state of the external authentication.

Even if local authentication fallback is enabled for a user account, JSA first attempts to authenticate the user to the external authentication module before it attempts local authentication. When external authentication fails, JSA automatically attempts to authenticate locally if local authentication fallback is enabled for that user. User accounts cannot be configured only to authenticate locally when an external authentication provider is configured. For this reason, it is important that all JSA user accounts correspond to an external authentication provider account of the same name associated with the same authorized user.

Ensure that the external authentication provider is trustworthy, as this configuration outsources a security decision and a rogue authentication admin can allow unauthorized access to your JSA. Make this connection in a secure way, by using the secure version of protocols (for example by using LDAPS rather than LDAP).

Local authentication fallback is not available with SAML authentication. No users are able to authenticate locally when you use SAML authentication.

When offboarding users, disable local authentication fallback for that user before you remove their authentication access from the external authentication provider.

Configuring System Authentication

You can configure local authentication on your JSA system. You can specify length, complexity, and expiry requirements for local passwords.

The local authentication password policy applies to local passwords for administrative users. The policy also applies to non-administrative users if no external authentication is configured.

When the local authentication password policy is updated, users are prompted to change their password if they log in with a password that does not meet the new requirements.

  1. On the Admin tab, click Authentication.

  2. Click Authentication Module Settings.

  3. Optional: From the Authentication Module list, select System Authentication.

    System authentication is the default authentication module. If you change from another authentication module, then you must deploy JSA before you do the next steps.

  4. Click Save Authentication Module.

  5. Click Home.

  6. Click Local Password Policy Configuration.

  7. Select the password complexity settings for local authentication.

Configuring RADIUS authentication

You can configure RADIUS authentication on your JSA system.

  1. On the navigation menu (), click Admin.

  2. Click System Configuration >User Management > Authentication.

  3. From the Authentication Module list box, select RADIUS Authentication.

  4. Configure the parameters:

    1. In the RADIUS Server field, type the host name or IP address of the RADIUS server.

    2. In the RADIUS Port field, type the port of the RADIUS server.

    3. From the Authentication Type list box, select the type of authentication you want to perform.

      Choose from the following options:

      Option

      Description

      CHAP

      Challenge Handshake Authentication Protocol (CHAP) establishes a Point-to-Point Protocol (PPP) connection between the user and the server.

      MSCHAP

      Microsoft Challenge Handshake Authentication Protocol (MSCHAP) authenticates remote Windows workstations.

      ARAP

      Apple Remote Access Protocol (ARAP) establishes authentication for AppleTalk network traffic.

      PAP

      Password Authentication Protocol (PAP) sends clear text between the user and the server.

    4. In the Shared Secret field, type the shared secret that JSA uses to encrypt RADIUS passwords for transmission to the RADIUS server.

  5. Click Save Authentication Module.

Configuring TACACS authentication

You can configure TACACS authentication on your JSA system.

  1. On the navigation menu (), click Admin.

  2. Click System Configuration >User Management > Authentication.

  3. From the Authentication Module list box, select TACACS Authentication.

  4. Configure the parameters:

    1. In the TACACS Server field, type the host name or IP address of the TACACS server.

    2. In the TACACS Port field, type the port of the TACACS server.

    3. From the Authentication Type list box, select the type of authentication you want to perform.

      Choose from the following options:

      Option

      Description

      ASCII

      American Standard Code for Information Interchange (ASCII) sends the user name and password in clear text.

      PAP

      Password Authentication Protocol (PAP) sends clear text between the user and the server. PAP is the default authentication type.

      CHAP

      Challenge Handshake Authentication Protocol (CHAP) establishes a Point-to-Point Protocol (PPP) connection between the user and the server.

      MSCHAP

      Microsoft Challenge Handshake Authentication Protocol (MSCHAP) authenticates remote Windows workstations.

      MSCHAP2

      Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAP2) authenticates remote Windows workstations by using mutual authentication.

      EAPMD5

      Extensible Authentication Protocol using MD5 Protocol (EAPMD5) uses MD5 to establish a PPP connection.

    4. In the Shared Secret field, type the shared secret that JSA uses to encrypt TACACS passwords for transmission to the TACACS server.

  5. Click Save.

Configuring Active Directory authentication

You can configure Microsoft Active Directory authentication on your JSA system.

  1. On the navigation menu (), click Admin.

  2. Click System Configuration >User Management > Authentication.

  3. From the Authentication Module list box, select Active Directory.

    Configure the parameters:

    1. In the RADIUS Server field, type the host name or IP address of the RADIUS server.

    2. In the RADIUS Port field, type the port of the RADIUS server.

    3. From the Authentication Type list, select Active Directory and configure the following parameters.

      Configure the following parameters:

      Parameter

      Description

      Server URL

      Type the URL used to connect to the LDAP server, for example, ldaps://host:port.

      LDAP Context

      Type the LDAP context you want to use. For example, DC=JSA,DC=INC.

      LDAP Domain

      Type the domain that you want to use. For example, jsa.inc.

  4. Click Authentication Module.

Related Documentation