Skip to main content

Configuring LDAP

Use the information in this topic to view or change XClarity Controller LDAP settings.

LDAP support includes:
  • Support for LDAP protocol version 3 (RFC-2251)
  • Support for the standard LDAP client APIs (RFC-1823)
  • Support for the standard LDAP search filter syntax (RFC-2254)
  • Support for Lightweight Directory Access Protocol (v3) Extension for Transport Layer Security (RFC-2830)
The LDAP implementation supports the following LDAP servers:
  • Microsoft Active Directory ( Windows 2003, Windows 2008, Windows 2012, Windows 2016, Windows 2019)
  • Microsoft Active Directory Application Mode (Windows 2003 Server)
  • Microsoft Lightweight Directory Service (Windows 2008, Windows 2012)
  • Novell eDirectory Server, version 8.7, 8.8 and 9.4
  • OpenLDAP Server 2.1, 2.2, 2.3 and 2.4

Click the LDAP tab to view or modify XClarity Controller LDAP settings.

The XClarity Controller can remotely authenticate a user's access through a central LDAP server instead of, or in addition to the local user accounts that are stored in the XClarity Controller itself. Privileges can be designated for each user account using the IBMRBSPermissions string. You can also use the LDAP server to assign users to groups and perform group authentication, in addition to the normal user (password check) authentication. For example, an XClarity Controller can be associated with one or more groups, the user will pass group authentication only if the user belongs to at least one group that is associated with the XClarity Controller.

To configure an LDAP server, complete the following steps:
  1. Under LDAP Server Information, the following options are available from the item list:
    • Use LDAP server for Authentication only (with local authorization): This selection directs the XClarity Controller to use the credentials only to authenticate to the LDAP server and to retrieve group membership information. The group names and privileges can be configured in the Active Directory Settings section.
    • Use LDAP server for Authentication and Authorization: This selection directs the XClarity Controller to use the credentials both to authenticate to the LDAP server and to identify a user’s permission.
    Note
    The LDAP servers to be used for authentication can either be configured manually or discovered dynamically via DNS SRV records.
    • Use Pre-Configured Servers: You can configure up to four LDAP servers by entering each server's IP address or host name if DNS is enabled. The port number for each server is optional. If this field is left blank, the default value of 389 is used for non-secured LDAP connections. For secured connections, the default port value is 636. You must configure at least one LDAP server.
    • Use DNS to Find Servers: You can choose to discover the LDAP server(s) dynamically. The mechanisms described in RFC2782 (A DNS RR for specifying the location of services) are used to locate the LDAP server(s). This is known as DNS SRV. You need to specify a fully qualified domain name (FQDN) to be used as the domain name in the DNS SRV request.
      • AD Forest: In an environment with universal groups in cross domains, the forest name (set of domains) must be configured to discover the required Global Catalogs (GC). In an environment where cross-domain group membership does not apply, this field can be left blank.
      • AD Domain: You will need to specify a fully qualified domain name (FQDN) to be used as the domain name in the DNS SRV request.
    If you wish to enable secure LDAP, click the Enable Secure LDAP check box. In order to support secure LDAP, a valid SSL certificate must be in place and at least one SSL client trusted certificate must be imported into the XClarity Controller. Your LDAP server must support Transport Layer Security (TLS) version 1.2 to be compatible with the XClarity Controller secure LDAP client. For more information about certificate handling, see SSL certificate handling.
  2. Fill in information under Additional Parameters. Below are explanations of the parameters.
    Binding method
    Before you can search or query the LDAP server, you must send a bind request. This field controls how this initial bind to the LDAP server is performed. The following bind methods are available:
    • No Credentials Required

      Use this method to bind without a Distinguished Name (DN) or password. This method is strongly discouraged because most servers are configured to not allow search requests on specific user records.

    • Use Configured Credentials

      Use this method to bind with the configured client DN and password.

    • Use Login Credentials

      Use this method to bind with the credentials that are supplied during the login process. The user ID can be provided through a DN, a partial DN, a fully qualified domain name, or through a user ID that matches the UID Search Attribute that is configured on the XClarity Controller. If the credentials that are presented resemble a partial DN (e.g. cn=joe), this partial DN will be prepended to the configured Root DN in an attempt to create a DN that matches the user's record. If the bind attempt fails, a final attempt will be made to bind by prepending cn= to the login credential, and prepending the resulting string to the configured Root DN.

    If the initial bind is successful, a search is performed to find an entry on the LDAP server that belongs to the user who is logging in. If necessary, a second attempt to bind is made, this time with the DN that is retrieved from the user's LDAP record and the password that was entered during the login process. If the second attempt to bind fails, the user is denied access. The second bind is performed only when the No Credentials Required or Use Configured Credentials binding methods are used.
    Root Distinguished Name (DN)
    This is the distinguished name (DN) of the root entry of the directory tree on the LDAP server (for example, dn=mycompany,dc=com). This DN is used as the base object for all search requests.
    UID Search Attribute
    When the binding method is set to No Credentials Required or Use Configured Credentials, the initial bind to the LDAP server is followed by a search request that retrieves specific information about the user, including the user's DN, login permissions, and group membership. This search request must specify the attribute name that represents the user IDs on that server. This attribute name is configured in this field. On Active Directory servers, the attribute name is usually sAMAccountName. On Novell eDirectory and OpenLDAP servers, the attribute name is uid. If this field is left blank, the default is uid.
    Group Filter
    The Group Filter field is used for group authentication. Group authentication is attempted after the user's credentials are successfully verified. If group authentication fails, the user's attempt to log on is denied. When the group filter is configured, it is used to specify to which groups the XClarity Controller belongs. This means that to succeed the user must belong to at least one of the groups that are configured for group authentication. If the Group Filter field is left blank, group authentication automatically succeeds. If the group filter is configured, an attempt is made to match at least one group in the list to a group that the user belongs. If there is no match, the user fails authentication and is denied access. If there is at least one match, group authentication is successful.
    The comparisons are case sensitive. The filter is limited to 511 characters and can consist of one or more group names. The colon (:) character must be used to delimit multiple group names. Leading and trailing spaces are ignored, but any other space is treated as part of the group name.
    Note
    The wildcard character (*) is no longer treated as a wildcard. The wildcard concept has been discontinued to prevent security exposures. A group name can be specified as a full DN or by using only the cn portion. For example, a group with a DN of cn=adminGroup, dc=mycompany, dc=com can be specified using the actual DN or with adminGroup.
    Nested group membership is supported only in Active Directory environments. For example, if a user is a member of GroupA and GroupB, and GroupA is also a member of GroupC, the user is said to be a member of GroupC also. Nested searches stop if 128 groups have been searched. Groups in one level are searched before groups in a lower level. Loops are not detected.
    Group Search Attribute
    In an Active Directory or Novell eDirectory environment, the Group Search Attribute field specifies the attribute name that is used to identify the groups to which a user belongs. In an Active Directory environment, the attribute name is memberOf. In an eDirectory environment, the attribute name is groupMembership. In an OpenLDAP server environment, users are usually assigned to groups whose objectClass equals PosixGroup. In that context, this field specifies the attribute name that is used to identify the members of a particular PosixGroup. This attribute name is memberUid. If this field is left blank, the attribute name in the filter defaults to memberOf.
    Login Permission Attribute
    When a user is authenticated through an LDAP server successfully, the login permissions for the user must be retrieved. To retrieve the login permissions, the search filter that is sent to the server must specify the attribute name that is associated with login permissions. The Login Permission Attribute field specifies the attribute name. If using LDAP server for Authentication and Authorization, but this field is left blank, the user will be refused access.
    The attribute value that is returned by the LDAP server searches for the keyword string IBMRBSPermissions=. This keyword string must be immediately followed by a bit string that is entered as 12 consecutive 0s or 1s. Each bit represents a set of functions. The bits are numbered according to their positions. The left-most bit is bit position 0, and the right-most bit is bit position 11. A value of 1 at a bit position enables the function that is associated with that bit position. A value of 0 at a bit position disables the function that is associated with that bit position.
    The string IBMRBSPermissions=010000000000 is a valid example. The IBMRBSPermissions= keyword is used to allow it to be placed anywhere in this field. This enables the LDAP administrator to reuse an existing attribute; therefore, preventing an extension to the LDAP schema. This also enables the attribute to be used for its original purpose. You can add the keyword string anywhere in this field. The attribute that you use can allow for a free-formatted string. When the attribute is retrieved successfully, the value that is returned by the LDAP server is interpreted according to the information in the following table.
    Table 1. Permission bits.

    Three column table containing bit position explanations.

    Bit positionFunctionExplanation
    0Deny AlwaysA user will always fail authentication. This function can be used to block a particular user or users associated with a particular group.
    1Supervisor AccessA user is given administrator privileges. The user has read/write access to every function. If you set this bit, you do not have to individually set the other bits.
    2Read Only AccessA user has read-only access, and cannot perform any maintenance procedures (for example, restart, remote actions, or firmware updates) or make modifications (for example, the save, clear, or restore functions. Bit position 2 and all other bits are mutually exclusive, with bit position 2 having the lowest precedence. When any other bit is set, this bit will be ignored.
    3Networking and SecurityA user can modify the Security, Network Protocols, Network Interface, Port Assignments, and Serial Port configurations.
    4User Account ManagementA user can add, modify, or delete users and change the Global Login Settings in the Login Profiles window.
    5Remote Console AccessA user can access the remote server console.
    6Remote Console and Remote Disk AccessA user can access the remote server console and the remote disk functions for the remote server.
    7Remote Server Power/Restart AccessA user can access the power on and restart functions for the remote server.
    8Basic Adapter ConfigurationA user can modify configuration parameters in the System Settings and Alerts windows.
    9Ability to Clear Event LogsA user can clear the event logs.
    Note
    All users can view the event logs; but, to clear the event logs the user is required to have this level of permission.
    10Advanced Adapter ConfigurationA user has no restrictions when configuring the XClarity Controller. In addition the user has administrative access to the XClarity Controller. The user can perform the following advanced functions: firmware upgrades, PXE network boot, restore XClarity Controller factory defaults, modify and restore adapter configuration from a configuration file, and restart/reset the XClarity Controller.
    11Reserved

    This bit position is reserved for future use. If none of the bits are set, the user has read-only authority. Priority is given to login permissions that are retrieved directly from the user record.

    If the login permission attribute is not in the user's record, an attempt is made to retrieve the permissions from the groups to which the user belongs. This is performed as part of the group authentication phase. The user is assigned the inclusive OR of all the bits for all groups.

    The Read Only Access bit (position 2) is set only if all other bits are set to zero. If the Deny Always bit (position 0) is set for any of the groups, the user is refused access. The Deny Always bit (position 0) always has precedence over all other bits.

    If none of the bits are set, the default will be set to Read Only for the user.
    Note that priority is given to login permissions retrieved directly from the user record. If the user does not have the login permission attribute in its record, an attempt will be made to retrieve the permissions from the group(s) that the user belongs to, and, if configured, that match the group filter. In this case the user will be assigned the inclusive OR of all the bits for all of the groups. Similarly, the Read Only Access bit will only be set if all the other bits are zero. Moreover, note that if the Deny Always bit is set for any of the groups, the user will be refused access. The Deny Always bit always has precedence over every other bit.
    Note
    If you give a user the ability to modify basic, networking, and/or security related adapter configuration parameters, you should consider giving this same user the ability to restart the XClarity Controller (bit position 10). Otherwise, without this ability, a user might be able to change parameters (for example, IP address of the adapter), but will not be able to have them take effect.
  3. Choose whether or not to Enable enhanced role-based security for Active Directory Users under Active Directory Settings (if Use LDAP server for Authentication and Authorization mode is used), or configure the Groups for Local Authorization (if Use LDAP server for Authentication only (with local authorization) mode is used).

    • Enable enhanced role-based security for Active Directory Users

      If enhanced role-based security setting is enabled, a free-formatted server name must be configured to act as the target name for this particular XClarity Controller. The target name can be associated with one or more roles on the Active Directory server through a Role Based Security (RBS) Snap-In. This is accomplished by creating managed targets, giving them specific names, and then associating them to the appropriate roles. If a name is configured in this field, it provides the ability to define specific roles for users and XClarity Controllers (targets) who are members of the same role. When a user logs in to the XClarity Controller and is authenticated via Active Directory, the roles that the user is a member of are retrieved from the directory. The permissions that are assigned to the user are extracted from the roles that also have as a member a target that matches the server name that is configured here, or a target that matches any XClarity Controller. Multiple XClarity Controllers can share the same target name. This could be used to group multiple XClarity Controllers together and assign them to the same role (or roles) by using a single managed target. Conversely each XClarity Controller can be given a unique name.

    • Groups for Local Authorization

      Group Names are configured to provide local authorization specifications for groups of users. Each group name can be assigned permissions (Roles) that are the same as described in the table above. The LDAP server associates users with a group name. When the user logs in he is assigned the permissions that are associated with the group to which the user belongs. Additional groups can be configured by clicking the “+” icon or deleted by clicking the “x” icon.