Configuring management authentication

Edit online

To configure management authentication with the local management interface and the command line interface, use the Management Authentication management page.

Procedure

  1. From the top menu, select System > System Settings > Management Authentication.
    All current management authentication settings are displayed.
  2. In the Main tab:
    • Select Local User Database if you want to use the local user database for authentication.
    • Select Remote LDAP User Registry if you want to use the remote LDAP user registry for authentication.
      Note: If a remote user registry is configured for management authentication, the local administrator user (admin) can continue to be referenced with the admin@local user name. You can use this as a fail safe in the event that the remote user registry is not reachable.
      1. In the LDAP tab:
        1. Specify the name of the LDAP server in the Host name field.
        2. Specify the port over which to communicate with the LDAP server in the Port field.
        3. Select the Anonymous Bind check box if the LDAP user registry supports anonymous bind.
        4. Specify the DN of the user that is used to bind to the registry in the Bind DN field.
        5. Specify the password that is associated with the bind DN in the Bind Password field.
        6. Optional: If you want to enable LDAP client debugging for authentication related issues, select the Debug check box. The LDAP debugging log can be viewed by going to Monitor > Application Log Files and accessing the management_ui > ldap_debug.log file.
      2. In the LDAP General tab:
        1. Specify the name of the LDAP attribute that holds the supplied authentication user name of the user in the User Attribute field.
        2. Specify the name of the LDAP attribute that is used to hold the members of a group in the Group Member Attribute field.
        3. Specify the base DN that is used to house all administrative users in the Base DN field.
        4. Specify the DN of the group to which all administrative users belong in the Administrative Group DN field.
          Note: All administrative users must have permission to view the specified admin_group_dn group within the user registry.
      3. In the LDAP SSL tab:
        1. Select the Enable SSL check box to define whether SSL is used when the system communicates with the LDAP server.
        2. Select the name of the key database file in the Key File Name field.
        3. Select the name of the certificate to be used if client authentication is requested by the LDAP server in the Certificate Label field.
      4. In the User Mapping tab:
        1. Select the Enable checkbox to enable the mapping of a client certificate DN to a new format prior to the user being authenticated.
        2. The User mapping script field contains a placeholder script that will be set as the default unless a new script is entered. The script contains a Javascript function that takes a Map as an input and returns a String that represents the new DN. The map contains the following values that can be used in the mapping:
          • cert > The actual X509Certificate object.
          • principal > The X500Principal in the certificate.
          • san > The certificate subject alternative names.
          • dn > The certificate DN.
          • baseDN > The management authentication configuration value for base DN.
          • userAttribute > The management authentication configuration value for user attribute.
          • groupMemberAttribute > The management authentication configuration value for group member attribute.
          • Each distinct rdns from the DN separately. For example the DN of cn=testuser,o=test,c=us results in 3 entries in the map:
            • cn > testuser
            • o > test
            • c > us
          The default script will use the cn from the map and combine it with the userAttribute and baseDN to create the new DN: 
            function mapUser(props) {
      var user = props.get(“cn”);
      return props.get(“userAttribute”) + “=“ + user + “,” + props.get(“baseDN”);
  }
      5. In the SSH Public Key Authentication tab:
        1. Select the Enable check box to enable SSH public key authentication for remote users.
        2. Specify the name of the user attribute that contains SSH public key data in the Public Key Attribute field.

          The public key attribute is an attribute that contains text data in the format of an SSH AuthorizedKeysFile file.

    • Select Federated SSO if you want to use an external OIDC 2.0 identity provider for authentication.
      Note: If federated SSO is configured for management authentication, the local administrator user (admin) can continue to be used to authenticate to the CLI (SSH).
      1. In the Openid Connect Client tab:
        1. Specify the client identifier.
        2. Specify the client secret. Public clients are not supported.
        3. Specify the OpenID Connect discovery endpoint.
        4. Specify whether the PKCE extension is enabled for this client.
        5. Optional: Specify the SSL truststore that is used to verify connections to the OIDC OP.
        6. Optional: Specify the token claim to use as the username.
          Note: Administrators must verify that the claim used as the username is unique and does not contain non-utf8 characters. Usernames that contain non-utf8 characters can become corrupted when logged.
        7. Optional: Specify whether custom token mapping is applied. Administrators can select among three options:
          • All users are admin users
          • Admin group membership is enforced, administrators must define:
            • Group Claim: The name of the ID token claim to use for group membership.
            • Admin Group: The group name used to define administrator users.
          • If JavaScript Token mapping is enabled, administrators must define a single JavaScript function to map the tokens that are received to the username and group claims:
            /* This JavaScript function take two arguments. The first argument defines which attribute mapping
 * is being evaluated. The mapping can be either mapToUser for username mapping, or mapToGroups for
 * group mapping. The second argument contains a java.util.Map of the parsed token claims.
 * The result of the group mapping must be a list of groups which must contain "adminGroup" group. 
 * If the group mapping does not return membership of "adminGroup", the SSO login fails.
 *
 * This code fragment can only contain a single function which takes two arguments.
 * Administrators can use java.lang.System.out.println(token); to debug functions at runtime.
 * The output from these statements appear in the messages.log file of the management_ui
 * application.
 */
function mapToken(operation, token) {
  if(operation == "mapToUser") {
    return token.get("sub");
  } else { /* operation == "mapToGroups" */
    return ["adminGroup"];
  }
}
  3. Click Save to save your settings.
    Note: For the changes to take effect, they must be deployed.
  4. Optional: Click Test to test the authentication.
    Note: If there have been changes made to the management authentication configuration that have not yet been deployed, this test will run using the undeployed configuration.
    1. In the Test Authentication window, enter the user name in the Username field.
    2. Enter the password in the Password field.
    3. Click Test.
    If the authentication is successful, a success message is displayed. If the authentication is not successful, an error message is displayed.
  5. Optional: Reset management authentication.
    The SSH interface can be used to reset the management authentication policy on appliances that cannot contact an external LDAP/OIDC identity provider.
    1. Use a command line interface to SSH as the admin@local user to your appliance.
    2. Run the command lmi reset_lmi_authn and then type YES to confirm.
    3. Verify that you are able to login to the Local Management Interface, and the admin user is able to authenticate.