We discussed this in the group (and I apologize that I didn't reply here...), and there was not support for adding the 'group' concept to the local accounts. We don't see a large number of local users generally created (so adding groups seems like overkill) in end user environments. We'd much prefer that user grouping be handled by network/directory-based authentication as that is the preferred path for larger scale deployments.
We also discussed (and this will probably come up again) the ability to specify what types of access are provided for the account (IPMI and/or Redfish access, for example) - but as many implementations today do not "integrate" their user databases (meaning a separate list of accounts for IPMI), this is functionality that may never get implemented.
Post by josephreynolds1 on Sept 10, 2020 15:58:43 GMT
I'm not sure we are talking about the same thing. This is NOT a desire to group together multiple accounts that should all have the same access. The desire is to control which BMC interfaces a user is allowed to access. For example, the joeuser account is allowed to access the BMC's Redfish and SSH interfaces but not its network IPMI interface.
The OpenBMC project defines "group roles"  which control which users are allowed to access BMC interfaces. The "group roles" are ssh, ipmi, redfish, and web (for webui access). For example, if the joeuser account has group roles ssh and redfish but not ipmi, that user is allowed to access the BMC's Redfish and SSH services, but requests to access the BMC's network IPMI service are rejected. (Under the covers these are implemented as Linux groups.) : github.com/openbmc/docs/blob/master/architecture/user-management.md#supported-group-roles
How can OpenBMC do this? Will Redfish extend the ManagerAccount AccountTypes, or should OpenBMC use OEMAccountTypes? - ssh: can we add this to ManagerAccount.AccountTypes? - ipmi: can we add this to ManagerAccount.AccountTypes? - redfish: is already present in ManagerAccount.AccountTypes. - web: can we add this to ManagerAccount.AccountTypes, or should this be added to OEMAccountTypes?
We need to expose the same as part of ManagerAccountAccount --> AccountTypes (Currently OEM, Redfish, SNMP is there) (Need to add fields from SessionTypes ). Note: OEMAccounttype must be used for OEM Account Type (similar to OEMSessionType).
Note: As Redfish recognizes other services, it needs to list all the accounts in a Manager, even if there is an account which is not enabled for Redfish (IPMI don't recoginize the same, i.e. IPMI can't list users which doesn't have IPMI group support).
Post by josephreynolds1 on Sept 15, 2020 19:22:43 GMT
Sounds good to me. I think there are some additional considerations for IPMI. Can we ask the IPMI maintainers to comment on this?
How does the Redfish operation of adding & removing IPMI from ManagerAccount.AccountTypes interact with IPMI's user management? 1. Does it add & remove that user from the list of 16 IPMI users? `user set name #user_slot# "newuser"` and `user set name #user_slot# ""`. 2. Or does it enable & disable that IPMI user's access as in `ipmitool channel setaccess 1 #user_slot# ipmi=off`?
I prefer option 1 because it seems cleaner.
Note that an IPMI service limits to 16 users. What should happen when you try to create a 17th account with has the IPMI AccountType, or try to add the IPMI AccountType to more than 16 accounts? I assume this would fail with an appropriate error.
How to handle the IPMI password length and recoverability requirements? Do we want to require the IPMI AccountType be provided when the ManagerAccount is created, and not allow it to be PATCHed in later? (<--I vote no.) Can or should an implementation also require the ManagerAccount password be changed in the same operation that adds IPMI access? For example, a new Base message like, "Adding IPMI to AccountTypes requires the password to be changed at the same time".
In OpenBMC we are not tracking user names with user ID, it is left to IPMI itself. When we create new user it is added in to the system, and IPMI will mark it to a user ID slot (next available one). phosphor-user-manager today tracks the number of user in the system (including IPMI), and accordingly return the error (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Common.errors.yaml) Say when we reached IPMI User limit 16, NoResource error with "ipmi user count reached" as reason is returned, whereas if we have reached the max user account of the system can support, then it currently returns NoResource with "Non-ipmi user count reached" (Which we can rename to "system user limit reached"). In OpenBMC Group based restriction is also returned Say, When user name length is > 16 and user group includes IPMI, then error --> UserNameGroupFail (With reason IPMI length) is returned, whereas if the username is > system maximum say 30, then we return Invalid Argument with reason User name + Invalid length.
Reg the password, it should be fine to allow the password update separately (Reason: Admin, can just add one user to IPMI Group, and later that user can change his password and access IPMI RMCP+). We don't need to enforce Admin to update the password during the change of group. I don't find any security issue, as without changing the password, other session establishment will work, only RMCP+ won't work.