Here is a long explanation of this problem. The TL;DR is, IMHO, disabling IPMI cipher suite privilege levels is extremely dangerous and can potentially disable access to the BMC’s IPMI interface completely, and additionally does not secure the BMC. Details: While only the Lenovo BMC engineers know exactly why the BMC behaves the way it does, this may be a result of misinterpretation of the IPMI spec. The ipmi spec is available at: https://www.intel.com/content/www/us/en/servers/ipmi/ipmi-technical-resources.html References are to the latest version “IPMI v2.0, rev. 1.1 markup for Errata 7, April 21, 2015” The relevant part of the spec to this issue is Table 23-4, LAN Configuration parameters. The important parameters are #23 (“RMCP+ Messaging Cipher Suite Entries”) and #24 (“Messaging Cipher Suite Privilege Levels”). Parameter 23 returns an array of cipher suite IDs that the channel supports, from 0-16 supported cipher suite ids. Parameter 24 allows getting, or setting, the mask of the maximum privilege level allowed for each cipher suite. The Lenovo BMC engineers may have interpreted the parameter 24 mask as corresponding to the array of cipher suite IDs provided by parameter 23. That’s certainly a fair interpretation, and it makes sense. Unfortunately, that isn’t the interpretation of some other BMC manufacturers, and is not the way the mask is handled by both the ipmitool and freeipmi-tools utilities. Instead, the interpretation is that the mask applies to the cipher suite ID numbers. To be fair to the original BMC implementors, the first IPMI v2 spec only defined 15 cipher suite IDs, so the mask size covered all possible currently-existing cipher suites. This is most simply demonstrated with the ipmitool ‘lan print’ command, as well as the ‘lan set cipher_privs’ command. The ‘lan set cipher_privs’ command allows setting the mask, and the ‘lan print’ command prints the output of all lan configuration params, including 23 and 24, e.g.: RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12 Cipher Suite Priv Max : XXXaXXXXXXXXXXX In that example, depending on the interpretation of the IPMI spec, either cipher suite 3 or 6 might be enabled for administrator access; if one interprets the mask as indexing the array of supported suites, the mask has cipher suite 6 enabled, while if one interprets the mask as referencing cipher suites by id number, the mask has suite 3 enabled. This example comes from a Supermicro box, and their interpretation is that the mask shown enables cipher suite 3, not 6. Unfortunately (or maybe fortunately), some BMC implementors seem to have chosen the simple approach of simply listing all defined cipher suites in order, so there is no difference between the “RMCP+ Cipher Suites” array and the list of defined suites, e.g.: RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 In that case, there is no ambiguity; the spec can be interpreted either way, and the result is the same. This is the case for several systems I tested: Dell PowerEdge R730xd Dell PowerEdge T610 RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 HP ProLiant SL390s G7 HP ProLiant DL360e Gen8 HP ProLiant DL360 Gen9 HP ProLiant DL380 Gen10 RMCP+ Cipher Suites : 0,1,2,3 Cisco UCSC-C220-M3L RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,128 However, here are systems which don’t take that approach, and clearly do take the “traditional” interpretation of the format of parameter 24: Supermicro Power9 Supermicro Super Server Supermicro X8DTH RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12 Cipher Suite Priv Max : XXXaXXXXaXXXaXX Quanta S910-X31E RMCP+ Cipher Suites : 0,1,2,3,6,7,8,11,12 Cipher Suite Priv Max : XXXaXXXXaXXXaXX But, there are systems which take the opposite interpretation, which causes the problem in this bug: Fujitsu PRIMERGY RX1330 M4 Fujitsu PRIMERGY RX2530 M5 Fujitsu PRIMERGY RX2540 M5 RMCP+ Cipher Suites : 0,1,2,3,6,7,8,11,12,15,16,17 Cipher Suite Priv Max : XaaaaaaaaaaaXXX Lenovo/IBM System x3650 M5 RMCP+ Cipher Suites : 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 There are also some bizarre system in our lab: This system allows access only using cipher suites 0-3, and no others, with the current config: Lenovo ThinkServer RD240 (with mainboard Tyan Tank GT20): RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12,0,0,0,0,0,0,0,0 Cipher Suite Priv Max : XXXaXXXXaXXXaXX This one only allows access with cipher suites 2 and 3 (not 1 or 4) with the current config: Lenovo System x3650 M2 RMCP+ Cipher Suites : 1,2,3,4 Cipher Suite Priv Max : XaaaXXXXXXXXXXX Turning to the IPMI tooling code, as mentioned above, both the ipmitool and freeipmi code takes the suite-id interpretation, meaning the mask does not correspond to the list of supported suites. The ipmitool code to get and print the mask can be seen here: https://github.com/ipmitool/ipmitool/blob/master/lib/ipmi_lanp.c#L847 And set the mask here: https://github.com/ipmitool/ipmitool/blob/master/lib/ipmi_lanp.c#L1159 Note that ipmitool’s code does not appear to have been updated since the initial IPMI v2.0 spec release; it doesn’t support cipher suites over 15. The freeipmi code even has a helpful comment to clarify the parameter 24 mask does not map to the supported ciphers array: http://git.savannah.gnu.org/cgit/freeipmi.git/tree/ipmi-config/ipmi-config-category-core-rmcpplus-conf-privilege-section.c#n352 And you can check the code to see it does use the cipher suite id, not index into the supported suite array: http://git.savannah.gnu.org/cgit/freeipmi.git/tree/ipmi-config/ipmi-config-category-core-rmcpplus-conf-privilege-section.c#n429 The fact that both tools interpret the specification this way is trivially checkable: ddstreet@thorin:~$ ipmi-config -u ADMIN -p $PW -D LAN_2_0 -h dwalin.bmc --checkout -S Rmcpplus_Conf_Privilege | grep Maximum_Privilege_Cipher_Suite_Id Maximum_Privilege_Cipher_Suite_Id_1 Unused Maximum_Privilege_Cipher_Suite_Id_2 Unused Maximum_Privilege_Cipher_Suite_Id_3 Administrator Maximum_Privilege_Cipher_Suite_Id_6 Unused Maximum_Privilege_Cipher_Suite_Id_7 Unused Maximum_Privilege_Cipher_Suite_Id_8 Unused Maximum_Privilege_Cipher_Suite_Id_11 Unused Maximum_Privilege_Cipher_Suite_Id_12 Unused ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan print | grep 'Cipher Suite.*:' RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12 Cipher Suite Priv Max : XXXaXXXXXXXXXXX ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan set 1 cipher_privs XXXaXXXXXXXXaXX ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan print | grep 'Cipher Suite.*:' RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12 Cipher Suite Priv Max : XXXaXXXXXXXXaXX ddstreet@thorin:~$ ipmi-config -u ADMIN -p $PW -D LAN_2_0 -h dwalin.bmc --checkout -S Rmcpplus_Conf_Privilege | grep Maximum_Privilege_Cipher_Suite_Id Maximum_Privilege_Cipher_Suite_Id_1 Unused Maximum_Privilege_Cipher_Suite_Id_2 Unused Maximum_Privilege_Cipher_Suite_Id_3 Administrator Maximum_Privilege_Cipher_Suite_Id_6 Unused Maximum_Privilege_Cipher_Suite_Id_7 Unused Maximum_Privilege_Cipher_Suite_Id_8 Unused Maximum_Privilege_Cipher_Suite_Id_11 Unused Maximum_Privilege_Cipher_Suite_Id_12 Administrator ddstreet@thorin:~$ ipmi-config -u ADMIN -p $PW -D LAN_2_0 -h dwalin.bmc --commit -e Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_8=Administrator ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan print | grep 'Cipher Suite.*:' RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12 Cipher Suite Priv Max : XXXaXXXXaXXXaXX So, there is no “safe” way to tell if disabling/enabling any specific cipher suite on any random box’s IPMI will actually do what you want. The closest thing to “safe” is likely to test the applied config from the local machine during enlistment/comissioning to verify that the applied mask correctly allows access using the desired suite(s). Additionally, disabling the cipher suites makes no difference if no tool actually was using those suites; by default, ipmitool and freeipmi use cipher suite 3, which is secure (or at least “secure” in terms of the IPMI spec). Also, the BMC also can be “insecure” in other ways; e.g. if telnet access is enabled, or if IPMI v1.5 access enabled (at best, this is as secure as the least secure IPMI v2 cipher suites), or if HTTP is used to access the BMC web GUI. Finally, there is no way for maas to know if anything else was actually using any of the cipher suite(s) that maas disables. Some maas users might have their BMC network secured, and need (for whatever reason) to use a cipher suite other than 3, 8, 12, or 17; if maas disables all suites besides those, this may break existing external applications.