BMC acc setup during auto-enlistment fails on Huawei model RH1288 V3

Hi Kiko,

Could you please provide:

1. Version of MAAS being used.
2. Output where it is being said that it is "too simple".
3. If you are using 2.0+, provide /var/log/maas/rsyslog/maas-enlisting-node/<date>/<ip-address-of-failing-node>. If not, a capture of 2 on the console log.

Also, it seems this Hardware is not Ubuntu Certified.

Thanks.

Hi Andres,

1. MAAS Version 2.0.0+bzr5189-0ubuntu1 (16.04.1)
2. There is no output which is directly related to the security checking, you only get following error in iBMC when maas tries to change the user's password
   "Modify user(maas|user3) password failed"

I attached the logfile you requested.

If you need any further information i'll try to provide them to you

Thanks! Two additional questions:

Were you able to actually get MAAS to automatically set a valid
password?

If not, were you able to inform a password in iBMC and then manually
configure the node's power type correctly?

Hi Kiko,

yes, when i disable the security settings MAAS is able to automatically create the user and use the iBMC.
Also when you provide the credentials manually it works like it should work.

Thanks, but your reply makes me question my assumptions.

Were you able to determine what the security module considers an acceptable password? Is there a length constraint, or a number of characters constraint?

Or is setting up passwords in-band simply not allowed without disabling security?

Here are the password rules which are active when you do not disable the security settings:

The password complexity requirements are as follows:
1) Must contain 8 to 20 characters.
2) Must contain at least one space or one of the following special characters:
`~!@#$%^&*()-_=+\|[{}];:'",<.>/?
3) Must contain at least two types of the following characters:
- Lowercase letters:a to z;
- Uppercase letters:A to Z;
- Digits:0 to 9;
4) Cannot be the same as the user name or user name in reverse order.
5) The new password must differ from the old password in two character positions.

As far as i could see in the logs, maas is using only [a-Z][A-Z][0-9] so the iBMC rejects the password when those rules are active.

Thank you for providing your password policy. Please, correct me if I'm wrong but this password policy seems to be different from what's in the IPMI specification. For example, skimming through the spec, it seems that maximum length of passwords is 16 characters.

That said, provided that this seems to be a custom password policy that seems to differ from the standard:

- It would be very risky for MAAS to use this password policy provide that it may not apply to the hundreds of BMC's that MAAS has been certified against.
- This could cause serious regressions against BMC's that MAAS is known to work.

That said, is there a way for us to identify that this password policy is enabled by querying the BMC ? For example, if we are to do do:

bmc-config --checkout

From the output of the above command, can we determine that the password policy you have described is in use?

On Sat, Sep 10, 2016 at 05:56:21PM -0000, Andres Rodriguez wrote:
> Thank you for providing your password policy. Please, correct me if I'm
> wrong but this password policy seems to be different from what's in the
> IPMI specification. For example, skimming through the spec, it seems
> that maximum length of passwords is 16 characters.

What is the policy we use to generate our current password?

I'm asking because ISTM that it would be really low-risk to generate a
password with the following criteria:

    - 8 chars at least
    - Use a special char from a low-risk set like: [,.]
    - At least two types of each of [a-z] [A-Z] [0-9]

The current password generation is:

 - password between 8-16 characters.
 - randomly generated to use numbers, and letters in upper or lowecase.

If we are to a special char, even if it is low risk, we cannot safely
assume that all BMC's that MAAS is proven to work will accept the special
character. I'd like to assume they would, but we never know for sure since
we would go all the way back to BMC's using IPMI 1.5.

On Sat, Sep 10, 2016 at 8:17 PM, Christian Reis <email address hidden> wrote:

> On Sat, Sep 10, 2016 at 05:56:21PM -0000, Andres Rodriguez wrote:
> > Thank you for providing your password policy. Please, correct me if I'm
> > wrong but this password policy seems to be different from what's in the
> > IPMI specification. For example, skimming through the spec, it seems
> > that maximum length of passwords is 16 characters.
>
> What is the policy we use to generate our current password?
>
> I'm asking because ISTM that it would be really low-risk to generate a
> password with the following criteria:
>
> - 8 chars at least
> - Use a special char from a low-risk set like: [,.]
> - At least two types of each of [a-z] [A-Z] [0-9]
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1621175
>
> Title:
> BMC acc setup during auto-enlistment fails on Huawei model RH1288 V3
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1621175/+subscriptions
>

--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

Indeed, you have a point. Here are two possible approaches that don't
seem to add risk:

   1. We could detect if we failed to create an account, and if we did,
      retry with a more complex password before giving up altogether

   2. We could detect what system we are running on and if we know it
      has a "high-security" BMC, use the more complex policy

I like approach 1 because it is simpler and more general.