Lines Matching refs:user
6 user-management components. The implementation detail is beyond the scope of
11 1. Use common user-management (e.g. phosphor-user-manager) rather than
12 application-based user-management. Especially, avoid IPMI based
13 user-management.
15 Observe this rule even while creating, modifying or authenticating the user.
16 3. Have applications use the PAM module to authenticate the user instead of
24 or if the user created doesn't have an 'ipmi' group role.
26 user-management (e.g. phosphor-user-manager), whereas individual user-related
31 restriction etc. for the corresponding user). Design is made to cover this
37 corresponding user. This is used to determine at a high level whether the user
40 SSH. Also having group roles in common user-management (e.g.
41 phosphor-user-manager) allows different application to create roles for the
42 other (e.g. Administrative user will be able to create a new user through
68 | 1 | admin | Users are allowed to configure all OpenBMC (including user-management,…
69 …f the host, etc. But users are not allowed to change other configuration like user, network, etc. |
70 | 3 | user | Users only have read access and can't change any behavior of the syste…
73 ## Common User Manager - D-Bus API (phosphor-user-manager)
75 User Manager service exposes D-Bus methods for user-management operations. It
79 for detailed user management D-Bus API and interfaces.
87 || |PAM for user | | |Create new user| | | Redfish specific 1:1 | ||
88 || |authentication | | |or delete or | | | user settings storage| ||
96 | (hashed) or | user in ipmi group)| | | =========================== |
103 +------------+ ^ || | Create new user | || |
105 Common user manager | D-Bus Call | || | update | || |
107 || phosphor-user-manager || | || | must use same logic| || |
112 | | || | user mappings | || |
126 user management
128 | phosphor-user-manager |
130 | | Local user management: | |
137 | | PATH: /xyz/openbmc_project/user/<name> | |
153 | | user management configuration | |
167 1.Request to add new user | | …
170 to user-manager with User Name, | | …
177 … | too many users, user name is too | |
181 3. Throw error to the user | | …
197 the user using pam_chauthtok() | | …
200 user is part of 'ipmi' Group) | | …
214 to user-manager with User Name | | …
249 … | |when the user belongs to IPMI|
252 but will allow only when user is | | …
253 enabled. IPMI shouldn't allow user | | …
254 to login if user is disabled | | …
265 1.Request to delete existing user | | …
268 to user-manager with User Name | | …
274 … | Can be user does not exist etc. | |
276 3. Throw error to the user | | …
301 to clear user name. Send D-Bus API | |
302 to user-manager with User Name | |
330 Applications must use `pam_authenticate()` API to authenticate user. Stacked PAM
339 | | user failed attempt | |
345 | | user authentication | |
359 Applications must use `pam_chauthtok()` API to set / change user password.
360 Stacked PAM modules allow all 'ipmi' group user passwords to be stored in
389 | | local user's password | |
395 | | 'ipmi' group user's | |
410 |authenticate the user |
416 |Read user properties using |
428 |minimum of user & channel |
442 SSH, Redfish, Webserver and HostConsole interface allows the user to
450 For the LDAP user accounts, there is no LDAP attribute type that corresponds to
451 the OpenBMC privilege roles. The preferred way is to group LDAP user accounts
452 into LDAP groups. D-Bus API is provided for the user to assign privilege role to
457 This section explains how the privilege roles of the user accounts are consumed
458 by the webserver interface. The privilege role is a property of the user D-Bus
459 object for the local users. For the LDAP user accounts, the privilege role will
461 configured prior to authenticating with the LDAP user accounts.
463 1. Invoke PAM API for authenticating with user credentials. Proceed, if the
465 2. Check if the user is a local user account. If the user account is local,
468 3. If the user account is not local, read the group name for the user.
471 5. If there is no mapping for group name to privilege role, default to `user`
476 1. As per IPMI spec the max user list can be 15 (+1 for NULL User). Hence
478 getting added to the 'ipmi' Group. Phosphor-user-manager has to enforce this
480 2. Should add IPMI_NULL_USER by default and keep the user in disabled state.
481 This is to prevent IPMI_NULL_USER from being created as an actual user. This
482 is needed as NULL user with NULL password in IPMI can't be added as an entry
483 from Unix user-management point of it.
486 4. Adding / removing a user name from 'ipmi' Group role must force a Password
487 change to the user. This is needed as adding to the 'ipmi' Group of existing
488 user requires clear text password to be stored in encrypted form. Similarly
489 when removing a user from IPMI group, must force the password to be changed
491 5. IPMI spec doesn't support groups for the user-management. Hence the same can
492 be implemented through OEM Commands, thereby creating a user in IPMI with
496 differentiate between new user request or request to extend an existing user
499 Request' completion code, if tried to add existing user in the system.
507 Connected devices must avoid shipping with generic user name & password. The
511 2. Forcing user to generate new authentication account, before using the device.
513 ### Generating user during deployment:
516 specifies about forcing end-user to generate a new account, during deployment
519 `SetUserAccess`, which must be used to create a new user account instead of
520 using any generic default user name and password. Accounts created through this
524 ### Special user - root – user id 0:
526 Exposing root account (user id 0) to end-user by default (other than debug /
528 to enable root user by default for end-user. For general login for debug /
529 developer builds, a new default user with password can be created by specifying
531 default (CI systems etc. can use this account). From OpenBMC package user name
536 `root` user / sudo privilege access are required during development / debug
538 OEM action(TBD) to can be used to set password for the root user, after which
539 `root` user can be used to login to the serial console and for further debugging
540 (Note: `root` user will not be listed as user account in any interfaces like
541 IPMI / REDFISH from user management point of view).
546 uniquely for each & every device or can expose a default user name & password
547 forcing end-user to update the same, before using the device (TBD).