Configuring LDAP
Use the information in this topic to view or change XClarity Controller LDAP settings.
- 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)
- Microsoft Active Directory (Windows 2003, Windows 2008, Windows 2012, Windows 2016, Windows 2019)
- Microsoft Active Directory Application Mode (Windows 2003, Windows 2008)
- Microsoft Lightweight Directory Service (Windows 2008, Windows 2012, Windows 2016, Windows 2019)
- Novell eDirectory Server, version 8.7 and 8.8
- OpenLDAP Server 2.1, 2.2, 2.3, 2.4, 2.5 and 2.6
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 valur of "Login Permission attribute". 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.
- 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 roles can be configured in the Groups for Local Authorization 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.
NoteThe 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 three 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.
- Fill in information under Additional Parameters. Below are explanations of the parameters.
- LDAP type
- Select the LDAP server type for LDAP based authentication. The following server types are available:
OpenLDAP
OpenLDAP
Active Directory
Directory: Windows Active Directory
Other
Directory: Apache Directory, eDirectory, etc.
- 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:
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.
- Client distinguished name
- The Client Distinguished Name (DN) to be used for the initial bind. And it is limited to a maximum of 300 characters.
- Client password
- The password for this Distinguished Client.
- Root 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.
- User’s Login Name Search Attribute
- When the binding method is set to 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 CN or sAMAccountName. On Novell eDirectory and OpenLDAP servers, the attribute name is uid. If this field is left blank, the default is sAMAccountName.
- 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.
- Group Membership Search Attribute
- The Group Search Attribute field specifies the attribute name that is used to identify the groups to which a user belongs. On Active Directory servers, the attribute name is usually memberOf. On Novell eDirectory servers, the attribute name is groupMembership. On OpenLDAP servers, 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.
If none of the bits are set, the user will be refused accessTable 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 Configuration - Networking and BMC 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 Configuration - Basic 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. NoteAll users can view the event logs; but, to clear the event logs the user is required to have this level of permission.10 Configuration - Advanced (Firmware Update, Restart BMC, Restore Configuration) A 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 adapter factory defaults, modify and restore adapter configuration from a configuration file, and restart/reset the adapter. 11 Configuration - UEFI Security A user can configure UEFI security related settings, which can also be configured from UEFI F1 security setup page. 12 Reserved Reserved for future use, and currently ignored. NoteNote 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, theRead 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. ImportantIf 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. If Use LDAP server for Authentication only (with local authorization) mode is used, configure the Groups for Local Authorization. Group Name, Group Domain and Role are configured to provide local authorization for groups of users. Each group can be assigned with a Role (permissions) that is the same as configured in the roles in Local User. User accounts are assigned to different groups on LDAP server. An user account will be assigned with the Role (permissions) of the group this user account belongs to after login to BMC. Group Domain should be in the same format as Distinguished Name, like: dc=mycompany,dc=com, will be used as the base object for group searches. If the field is left blank, it will use the same value as the "Root DN" field. Additional groups can be added by clicking the "+" icon or deleted by clicking the "x" icon.
Select the attribute used for displaying the user name from the Specify the attribute used for displaying user name drop-down menu.