Dell and Supermicro servers: authorization via LDAP

Author: DevOps Team Leader Hostkey Nikita Zubarev

We have covered our experience integrating FreeIPA with Active Directory in several past articles (here and here), and now it's time to see how to authorize them.

LDAP has become the de facto standard for authentication and authorization services. Popular LDAP-based solutions such as FreeIPA provide centralized account and access management. This allows software developers to easily integrate authentication via LDAP into their applications using off-the-shelf client libraries.

Server hardware manufacturers are also actively using LDAP capabilities. For example, Supermicro has implemented FreeIPA user authentication in its IPMI system for remote server management. This eliminates the need to create accounts in the internal IPMI database for each user on each server.

Instead of authenticating a user to the internal IPMI user database, the IPMI BMC can request FreeIPA. Users who are allowed to log in are identified by their membership in a specific security group, and access is then granted to any user who is a member . The first priority is the internal IPMI user database, the second priority is external repositories, in our case FreeIPA.

With this approach, large server infrastructures have a single point of authentication via LDAP. This simplifies administration and tightens security compared to local accounts.

Whether with a large or not so large fleet of iron servers, when automating management there is a need to have a "single point of entry", which provides a number of advantages (e.g. authorization via LDAP).

When using proxies to integrate with FreeIPA, there are lots of presets on Go that can be used with tweaks, for example yazynin/supermicro-bmcldap-freeipa or bmc-toolbox/bmcldap. We've been using bmc-toolbox. It was necessary to modify the authorization mechanism according to the task and to refine the logic of requests to FreeIPA.

We modified the user authorization scheme to conform to accepted internal security standards. In addition, we added CN attribute substitution for UID in LDAP queries to harmonize data schemas between IPMI and FreeIPA.

Thanks to these improvements, it was possible to configure our IPMI integration with the centralized FreeIPA directory and implement a unified LDAP-based user authentication system for remote access to the servers.

The project has three protocols, one for Dell, HP and SuperMicro respectively:

• The HP version we skipped entirely as we do not use it.
• To integrate with Dell servers, we needed to make changes to the LDAP query logic relative to the base version for Supermicro. First, we removed the use of the memberOf attribute because it is not supported on the Dell side. Instead, we implemented a more complex LDAP query logic to define the user groups. Secondly, we had to modify the query attributes used because in the base version they were hard-wired into Supermicro's implementation. The attributes were changed to match the data schema and Dell's requirements. Thanks to these changes, we were able to adapt the solution and configure the integration of Dell IPMI servers with the centralized LDAP, despite the differences in implementation between the different vendors.
• The version for Supermicro and for Dell has been corrected, errors in the naming of some config variables have been fixed. Since Supermicro does not separate user rights by groups, but rather gets them from the user record, we have revised this mechanism as well. We have also added advanced logging, which makes debugging and monitoring easier.

So, build a package and the output is a working microservice.

To complete the integration, all that remains to connect all the existing servers to a centralized LDAP-based authentication system. Servers in the infrastructure are categorized by type (Supermicro, Dell, etc.) using tags. This allows their list to be retrieved programmatically via API.

Use the SMCIPMITool utility to connect the servers. Configuration is done in the web-interface or via the command line:

#SMCIPMITool ip_addr ADMIN pass ipmi oem x10cfg ldap 1 1 636 ip_addr_proxy '' supermicro cn=supermicro,cn=bmcUsers

For Dell servers, a racadm utility is used.

Create a text file with the following content:

/etc/inworker/ldap.cfg
[iDRAC.LDAP]
BaseDN=cn=dell
BindDN=dell
BindPassword=pass
CertValidationEnable=Disabled
Enable=Enabled
GroupAttribute=memberOf
GroupAttributeIsDN=Disabled
Port=636
SearchFilter=objectClass=posixAccount
Server=ip_addr
UserAttribute=uid
[iDRAC.LDAPRoleGroup.2]
DN=cn=dell,cn=ipmi_access,cn=groups,cn=accounts,dc=infra,dc=hostkey,dc=nl
Privilege=0x1ff

Next, execute the following command:

 racadm -r <ip of IPMI host> -u ADMIN -p <admin_password> set -f ldap.cfg

What it is and why it's needed

Implementations of the IPMI protocol and its interaction with LDAP vary significantly from one server hardware vendor to another. Each vendor may have their own specific requirements for LDAP directory structure, types of queries, attributes used, and other integration nuances.

Some vendors support work only with Active Directory, while others require custom attributes for user authorization. Supporting all these requirements within a single corporate LDAP directory is often extremely difficult and impractical.

To solve this problem, bmcldap software was developed as a proxy server for enabling IPMI and LDAP integration. It acts as an intermediary between the hardware and the corporate directory, emulating the operation of an LDAP server from the BMC's point of view.

Bmcldap converts requests from various vendors into a standard LDAP format. It then performs the necessary queries to the target directory and returns the result in the format expected by the particular IPMI implementation.

This solves the compatibility issue and makes it possible to use any standard LDAP as a single repository for user authentication via IPMI in a heterogeneous IT infrastructure.

For correct routing of LDAP requests depending on the manufacturer of the equipment, the vendor identifier is added to the DN search string:

• cn=dell - for Dell devices;
• cn=supermicro - for Supermicro;
• cn=hp - for HP, etc.

For example, for authentication on a Dell server, the DN string would look like this:

cn=dell,cn=bmcadmins,cn=groups,cn=accounts,dc=example,dc=com

Upon receiving a request with this DN, the bmcldap proxy server will determine that it needs to process the request specifically for Dell and will perform an LDAP lookup accordingly.

When a server is added to an authentication configuration via LDAP, it is assigned an ldap tag. This is to avoid having to re-process the server the next time it is started.

This approach allows for flexible customization of LDAP request handling rules in bmcldap based on the vendor ID in the DN string. This makes it easier to support heterogeneous hardware from different vendors.

Conclusion

The use of the bmcldap proxy server solved the problem of integrating heterogeneous server platforms from different vendors with a single corporate LDAP directory for centralized user authentication.

The key was routing requests from BMC based on the manufacturer ID in the DN string of the LDAP request. This allowed us to realize specific processing for each type of equipment.

Internal mechanisms of bmcldap were finalized to work correctly with Supermicro and Dell servers, and compatibility problems were eliminated.

As a result, all servers were integrated with the bmcldap proxy server for authentication via LDAP, taking into account the peculiarities of the different IPMI implementations. This solution simplified administration and increased the security of access to the servers.

The flexibility of the bmcldap implementation makes it possible to further extend support for new platforms without changing the underlying LDAP infrastructure.