Configuring LDAP

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

Click the LDAP tab to view or modify IMM2 LDAP Client settings.

Note

• The IMM2 LDAP implementation supports the following LDAP servers:
  • Microsoft Active Directory
  • Novell eDirectory Server
  • Open LDAP 2.1
• The IMM2 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)
• In a Flex System, the IMM2 is set up to use the LDAP server running on the CMM. You will see an informational message that reminds you that the LDAP settings may not be changed, (as shown in the following illustration).

Using a LDAP server, the IMM2 can authenticate a user by querying or searching an LDAP directory on an LDAP server, instead of going through its local user database. The IMM2 can remotely authenticate any user's access through a central LDAP server. You can assign authority levels according to information that is found on the LDAP server. You can also use the LDAP server to assign users and IMM2s to groups and perform group authentication, in addition to the normal user (password check) authentication. For example, an IMM2 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 IMM2.

The following illustration shows the LDAP tab.

To use a preconfigured LDAP server, complete the following fields:

LDAP server configuration item list

Select Use Pre-Configured LDAP Server from the item list. The port number for each server is optional. If this field is left blank, the default value of 389 is used for nonsecured LDAP connections. For secured connections, the default value is 636. You must configure at least one LDAP server.

Root distinguished name

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 Anonymously or With 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.

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:

• Anonymously
  • Use this method to bind without a DN or password. This method is strongly discouraged because most servers are configured to not allow search requests on specific user records.
• With Configured Credentials
  • Use this method to bind with configured client DN and password.
• With 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 fully qualified domain name, or a user ID that matches the UID Search Attribute that is configured on the IMM2. 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 Anonymous or With Configured Credentials binding methods are used.

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 service processor belongs. This means that the user must belong to at least one of the groups that are configured for group authentication to succeed. 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. A selection to allow or not allow the use of wildcards in the group name is provided. The filter can be a specific group name (for example, IMMWest), an asterisk (*) used as a wildcard that matches everything, or a wildcard with a prefix (for example, IMM*). The default filter is IMM*. If security policies in your installation prohibit the use of wildcards, you can choose to not allow the use of wildcards. The wildcard character (*) is then treated as a normal character instead of the wildcard. A group name can be specified as a full DN or 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.

In Active Directory environments only, nested group membership is supported. 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 this field is left blank, the user is assigned a default of read-only permissions, assuming that the user passes the user and group authentication.

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 position	Function	Explanation
0	Deny Always	A user will always fail authentication. This function can be used to block a particular user or users associated with a particular group.
1	Supervisor Access	A 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.
2	Read Only Access	A 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.
3	Networking and Security	A user can modify the Security, Network Protocols, Network Interface, Port Assignments, and Serial Port configurations.
4	User Account Management	A user can add, modify, or delete users and change the Global Login Settings in the Login Profiles window.
5	Remote Console Access	A user can access the remote server console.
6	Remote Console and Remote Disk Access	A user can access the remote server console and the remote disk functions for the remote server.
7	Remote Server Power/Restart Access	A user can access the power on and restart functions for the remote server.
8	Basic Adapter Configuration	A user can modify configuration parameters in the System Settings and Alerts windows.
9	Ability to Clear Event Logs	A 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.
10	Advanced Adapter Configuration	A user has no restrictions when configuring the IMM2. In addition the user has administrative access to the IMM2. The user can perform the following advanced functions: firmware upgrades, PXE network boot, restore IMM2 factory defaults, modify and restore adapter configuration from a configuration file, and restart/reset the IMM2.
11	Reserved	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.