LDAP Role Groups

[susantjasinski]

LDAP Settings - InVision Mockups for testing 11-2018

System Admins need to add and remove Role Groups of users (as defined by the LDAP server) who can access the BMC through the LDAP server, and modify their privileges.

• Only users with Admin privileges can view this panel
• Add role group button: add an LDAP server's role group (created using the LDAP server) to the list of people that can access the BMC, and assign a set of pre-defined privileges to that group
  • Group Name: drop down list is provided/pre-defined by the LDAP server
  • Group Privilege: drop down list is pre-defined by the BMC
  • https://github.com/openbmc/docs/blob/master/user_management.md
• Modify role group button: modify the pre-defined privileges assigned to that group
  • Becomes enabled when a group's checkbox is selected in the table
• Delete role group button: remove an LDAP server's role group (created using the LDAP server) from the list of people that can access the BMC
  • Becomes enabled when a group's checkbox is selected in the table

[joseph-reynolds]

The mockups shows Role Group Group Name "RG1" and privileges (Admin, Operator, User, None). Can you clarify in this issue/review that RG1 is defined by the LDAP server, and the privileges are defined by the BMC? Similarly, where in OpenBMC does it say what this mapping means? My understand is that after the association is made, when I log in as userid X, the BMC authenticates with the LDAP server which says which LDAP groups I am in. And if user X is in LDAP group RG1, then this mapping will tell the BMX to give me Admin privileges. Maybe this is documented somewhere else. If so, where?

[edtanous]

https://github.com/openbmc/docs/blob/master/user_management.md

[susantjasinski]

Thank you @joseph-reynolds I updated the description to include your comments about Group Name and Group Privileges. @edtanous, I also put your doc link about User Management in the description so it doesn't get lost in this comment string.

[warp5tw]

So far the group roles and privilege roles definitions follow https://github.com/openbmc/docs/blob/master/user_management.md.

As the user_management.md describes, the group roles are used to determine at a high level whether the user is authorized to the required interface.

Maybe the group definition could be treated in different ways. How about defining groups according to the server usage where BMC is installed?

For example, there are web application servers, email servers and ftp servers and these servers are grouped as “webapp” , “email” and “ftp”.

These servers are grouped by their application or usage and bmc machines could be allocated in or moved out of these groups dynamically.

Some accompanying LDIFs are presented for illustration.

Here is the server group definition LDIF.

dn: ou=ap_group,dc=ldap,dc=example,dc=com objectClass: organizationalUnit ou: ap_group

dn: cn=ftp,ou=ap_group,dc=ldap,dc=example,dc=com objectClass: group-obj cn: ftp gidNumber: 1016 bmc-uid: bmc1 bmc-uid: bmc2

The attribute bmc-uid is defined to describe the BMC machines that the server application group contains. For example, the ftp group contains two BMC machines which are bmc1 and bmc2.

An LDIF example for bmc machine description is as below.

dn: ou=bmc,dc=ldap,dc=example,dc=com objectClass: organizationalUnit ou: bmc

dn: bmc-uid=bmc1,ou=bmc,dc=ldap,dc=example,dc=com objectClass: bmc-info-obj bmc-uid: bmc1 macAddress: 00:00:f7:a0:ff:fc macAddress: 00:00:f7:a0:ff:fd cn: bmc1

dn: bmc-uid=bmc2,ou=bmc,dc=ldap,dc=example,dc=com objectClass: bmc-info-obj bmc-uid: bmc2 macAddress: 00:00:f7:a0:00:e0 macAddress: 00:00:f7:a0:00:e1 cn: bmc2

The attribute “macAddress” is used to identify the bmc machine.

The group roles defined in https://github.com/openbmc/docs/blob/master/user_management.md could be deemed as a user login interface.

In this way, the administrator can assign the user login interfaces to the “server application” groups according to the admin’s plan.

An LDIF is used to describe the scenario.

dn: ou=login_info,uid=user1,ou=people,dc=ldap,dc=example,dc=com objectClass: organizationalUnit ou: login_info

dn: cn=ftp,ou=login_info,uid=user1,ou=people,dc=ldap,dc=example,dc=com objectClass: user-group-info-obj cn: ftp privRoleID: priv-admin user-login-interface: ssh user-login-interface: redfish user-login-interface: /dev/pts user-login-interface: /dev/tty user-login-disabled: 0

dn: cn=email,ou=login_info,uid=user1,ou=people,dc=ldap,dc=example,dc=com objectClass: user-group-info-obj cn: email privRoleID: priv-admin user-login-interface: ssh user-login-interface: /dev/pts user-login-interface: /dev/tty user-login-interface: web user-login-disabled: 0

dn: cn=webserver,ou=login_info,uid=user1,ou=people,dc=ldap,dc=example,dc=com objectClass: user-group-info-obj cn: webserver privRoleID: priv-admin user-login-interface: ssh user-login-interface: ipmi user-login-interface: /dev/pts user-login-interface: /dev/tty user-login-disabled: 0

The LDIF above shows a piece of login information for a specific user. The login information gathers the “server application” groups a user joins and how the user logins into the “server application” groups in a predefined way.

The user (user1) joins “ftp” and “email” groups here. When user1 tries to login into a BMC machine which belongs to a “ftp” group, the user can use ssh, redfish, /dev/pts and /dev/tty interfaces for the login purpose. Also, the privilege for each group the user joins could be specified here where such privileges are required. An attribute “user-login-disabled” controls if the user is allowed to login into a certain “server application” group. “0” stands for "not disabled" and “1” stands for "disabled". If a user joins a group which contains a “user-login-interface” is IPMI, the related LDIF is also provided to describe IPMI settings.

dn: bmc-uid=bmc1,cn=webserver,ou=login_info,uid=user1,ou=people,dc=ldap,dc=example,dc=com objectClass: user-priv-ipmi-obj bmc-uid: bmc1 cn: priIPMB user-priv-ipmi-ch: admin

The LDIF above describes the IPMI application setting for user1 in the webserver group on a BMC machine called “bmc1”. User1 owns the admin privilege on the primary IPMB channel(which is priIPMB) on the “bmc1” BMC machine.

As for the user LDIF, an example is provided below.

dn: ou=people,dc=ldap,dc=example,dc=com objectClass: organizationalUnit ou: people

dn: uid=user1,ou=people,dc=ldap,dc=example,dc=com objectClass: shadowAccount objectClass: posixAccount objectClass: user-account-info-obj cn: user1 gidNumber: 1010 homeDirectory: /home/user1 uid: user1 uidNumber: 1001 UserEnabled: 0 UserLockedForFailAttempt: 0 UserPrivilege: priv-admin loginShell: /bin/sh userPassword:

The attributes mentioned by https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/User and https://github.com/openbmc/docs/blob/master/user_management.md are defined in this LDIF.

Finally, here comes the group LDIF and privilege LDIF mentioned by https://github.com/openbmc/docs/blob/master/user_management.md.

dn: ou=group,dc=ldap,dc=example,dc=com objectClass: organizationalUnit ou: group

dn: cn=ssh,ou=group,dc=ldap,dc=example,dc=com objectClass: posixGroup cn: ssh gidNumber: 1010

dn: cn=web,ou=group,dc=ldap,dc=example,dc=com objectClass: posixGroup cn: web gidNumber: 1013

dn: cn=ipmi,ou=group,dc=ldap,dc=example,dc=com objectClass: posixGroup cn: ipmi gidNumber: 1011

dn: cn=redfish,ou=group,dc=ldap,dc=example,dc=com objectClass: posixGroup cn: redfish gidNumber: 1012

Here, the groups are treated as a user login interface or channel.

dn: ou=privRole,dc=ldap,dc=example,dc=com objectClass: organizationalUnit ou: privRole

dn: privRoleID=priv-user,ou=privRole,dc=ldap,dc=example,dc=com objectClass: priv-role-obj cn: user privRoleID: priv-user

dn: privRoleID=priv-admin,ou=privRole,dc=ldap,dc=example,dc=com objectClass: priv-role-obj cn: admin privRoleID: priv-admin

dn: privRoleID=priv-callback,ou=privRole,dc=ldap,dc=example,dc=com objectClass: priv-role-obj cn: callback privRoleID: priv-callback

dn: privRoleID=priv-operator,ou=privRole,dc=ldap,dc=example,dc=com objectClass: priv-role-obj cn: operator privRoleID: priv-operator

Privilege settings are stored in LDAP also.

Some code patches for making the scenario described happen are required, of course.

Your comments or suggestions are highly welcome.

[warp5tw]

Hi Susan:

May I know where I could retrieve webui page resources represented in LDAP Settings - InVision Mockups for testing 11-2018?

Thank you.

Regards, Tyrone

[susantjasinski]

@warp5tw I am not sure what you mean by "resources represented in LDAP Settings". Can you be more specific about what you need?

[warp5tw]

@warp5tw I am not sure what you mean by "resources represented in LDAP Settings". Can you be more specific about what you need?

Hi Susan:

Where could I download these web pages that show LDAP Settings - InVision Mockups for testing 11-2018??

Sorry for my unclear statement.

[susantjasinski]

@warp5tw I am still uncertain what you need from me. The image that you see in the Invision app is a drawing only, the web UI panel does not exist yet. The purpose of this feedback review is to gather comments from the open community so that we can adjust the design before coding in order to have less re-work for developers.

If you tell me what you are trying to do, perhaps I can assess what you need from me.

Regarding your proposal for redefining groups according to server usage where BMC is installed, this is an architectural decision. Feel free to add this to the Open Community Call agenda on an upcoming Monday to discuss whether we should implement your idea and, if yes, then who will work on it and how it will affect the GUI panel design.

[warp5tw]

@susantjasinski I get your point now because I thought that the web UI panel existed. Originally my idea was to use these web UI panels to test my own LDAP configurations and implementations. That's the whole story.

Thank you for your information about OpenBMC Community Call agenda and I'll check it.

Thank you again.

[susantjasinski]

New Changes to the Page Layout coming in January based on feedback ...

[jandraa]

Current design: https://ibm.invisionapp.com/share/RQNYHJ0VBDY#/318942513_LDAP_Disabled

Open questions:

• How many server URI's is the backend built for?
• Would each server URI have a distinct set of properties (BIND password, LDAP type, etc.) or would they all have the same settings for all those properties?