[enhancement] Support Lenovo’s new password policy (Lenovo SR550)

Field-critical applied due to on-site issue

Hi All,

This password policy is *NOT* part of the IPMI spec. This is a password
policy implemented only on the manufacturer side and this may not be
certified hardware.

That said, while this may be a field issue, you should be able to change
the policy to the IPMI compliant one.

O do not believe fixing this issue without evaluating what will happen with
all the other hardware we support and certify is going to be impacted.

On Mon, Mar 26, 2018 at 8:51 AM Chris Gregan <email address hidden>
wrote:

> Field-critical applied due to on-site issue
>
> --
> You received this bug notification because you are subscribed to MAAS.
> https://bugs.launchpad.net/bugs/1758760
>
> Title:
> BMC user account creation during enlistment fails on Lenovo SR550
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1758760/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=maas; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug-Tags: cpe-onsite
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: cgregan marton-kiss
> Launchpad-Bug-Reporter: Márton Kiss (marton-kiss)
> Launchpad-Bug-Modifier: Chris Gregan (cgregan)
> Launchpad-Message-Rationale: Subscriber (MAAS)
> Launchpad-Message-For: andreserl
>
--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

Unsubbing field-critical because this is an issue with a BMC that is not IPMI spec compliant *AND* the work around is to configure the BMC to use a IPMI spec compliant password policy.

Andreas,

I just checked the IPMI spec, and it exactly says:
"Software is allowed to place additional restrictions on what passwords can be entered, in which case it is the responsibility of configuration software and console software to stay in synch with that definition."

https://www.intel.co.uk/content/www/uk/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html
2.30 Set User Password command

So from that aspect it complies with the IPMI spec. It is just a bit more restrictive.

Marton,

You are right, the policy has now been updated since the last time I reviewed it. That said:

 - Before, all manufacturers had the same password policy, which allowed us to ahave the same password policy.
 - Manufacturers are now implementing their own policy, which means that each manufacturer may set different policies breaking a generalized approach.

That said, since this hardware seems to be non-certified, my recommendation is to change back to the default password policy and not the stricter one since it is not supported for this hardware. Adding support requires:

 - Creation of the new password policy based on the previously created
 - Testing across this new hardware and other hardware to ensure no regressions

As such, I've changed the title of this bug as a enablement request.

To work around the issue, revert back to the fdefault password policy instead of the stricter, as MAAS doesn't support the stricter password policy in this hardware.

Meanwhile this specific hardware is not supporting turning off the password policy check. The doc includes this option:

-pc Password complexity rules. on, off
http://sysmgt.lenovofiles.com/help/topic/com.lenovo.systems.management.xcc.doc/xcc_book.pdf

But in the real life:

system> help accseccfg
usage:
   accseccfg [options]
options:
   -am User authentication method (local, ldap, localldap, ldaplocal)
   -lp Lockout period after maximum login failures in minutes
            (between 0 and 2880, 0=lockout period does not expire)
   -pe Password expiration time period (between 0 and 365, 0=never expire)
   -pew Password expiration warning time period
            (between 0 and -pe value, 0=never warn)
   -pl Password length (between 8 and 20)
   -ci minimum change interval in hours (between 0 and 240, 0=change
            immediately.)
   -lf maximum number of login failures before account is locked
            (between 0 and 10, 0=never locked)
   -chgdft (on|off) user must change default password after first login
   -chgnew (on|off) new user must change password after first login
   -rc Password reuse cycle (between 0 and 10, 0=reuse immediately)
   -wt Web inactivity session timeout in minutes.(between 0 and 1440)

system> accseccfg -pc
Unrecognized long option: -pc

It is simply not implemented.

Re-added field critical because this is a blocker.

@Marton,

Have you checked if the BIOS itself has such option instead of the command line interface?

@Marton,

Another question, what's the BIOS version of this system?

BMC Version V1.70 (Build ID: CDI320S)
UEFI Version V1.30 (Build ID: TEE122Q)
LXPM Version V1.20 (Build ID: PDL112R)

@Marton,

Thanks! Were you able to confirm that no such option to disable the password policy check is available in the BIOS?

You can see the output of the doc and the policy mgmt command in #6. So this option exists in the doc, but seems to be not implemented in Lenovo's mgmt tool.

For my workaround I set the:
- rc: 0 (Password Reuse Cycle - allow to reuse the password)
- ci: 0 (Minimum Password Change Interval - allow to update the password anytime)

However the -pc that would help us to disable character challenges is not working.

Marton, why is this code even being run? AIUI in Foundation we specify a BMC username and password and we never expect to have MAAS create one for us. Does MAAS always run that code anyway?

@Marton,

Please test the attached branch and let me know what the results are.

Thanks.

@kiko yes, MAAS always runs that code during enlistment (and commissioning), whether or not a username/password was provided for the BMC.

Keep in mind, however, that even if MAAS didn't run this when it new the BMC credentials for a machine already, it would not fix this case, because MAAS is enlisting a node it does not know about.

When we add a node through foundation, we add it to MAAS w/ fixed BMC credentials, but a fake MAC address, to get MAAS to power it on, then we immediately delete the node from MAAS so that the node will go through enlistment when it PXE boots. During enlistment, MAAS creates it as a new node, this time with the real MAC addresses it discovered, and with BMC credentials it set. We then recognize that node via the BMC power address matching the one we used.

That's unfortunate. Jason, is there a bug for overriding MAAS' BMC credential creation behavior?

@kiko - yes - bug 1761262. See also bug 1759911 which is simpler and would provide us with a workaround for foundation. And bug 1707216 for allowing adding a machine without a MAC address.