BMC password only change not working

[Eric MacDonald]

Changing the BMC password only does not result in the changed password being saved in Barbican.

Severity
--------
Major: from the Useability perspective
Minor: from the Recoverability perspective

Steps to Reproduce
------------------
Say for instance the administrator executes the following BMC provisioning command

> system host-update controller-0 bm_type=bmc bm_password=roor bm_username=root bm_ip=xxx.yyy.aaa.bbb

... and then realizes that the bmc password entry was entered incorrectly ; fat fingered or whatever.

Intended it to be 'root' but entered (in this example) 'roor' instead. The typical correction method would be to execute the same command again but with the correct password.

> system host-update controller-0 bm_type=bmc bm_password=root bm_username=root bm_ip=xxx.yyy.aaa.bbb

This command is accepted and appears to execute successfully. However, the password is not changed in Barbican, it remains roor.

All BMC accesses will fail and produce failure logs but since those logs do not include the password it is difficult to root cause the issue.

There are 2 ways to work around this issue
1. de-provision the BMC

   > system host-update controller-0 bm_type=none

2. re-provision the BMC by making an additional change to the bmc username or ip address with the corrected bmc password only to correct the username and password on the next command.

    > system host-update controller-0 bm_type=bmc bm_password=root bm_username=root1 bm_ip=xxx.yyy.aaa.bbb

    > system host-update controller-0 bm_type=bmc bm_password=root bm_username=root bm_ip=xxx.yyy.aaa.bbb

    recommend de-provisioning and then provisioning

Expected Behavior
------------------
BMC password only change is stored in Barbican

Actual Behavior
----------------
BMC password only change is NOT stored in Barbican

Reproducibility
---------------
Reproducible 100% of the time

System Configuration
--------------------
Any system with BMCs

Branch/Pull Time/Commit
-----------------------
All

Last Pass
---------
Unknown

Timestamp/Logs
--------------
N/A

Test Activity
-------------
Feature Usability Unit Testing

[Ghada Khalil (gkhalil)]

Marking as stx.3.0 / medium priority - would be nice to fix, but not urgent given there is a workaround

[Alex Kozyrev (akozyrev)]

Original design, password is not stoored in Sysinv due to security concern.
So, there is no way to check if it is changed or no currently.
Need to find a way to notify MTCE about password change without that.
This bug should be treated as enhancement request.

[Eric MacDonald (rocksolidmtce)]

Agreed. I think there is a path through sysinv on the change. I recall seeing a sysinv log that was doing nothing coincident with each time I changed the password. Just need to figure out the best way to catch that and send a mod notification to mtce.

[Ghada Khalil (gkhalil)]

Changing to stx.4.0 given the comments above which indicate that this is day 1 behavior. This should be considered as an enhancement for stx.4.0

Is one implementation option to just re-apply the passwd change to the backend without checking if it has changed or not?

[Eric MacDonald (rocksolidmtce)]

Good idea.

I've already implemented mtce so that all bm provisioning change notifications cause re-fetch the bmc password. Just need to notification to come through.