This documentation applies to the 8.0 version of Remedy Action Request System, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Server configuration settings

Several server configuration settings affect the operation of the system in relationship to the AREA plug-ins. Some are related only to the AR System server while others are associated with how AR System interacts with the AREA environment. This section introduces and discusses interaction with SSO/login intercept authentication for the following options:

  • Cross-reference blank passwords
  • Authenticate unregistered users
  • Authentication-Chaining mode

Cross-reference blank passwords

This option allows you to configure the server to query an external mechanism for user password validation.

This is useful if you want to define user characteristics (email address, licensing, group information) in AR System, and have authentication occur outside of AR System. With this option, authorization occurs within the AR System User form, and authentication occurs outside the system. The following options are supported:

  • OS environment password (for the user with a matching name)
  • AREA plug-in

The cross-reference blank passwords feature is related only to users without a password defined within the AR System User form. It does not accept a user with no password, but checks the user's password against an AREA plug-in (if present) or the OS (when the External-Authentication-RPC-Socket ar.conf value is not set). Use the following steps to configure AR System server to cross reference blank passwords.

Note

This option is independent of the option described in the Authentication-Chaining mode section below.

To configure AR System server to cross reference blank passwords

  1. Log on to AR System.
  2. Choose AR System Administration > AR System Administration Console.
  3. Choose System > General > Server Information.

  4. Click the EA tab.

  5. Click Cross Reference Blank Password to activate the option.

  6. Click Apply to confirm the setting.

Authenticate unregistered users

This feature is used to authenticate users that do not exist in the User form. If you are maintaining a list of users outside of the AR System User form for authentication, use this feature to require authentication of unregistered users if you want to require that every login be authenticated within AR System, the OS, or an AREA plug-in. Use the following steps to configure AR System server to authenticate unregistered users.

Note

This feature is limited, especially when using OS authentication. Users cannot be assigned groups or licenses.

Configure AR System server to authenticate unregistered users

  1. Log on to AR System.
  2. Click AR System Administration > AR System Administration Console.
  3. Click System > General > Server Information.
  4. Click the EA tab.

  5. Click Authenticate Unregistered Users to activate the option.

  6. Click Apply to confirm the setting.

Configure AR System server to authenticate unregistered users in the configuration file (for releases prior to 6.0)

  1. Open the BMC Software installation folder:
    1. On a Windows system, navigate to the following file:
      Program Files > BMC Software > ARSystem > Conf > ar.cfg
    2. On a UNIX (or Linux) based OS, open a terminal and enter:
      vi ar.conf
  2. Enter the following at the bottom of the file:
    Use-Password-File: T

Authentication-Chaining mode

The authentication chaining option is a configuration setting that provides users with connection options based on the environment. Use the following steps to configure Authentication-Chaining mode:

To configure Authentication-Chaining mode

  1. Log on to AR System.
  2. Choose AR System Administration > AR System Administration Console.
  3. Choose System > General > Server Information.
  4. Click the EA tab.

  5. Use the Authentication Chaining Mode list to choose from the options described in the following table.



    Authentication-Chaining-Mode values

    Behavior

    Setting

    Use the default behavior, available prior to release 6.3 (that is, authenticate either with AR System or with AREA depending on the settings of other configuration options).

    0

    Use AR System internal authentication first, then use external authentication via the AREA plug-in.

    1

    Use external authentication via the AREA plug-in first, then use AR System internal authentication.

    2

  6. Click Apply to confirm the setting.

To configure AR System server Authentication-Chaining in the configuration file (for releases prior to 6.3)

  1. Open the BMC Software installation folder:
    1. On a Windows system, navigate to:
      Program Files > BMC Software > ARSystem > Conf > ar.cfg
    2. On a UNIX-based or Linux-based OS, open a terminal and enter:
      vi ar.conf
      The Authentication-Chaining Mode setting in the ar.cfg ( ar.conf ) file allows you to configure the behavior of the system.
  2. Enter the following at the bottom of the file:
    Authentication-Chaining-Mode: {value }

Multiple plug-ins with multiple external sources

Another option is to have multiple AREA plug-ins to authenticate against many different external sources. In all cases of chaining in the table, authentication via the AREA plug-in includes situations with one plug-in and those having multiple plug-ins.

AREA HUB plug-in

In an environment with multiple AREA plug-ins, the system can be set up to use the AREA HUB plug-in. The AREA plug-in hub provides a sequential chaining of multiple AREA plug-ins. From the AR System perspective, there is one AREA plug-in and that is the AREA hub. That hub traverses the various registered plug-ins, until a successful authentication is initiated or all registered plug-ins have been tried.

AREA chaining for C AREA plug-ins, the AREA HUB Plug-in, is configured in the ar.cfg file. The Java plug-in server supports AREA HUB ( AREA chaining) as of release 7.1. For Java, the AREA chaining is done inside the Java Plug-in server itself. One Java AREA plug-in is configured in ar.cfg AREA plug-in alias. The order is determined by the sequence configured in the plug-in server configuration file.

Note

For details about using and configuring the AREA plug-in hub, see Setting up the AREA hub.

Maximum number of bad password attempts before invalidating the account

This option sets a maximum number of bad password attempts as related to authentication within the AR System s erver environment only. Any rules or checking for bad password attempts through other environments are enforced strictly through that environment. Use the following steps to configure the maximum number of bad password attempts.

To configure the maximum number of bad password attempts

  1. Log on to AR System.
  2. Choose AR System Administration > AR System Administration Console.
  3. Choose System > General > Server Information.
  4. Click the Configuration tab.
  5. Enter the maximum number of bad attempts you want the system to allow.
  6. Click Apply to confirm the setting.

Bad password attempt configuration considerations

Any AREA plug-in that interacts with an external environment will count any failed validation against that environment as a bad authentication attempt. This is true even if the chain includes a successful validation against another plug-in. The net effect can be a problem. If logins are allowed using numerous mechanisms, add the most common or the ones with no lockout early in the list so you do not lock out an account through checks against one environment when the user is logging in using a different environment.

This option records a bad attempt event only if the login fails all of the tests. This means that when you want to include AR System authentication in the authentication chain, configure the chaining to try the AR System authentication first. This is because a failure there will not count against you if some other authentication works, and, if AR System authentication succeeds, you prevent the bad attempts against other authentication mechanisms.

A key characteristic of AREA is that the plug-in is used for authentication, but it can also optionally supply authorization information. A plug-in can return information like the user's email address, a group list, and a license type (although it cannot return a fixed license). If the plug-in does not supply this information, it can be obtained from the user record within the AR System. If the authorization information is in neither place, the email address is the login name, the user is in no groups, and the user is defined to have a read license. This is also further documented in the discussion of the AREA environment in the Integrating section.

Login alias

If your authentication method does not allow you to get the real user name from the AR System, you can look at the user name alias functionality of the AR System. The value passed to AR System server must be the user login name. When using the User form, this login name must match the login name field in that form (case sensitive). When using the login alias, a different value can be passed to the AREA plug-in. But the value passed to AR System server becomes $USER$ to preserve consistency. For more information, see the Configuring after installation section.

Was this page helpful? Yes No Submitting... Thank you

Comments