Legacy LDAP authentication and authorization

You can configure LDAP search attributes for an advanced management module on which enhanced role-based security for Active Directory users is disabled.

Legacy LDAP authentication and authorization was the original model deployed on advanced management modules. It supports Active Directory, Novell eDirectory, and OpenLDAP environments and relies on configuration information stored on an LDAP server to associated permissions with a user. It is used to both authenticate and authorize users through an LDAP server.

Complete the following steps to configure legacy LDAP authentication and authorization:

  1. In the navigation pane, click MM Control → Network Protocols.
  2. Select Use LDAP Servers for Authentication and Authorization.
  3. Set Enhanced role-based security to Disabled.
  4. The LDAP servers to be used for authentication can either be manually configured or discovered dynamically via DNS SVR records.
    • Select Use DNS to find LDAP Servers to dynamically discover the LDAP servers based on DNS SVR records (see step 5).
    • Select Use Pre-Configured LDAP Servers (default) to manually configure the LDAP servers (see step 6).
  5. If you are using DNS to dynamically discover the LDAP servers, configure the domain name of the LDAP server; then, go to step 7.
    Graphic illustrating the LDAP client setup page for legacy authentication and authorization using DNS.
    Domain Name
    The fully qualified domain name of the LDAP server. The domain name is needed to find the LDAP server.
    Active Directory Forest Name
    Active Directory role-based authentication and authorization does not make use of Global Catalogs; leave this field blank.
  6. If you are manually configuring the LDAP servers, configure the LDAP Server Host Name or IP Address field; then, go to step 7. Up to four LDAP servers can be configured using an IP address or a fully qualified hostname.
    Graphic illustrating the LDAP client setup page for legacy authentication and authorization using pre-configured servers.
  7. Configure the following Miscellaneous Parameters:
    Root DN
    This optional parameter is used to configure the base distinguished name (DN) of the Active Directory server (for example, dn=companyABC,dn=com). In most cases, this field is left blank, although it can be useful for debugging purposes.

    The advanced management module normally uses the RootDSE query to find the base distinguished name of an Active Directory server with which it communicates. This base distinguished name is then used for subsequent searches. The base distinguished name is derived from the defaultNamingContext and rootDomaintNamingContext attributes retrieved from the RootDSE query. When the base distinguished name is set using the Root DN field, it overrides the defaultNamingContext and rootDomaintNamingContext attributes.

    Binding Method
    For initial binds to the domain controller server, select one of the following options:

    w/ Configured Credentials: Fill in the client distinguished name (Client DN) and Password to be used for the initial bind. If this bind fails, the authentication process also fails. If the bind is successful, a search will attempt to find a user record that matches the client distinguished name entered in the Client DN field. The search typically looks for common attributes that might match the userid presented during the login process. These attributes include displayName, sAMAccountName, and userPrincipalName. If the UID search attribute field is configured, the search also includes this attribute.

    If the search is successful, then a second bind is attempted, this time with the user distinguished name (retrieved from the search) and the password presented during the login process. If the second bind attempt succeeds, the authentication portion succeeds and group membership information for the user is retrieved and matched against the locally configured groups on the advanced management module. The matched groups will define the authorization permissions assigned to the user.

    w/ Login Credentials: The initial bind to the domain controller server is made using the credentials presented during the login process. If this bind fails, the authentication process also fails. If the bind is successful, a search will attempt to find the user record. Once located, group membership information for the user is retrieved and matched against the locally configured groups on the advanced management module. The matched groups will define the authorization permissions assigned to the user.

  8. Configure the following Active Directory Settings:
    Group Filter
    The Group Filter field is used for group authentication. It specifies the groups that the advanced management module belongs to. If the Group Filter field left blank, group authentication is disabled. If enabled, group authentication is performed after user authentication. Specifically, an attempt is made to match at least one group in the list to a group that the user belongs to. If there is no match, the user fails authentication and is denied access. If there is at least one match, then group authentication passes. All comparisons that are made during authentication are case sensitive.

    When group authentication is disabled, user records must contain the permission attribute, otherwise access will be denied (see Login Permission Attribute). For each group that matches the group filter, the permissions associated with that group are assigned to the user. The permissions associated with a group are found by retrieving the Login Permission Attribute from the group record.

    The group filter is limited to 511 characters and can contain multiple group names. A colon (:) must be used to delimit group names. Leading spaces and trailing spaces are ignored; all other spaces are treated as part of the group name. An asterisk (*) wildcard character is not treated as a wildcard, the wildcard concept being removed for security reasons. A group name can be specified as a full domain name or using only the company name portion. For example, a group with a domain name equal to cn=adminGroup,dc=mycompany,dc=com can be specified by using the actual domain name or by using adminGroup.

    Group Search Attribute
    This field is used by the search algorithm to find group membership information for a specific user. When the group filter name is configured, the list of groups to which the user belongs must be retrieved from the LDAP server. This is required to perform group authentication. To retrieve this list, the search filter that is sent to the server must specify the attribute name that is associated with groups. This field specifies this attribute name.

    In an Active Directory or Novell eDirectory environment, the group search attribute specifies the attribute name that identifies the groups that a user belongs to. In Active Directory, this is usually memberOf, and with Novell eDirectory, this is usually groupMembership. In an OpenLDAP server environment, users are typically assigned to groups whose objectClass equals PosixGroup. In that context, this parameter specifies the attribute name that identifies the members of a particular PosixGroup; this is usually memberUid.

    If this field is left blank, the attribute name in the filter defaults to memberOf.

    Login Permission Attribute
    When a user is successfully authenticated through an LDAP server, the login permissions for the user must be retrieved. To retrieve these permissions, the search filter that is sent to the server must specify the attribute name that is associated with login permissions. This field specifies this attribute name.

    This field must not be left blank; otherwise, it is impossible to retrieve the user permissions. Without verified permissions, the login attempt will fail. This is a different from some earlier releases, where access was granted with default read-only permissions assigned to the user whose permissions could not be verified.

    The attribute value that is returned by the LDAP server is searched for the keyword string "IBMRBSPermissions=". This keyword must be immediately followed by a bit string entered as 64 consecutive 0's or 1's. Each bit represents a particular set of functions. The bits are numbered according to their position; the leftmost bit is bit position 0. A value of 1 at a position enables the corresponding function. A value of 0 disables that function. The string "IBMRBSPermissions=010000000000" is a valid example.

    Note that the "IBMRBSPermissions=" keyword is used to enable it to be placed anywhere in the attribute field. This enables the LDAP administrator to reuse an existing attribute, preventing an extension to the LDAP schema. Furthermore, this enables the attribute to be used for its original purpose. The keyword string can be added anywhere. The attribute that you use should enable a free-formatted string.

    Note: To make the task of configuring users easier when you are using a Microsoft Windows platform, a Role Based Security (RBS) snap-in utility is available at http://www-304.ibm.com/jct01004c/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5069735&brandind=5000008. The snap-in utility configures roles on an Active Directory server and associates users, groups, and advanced management modules to those roles.

    The permission bits are interpreted as follows:

    • Deny Always (bit position 0): If this bit is set, the user will always fail authentication. This function can be used to block a particular user or users associated with a particular group.
    • Supervisor Access (bit position 1): If this bit is set, the user is given administrator privileges, which lets the user view any page, enables changes to any field, and permits all actions provided by the interface. When this bit is set, the other bits that define specific function access do not have to be set individually. This user is the only user who can back up the advanced management module configuration to the BladeCenter unit or to restore a backed up advanced management module configuration.
    • Read Only Access (bit position 2): If this bit is set, the user has read-only access and cannot perform any maintenance procedures (for example, restart, remote actions, and firmware updates), and nothing can be modified (using the save, clear, or restore functions). Note that read-only and all other bits are mutually exclusive, with bit position 2 having the lowest precedence. That is, if any other bit is set, this bit is ignored.
    • Networking and Security (bit position 3): If this bit is set, the user can modify the settings in the Security, Network Protocols, and Network Interface pages for MM Control. If this bit is set, the user also can modify the IP configuration parameters for I/O modules under the I/O Module Tasks → Management page.
    • User Account Management (bit position 4): If this bit is set, the user can add, modify, and delete users and change the Global Login Settings in the Login Profiles page.
    • Blade Server Remote Console Access (bit position 5): If this bit is set, the user can access a remote blade server video console with keyboard and mouse control.
    • Blade Server Remote Console and Virtual Media Access (bit position 6): If this bit is set, the user can access a remote blade server video console with keyboard and mouse control and also can access the virtual media features for that remote blade server.
    • Blade Server and I/O Module Power/Restart Access (bit position 7): If this bit is set, the user can access the power-on and restart functions for the blade servers and the I/O modules. These functions are available in the Blade Tasks → Power/Restart page and the I/O Module Tasks → Power/Restart page.
    • Basic Configuration (bit position 8): If this bit is set, the user can modify basic configuration parameters for the management module and blade servers. These parameters include the General Settings and Alerts pages of MM Control and the Configuration page of the Blade Tasks.
    • Ability to Clear Event Logs (bit position 9): If this bit is set, the user can clear the event logs. All users can view the event logs, but this permission is required to clear the event logs.
    • Advanced Adapter Configuration (bit position 10): If this bit is set, the user has no restrictions when configuring the management module, blade servers, I/O modules, and VPD. In addition, the user has administrative access, meaning that this user also can perform the following advanced functions: firmware upgrades on management module or blade servers, restore management module factory defaults, modify and restore the management module configuration from a configuration file, and restart or reset the management module.
    • Version Number (bit positions 11 through 15): A version number of 00000 indicates that the user permissions scheme that is set using bit positions 0 through 10 is used. A version number of 00001 indicates that the role-based user permissions scheme using bit positions 16 through 55 is used. Any other version number will use the user permissions scheme that is set using bit positions 0 through 10.
    • Deny Always Role (bit position 16): If this bit is set, the user will always fail authentication. This function can be used to block a particular user or users associated with a particular group.
    • Supervisor Role (bit position 17): If this bit is set, the user has no restrictions. The user has read/write access to all pages and fields for all devices. When this bit is set, there is no need to set any other authority levels that are controlled by bits 18 through 55.
    • Operator Role (bit position 18): If this bit is set, the user has read-only access. This user cannot perform any maintenance procedures (for example, restart, remote actions, firmware updates) and is unable to modify any settings (using the save, clear, or restore functions). Note that read-only and all other bits are mutually exclusive, with read-only having the lowest precedence. That is, if any other bit is set, this bit 18 is ignored.
    • Chassis Operator Role (bit position 19): If this bit is set, the user can browse status and properties of BladeCenter unit components (management module, blowers, midplane, power modules, media tray) and can back up the management module configuration. This user also can back up the advanced management module configuration to a file.
    • Chassis User Account Management Role (bit position 20): If this bit is set, the user can add, modify, and delete users in the MM Control → Login Profiles page. Changing the global login settings requires the Chassis Configuration role. This user also can back up the advanced management module configuration to a file.
    • Chassis Log Account Management Role (bit position 21): If this bit is set, the user can clear the event logs or change the log policy settings. All users can view the event logs, but this role is required to clear the logs or to change the log policy settings (the field at the top of the event log page). This user also can back up the advanced management module configuration to a file.
    • Chassis Configuration Role (bit position 22): If this bit is set, the user can modify and save any BladeCenter unit configuration parameter except user profiles and event log settings; (for example, general management module settings, management module port assignments, management module network interfaces, management module network protocols, and management module security). This user also can change the SOL configuration under the SOL configuration web page, the ability to change the global login settings, and the ability to back up the advanced management module configuration to a file. In addition, this user can restore management module factory defaults configuration, if the user also has Chassis Administration permissions.
    • Chassis Administration Role (bit position 23): If this bit is set, the user can perform management module firmware updates, modify the state of the BladeCenter unit LEDs, and restart the management module. The user also can restore management-module factory defaults configuration if the user also has Chassis Configuration permissions.
    • Blade Operator Role (bit position 24): If this bit is set, the user can read blade information but not to modify it.
    • Blade Remote Presence Role (bit position 25): If this bit is set, the user can access the Remote Control web page and the functions that are provided on the page: remote console (KVM) and remote disk. In addition, this user can issue the command-line interface (CLI) console command to start an SOL session to a blade server.
    • Blade Configuration Role (bit position 26): If this bit is set, the user can modify and save any blade server configuration parameter except parameters in the SOL configuration web page (for example, blade server names, blade server policy settings, and can disable or enable SOL for individual blade servers on the Serial Over LAN status web page).
    • Blade Administration Role (bit position 27): If this bit is set, the user can power-on, power-off, and restart blade servers, activate standby blade servers, do firmware updates, and modify the state of blade server LEDs.
    • Switch Operator Role (bit position 28): If this bit is set, the user can browse the status and properties of I/O modules and the ability to ping I/O modules.
    • Switch Configuration Role (bit position 29): If this bit is set, the user can configure the I/O module IP address, enable or disable external management over all ports, and preserve new IP configuration on all resets. The user also can restore factory defaults and to start a Telnet or web session to an I/O module, if the user also has Switch Administration permissions.
    • Switch Administration Role (bit position 30): If this bit is set, the user can power-on, power-off, and restart I/O modules with various diagnostic levels, update passthru I/O module firmware, enable or disable Fast POST, and enable or disable external ports. The user also can restore factory defaults and to start a Telnet or web session to an I/O module, if the user also has Switch Configuration permissions.
    • Blade 1 Scope (bit position 31): If this bit is set, the user has access to the blade server in bay 1.
    • Blade 2 Scope (bit position 32): If this bit is set, the user has access to the blade server in bay 2.
    • Blade 3 Scope (bit position 33): If this bit is set, the user has access to the blade server in bay 3.
    • Blade 4 Scope (bit position 34): If this bit is set, the user has access to the blade server in bay 4.
    • Blade 5 Scope (bit position 35): If this bit is set, the user has access to the blade server in bay 5.
    • Blade 6 Scope (bit position 36): If this bit is set, the user has access to the blade server in bay 6.
    • Blade 7 Scope (bit position 37): If this bit is set, the user has access to the blade server in bay 7.
    • Blade 8 Scope (bit position 38): If this bit is set, the user has access to the blade server in bay 8.
    • Blade 9 Scope (bit position 39): If this bit is set, the user has access to the blade server in bay 9.
    • Blade 10 Scope (bit position 40): If this bit is set, the user has access to the blade server in bay 10.
    • Blade 11 Scope (bit position 41): If this bit is set, the user has access to the blade server in bay 11.
    • Blade 12 Scope (bit position 42): If this bit is set, the user has access to the blade server in bay 12.
    • Blade 13 Scope (bit position 43): If this bit is set, the user has access to the blade server in bay 13.
    • Blade 14 Scope (bit position 44): If this bit is set, the user has access to the blade server in bay 14.
    • Chassis Scope (bit position 45): If this bit is set, the user has access to the BladeCenter unit and management module.
    • I/O Module 1 Scope (bit position 46): If this bit is set, the user has access to I/O module 1.
    • I/O Module 2 Scope (bit position 47): If this bit is set, the user has access to I/O module 2.
    • I/O Module 3 Scope (bit position 48): If this bit is set, the user has access to I/O module 3.
    • I/O Module 4 Scope (bit position 49): If this bit is set, the user has access to I/O module 4.
    • I/O Module 5 Scope (bit position 50): If this bit is set, the user has access to I/O module 5.
    • I/O Module 6 Scope (bit position 51): If this bit is set, the user has access to I/O module 6.
    • I/O Module 7 Scope (bit position 52): If this bit is set, the user has access to I/O module 7.
    • I/O Module 8 Scope (bit position 53): If this bit is set, the user has access to I/O module 8.
    • I/O Module 9 Scope (bit position 54): If this bit is set, the user has access to I/O module 9.
    • I/O Module 10 Scope (bit position 55): If this bit is set, the user has access to I/O module 10.
    • Reserved (bit position 56 through 63): reserved for future use.

    If none of the bits are set, the default is set to deny always (read-only) for the user.

    Note that priority is given to login permissions that are retrieved directly from the user record. If the user does not have the login permission attribute in the user record, an attempt is made to retrieve the permissions from the groups that the user belongs to. This is done as part of the group authentication phase. The user is assigned the inclusive OR of all the bits for all of the groups. Again, the Deny Always bit is set only if all the other bits are zero. Also note that if the Deny Always bit is set for any of the groups, the user is refused access. The Deny Always bit always has precedence over every other bit.

    Important: If you give a user the ability to modify basic, networking, or security related adapter configuration parameters, consider giving this same user the ability to restart the management module. If the user is unable to reset the management module, changes that the user makes that require a restart will not take effect.
  9. To enable or disable SSL between the advanced management module and the Active Directory server, click LDAP section of the security page.
    Graphic illustrating the LDAP section of the security page.
Parent topic: Configuring LDAP