Authorization of LDAP users in bmcweb

Alexander Amelkin a.amelkin at yadro.com
Thu Apr 2 02:52:49 AEDT 2020


01.04.2020 10:40, CS20 KFTing пишет:
>
> Hi Alex:
>
> Please help try the patch from 
> https://github.com/Nuvoton-Israel/openbmc/blob/runbmc/meta-quanta/meta-olympus-nuvoton/recipes-extended/pam/libpam/pam_succeed_if_support_ldap_user_login.patch 
> to libpam and see how it goes.
>
> Besides the patch, the user from the ldap server needs to be in the 
> “redfish” group in the ldap server database and it’s already done 
> according to your description.
>
> The requirement "user in group redfish" is controlled by the 
> pam_succeed_if module when a user tries to login via WebUI and the 
> original implementation in pam_succeed_if module has some limitation 
> on group identification.
>
We've tested your patch. It works, but not every time.

I suspect that the groups check leads to requesting all groups from 
LDAP, and that takes a lot of time in our setup so authentication times 
out and fails. When I repeat the auth request, the list of groups is 
already in the memory and so authentication completes successfully.

I believe that there should be an easy way to make a mapping between 
LDAP and local permission (such as 'redfish', etc.) and privilege (such 
as 'priv-admin', etc.) groups. I'd say that there must be no need to add 
a user to LDAP `redfish` group, and I personally dislike that approach 
because it is prone to group name clashes. What I think would be great 
is have in WebUI a table like this:

LDAP Group | Privilege level | SSH | Redfish | Web
===========|=================|=====|=========|====
SomeGroup  | Administrator   |  Y  |    Y    |  Y
OtherGroup | Operator        |  N  |    Y    |  Y

* IPMI is not listed because it requires plain-text passwords and can't 
be authenticated against LDAP

What do you think?

WBR, Alexander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200401/64c01447/attachment.htm>


More information about the openbmc mailing list