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

Bug #1758760 reported by Márton Kiss on 2018-03-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Andres Rodriguez
Andres Rodriguez

Bug Description

This bug is very similar to https://bugs.launchpad.net/maas/+bug/1621175. The password creation policy is more strict for Lenovo SR550, and if the generated password in maas_ipmi_autodetect.py's generate_random_password() function not compliant with the policy, node enlistment fails.

Password policy:
- Only contain the following characters: A-Z,a-z,0-9,~`!"@#$%^&*()-+={}[]|:;"'<>,?/._
- Must contain at least one letter
- Must contain at least one number
- Must contain at least 2 of the following combinations:
  - at least one upper-case letter
  - at least one lower-case letter
  - at least one special character
- No other characters (in particular, spaces or white-space characters) are allowed
- Passwords may have no more than 2 consecutive instances of the same character (i.e., "aa")
- Passwords must not be a repeat of the associated user id
- No less than 10 and no more than 20

The same character rule must be implemented in this case, additional to Huawei rules.

Related branches

Chris Gregan (cgregan) wrote :

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>

> 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.

Changed in maas:
status: New → Triaged
importance: Undecided → Low
milestone: none → 2.4.x
summary: - BMC user account creation during enlistment fails on Lenovo SR550
+ [feature] Support Lenovo’s new, non-IPMI compliant, password policy
+ (Lenovo SR550)
tags: added: wishlist


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."

2.30 Set User Password command

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

Andres Rodriguez (andreserl) wrote :


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.

Changed in maas:
importance: Low → Undecided
Márton Kiss (marton-kiss) wrote :

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

-pc Password complexity rules. on, off

But in the real life:

system> help accseccfg
   accseccfg [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
   -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.

Ante Karamatić (ivoks) wrote :

Re-added field critical because this is a blocker.

summary: - [feature] Support Lenovo’s new, non-IPMI compliant, password policy
- (Lenovo SR550)
+ [feature] Support Lenovo’s new password policy (Lenovo SR550)


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

Andres Rodriguez (andreserl) wrote :


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

Márton Kiss (marton-kiss) wrote :

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

Andres Rodriguez (andreserl) wrote :


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

Márton Kiss (marton-kiss) wrote :

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.

Christian Reis (kiko) wrote :

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?

Changed in maas:
assignee: nobody → Andres Rodriguez (andreserl)
Andres Rodriguez (andreserl) wrote :


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


Changed in maas:
status: Triaged → In Progress
Changed in maas:
milestone: 2.4.x → 2.4.0beta1
importance: Undecided → Medium
summary: - [feature] Support Lenovo’s new password policy (Lenovo SR550)
+ [enhancement] Support Lenovo’s new password policy (Lenovo SR550)
Jason Hobbs (jason-hobbs) wrote :

@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.

Changed in maas:
status: In Progress → Fix Committed
Christian Reis (kiko) wrote :

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

Changed in maas:
status: Fix Committed → Fix Released
Jason Hobbs (jason-hobbs) wrote :

@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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers