Description of problem: when adding a LDAP user if the user is a member of a group with upper case letters in the OU for the group the roles assigned to said group will not be inherited by the user. Version-Release number of selected component (if applicable): This was observed in Ovirt 3.2 and 3.3 when connected to a 389 server version 1.2.11.15 when connected in RHDS mode How reproducible: fairly simple Steps to Reproduce: 1. create a group in 389 server where the name or OU contain at lease on capital letter 2. add the group in ovirt and assign roles to it 3. create a user in 389 server and make it a member of the group previously created in step 1. 4. add the user in ovirt Actual results: the user will not inherit any roles from the group. also you will see 00000000-0000-0000-0000-000000000000 in the group_ids field of the ad_groups table in the database Expected results: the user should inherit the roles assigned to the group Additional info: The problem is the memberof plugin in 389 server normalizes the OU's for the groups to all lower case. When the user is added it looks like it trying to match the group name via a exact match in the ad_groups table instead of an ilike. A simple workaround is to update the ad_groups table manually and change the contents of the name field in the ad_groups table to lowercase. Also interesting to note is you can still modify the roles for the group without any issue after you have changed it to lower case. This was discussed on the user mailing list here http://lists.ovirt.org/pipermail/users/2014-August/026765.html
3.3 version will not get fixes, please check with latest 3.4.z before reporting new issues, thanks! most probably already fixed in the new ldap implementation within 3.5. not sure it worth the effort of z-stream for 3.4. QA note: please test using new ldap implementation, if ok, please mark as verified with component ovirt-engine-extension-aaa-ldap.
the issue has also been confirmed in 3.4
Paul, Have you modified only the group names or also the domain at the ad_groups table? I have checked 3.4.3 code - we look for groups in db based on the domain name and the external id .
sorry for the delayed response I only changed the group name
*** This bug has been marked as a duplicate of bug 1131179 ***