Description of problem: Customer environment is not working as expected, we are able to log/authenticate/collect infos via foreman-rake console but the role defined on User Group is not applying at the login time, just after refresh *refresh button or via crontab entry* Version-Release number of selected component (if applicable): 6.2.10 How reproducible: 100% on customer environment, they are using openldap Steps to Reproduce: 1. delete external user from satellite 2. login with external user *no permission at this point* 3. after some time or just after refresh, all permissions to the same user Actual results: User Group feature not working. Expected results: At the login moment customer inherit the role according user group already defined. Additional info:
The problem at this customer was that: 1. They didn't see the external user group link during login. 2. After some time (when the ldap:refresh_usergroups cronjob ran) the user got permissions. 3. Alternatively, an admin could just refresh the user group the new user would belong in - and the user would be fetched into the group so permissions would be properly set. We did some remote debugging and found that: - ldap_fluff was able to retrieve the users for a group: "ldap_con.user_list(gid)", but not the groups for an user "ldap_con.group_list(uid)". - The reason it can't it's because it's nowhere to be found on OpenLDAP. On OpenLDAP, users could have an attribute "memberUID" which show the groups a user belong to. This customer didn't have the memberUID attribute enabled in their LDAP. - Satellite checks the groups for an user by checking memberUID, therefore it cannot find them. It does NOT iterate through every groups and check which are the users for every group. It doesn't do this because it's a much longer operation to do on every login. - 1 group_list(UID) call, versus N user_list(GID) calls. A possible fix would be to start doing that, checking every external group member list on every login from an LDAP auth source. This should be configurable as many customers with 10s of external user groups would find a noticeably slow login. ---- Waldirio, I'll shortly submit a patch here with a change you can make to get this working at AEP, but I am not sure if we will implement this yet (most likely not for 6.3 unless we see a lot of people with this problem).
Created attachment 1330900 [details] Patch for OpenLDAP lack of memberUID
*** Bug 1387824 has been marked as a duplicate of this bug. ***
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.