[ovirt-users] LDAP-based domain not working after upgrade?

Mon Aug 15 12:28:42 UTC 2016

On 08/13/2016 12:44 AM, nicolas at devels.es wrote:
> El 2016-08-12 20:38, Ondra Machacek escribió:
>> On 08/12/2016 05:53 PM, nicolas at devels.es wrote:
>>> El 2016-08-10 14:46, Nicolás escribió:
>>>> En 10/8/2016 2:29 p. m., Alexander Wels <awels at redhat.com> escribió:
>>>>
>>>>> On Wednesday, August 10, 2016 9:02:16 AM EDT Alexander Wels wrote:
>>>>
>>>>>> On Wednesday, August 10, 2016 9:10:25 AM EDT nicolas at devels.es
>>>>> wrote:
>>>>
>>>>>>> El 2016-08-10 08:58, Ondra Machacek escribió:
>>>>
>>>>>>> > On 08/10/2016 09:37 AM, Nicolás wrote:
>>>>
>>>>>>> >> Hi,
>>>>
>>>>>>> >>
>>>>
>>>>>>> >> We're running oVirt 4.0.1.1 [1], and we're trying to grant a
>>>>> permission to
>>>>
>>>>>>> >> a
>>>>
>>>>>>> >> user on a VM. Thing is when we open the 'Permissions' subtab
>>>>> on that
>>>>
>>>>>>> >> VM,
>>>>
>>>>>>> >> we click on Add, the LDAP backend shows up but any value
>>>>> entered into
>>>>
>>>>>>> >> the search box returns nothing, even when I know the values
>>>>> exist.
>>>>
>>>>>>> >>
>>>>
>>>>>>> >> This has been working on oVirt 3.x, we actually migrated to
>>>>> 4.x last
>>>>
>>>>>>> >> week and didn't notice this issue.
>>>>
>>>>>>> >>
>>>>
>>>>>>> >> Additionally, there's no combobox to choose the permission to
>>>>> grant?
>>>>
>>>>>>> >
>>>>
>>>>>>> > There should be combo box to choose a role.
>>>>
>>>>>>>
>>>>
>>>>>>> I've attached a screenshot, seems there's not.
>>>>
>>>>>>
>>>>
>>>>>> Its highly likely the dropdown is there, but its scrolled below
>>>>> the bottom
>>>>
>>>>>> of the dialog and thus you can't see it. I thought I made sure all
>>>>> the
>>>>
>>>>>> dialogs were working, seems like I missed one. Let me check it out
>>>>> and see
>>>>
>>>>>> what is going on.
>>>>
>>>>>>
>>>>
>>>>>
>>>>
>>>>> Okay I double checked, I went to the VMs main tab, selected a VM,
>>>>> then went to
>>>>
>>>>> the permissions sub tab. Clicked add. The dialog that popped up
>>>>> looks like the
>>>>
>>>>> one attached, which is what I was expecting. The one you attached
>>>>> appears to
>>>>
>>>>> be missing some styling, which is likely what caused the Role to
>>>>> Assign part
>>>>
>>>>> to be scrolled below the bottom of the page.
>>>>
>>>>>
>>>>
>>>>> Can you complete clear your cache (not shift reload, but
>>>>> settings->clear
>>>>
>>>>> cache). If that doesn't work can you tell us the version of the
>>>>> patternfly rpm
>>>>
>>>>> installed on your engine?
>>>>
>>>>>
>>>>
>>>>> Yes, I already did that, also opened the engine on different clients
>>>>> and the behavior is the same, I believe this is not a client issue.
>>>>> Patternfly package is patternfly1-1.3.0-1.el7.centos.noarch
>>>>
>>>
>>> Ok, this indeed seems like a graphics problem since I am seeing this
>>> connecting to a machine through a VNC server and the Role combobox is
>>> moved down out of the dialog.
>>>
>>> However, the LDAP issue persists. When I choose the 'internal' domain, I
>>> can search the 'admin' user successfully, however, if I set it to be the
>>> LDAP domain, any search returns nothing.
>>>
>>> Any hints or ideas how to debug this?
>>
>> Can you please enable debug log[1] and send it here?
>>
>> [1]
>> https://github.com/oVirt/ovirt-engine-extension-aaa-ldap/blob/master/README#L442
>>
>>
>
> Thanks. I was now able to see why it is failing:
>
> TRACE [org.ovirt.engineextensions.aaa.ldap.Framework] (default task-13)
> [] SearchRequest: Exception: LDAPSearchException(resultCode=11 (admin
> limit exceeded), numEntries=0, numReferences=0, errorMessage='admin
> limit exceeded')

This is server error, that number of entries to be returned is higher, 
than the limit set on server.
You should either increase that limit server side, or don't use '*', but 
use some filter. ( ie. user* )

>
> Indeed, if I run that query using the ldapsearch command I can clearly
> see it is returning an "admin limit exceeded" error.
>
> The applied filter is:
> (&(objectClass=posixAccount)(uid=*)(|(givenName=username)(sn=username)(displayName=username)(uid=username)))
>
>
> Strange thing is this hasn't been an issue on oVirt 3.6.x and we've not
> changed our LDAP configuration. Has the filter been changed in 4.x by
> default?

It didn't.

>
> If so, is there a way to override the filter to make it simpler? (In our
> case we'll always seek by username, so no need to search by givenName,
> sn or displayName).
>

Filtering is constructed on client side, in this case ovirt-engine backend,
so unfortunatelly it's not easilly modifiable.

> Thanks.
>
>>>
>>> Thanks.
>>>
>>>
>>>>>
>>>>
>>>>> Anyhow, I see there are lots of packages to update so I'll do so
>>>>> within a few days and report results.
>>>>
>>>>>
>>>>
>>>>>>> >> All this is done with the admin at internal user, so I guess
>>>>> this is not
>>>>
>>>>>>> >> a
>>>>
>>>>>>> >> self-permission issue.
>>>>
>>>>>>> >>
>>>>
>>>>>>> >> Interesting thing is that I can successfully log-in to the
>>>>> user portal
>>>>
>>>>>>> >> with a LDAP based user and manage all the VMs assigned to
>>>>> them.
>>>>
>>>>>>> >>
>>>>
>>>>>>> >> Just to see if there's been any configuration change, we also
>>>>> run the
>>>>
>>>>>>> >> ovirt-engine-extension-aaa-ldap-setup tool, the configuration
>>>>> it
>>>>
>>>>>>> >> returns
>>>>
>>>>>>> >> is pretty similar to ours, and even the test commands (Login,
>>>>> Search)
>>>>
>>>>>>> >> work successfully (I can see search returning user's data
>>>>> like name,
>>>>
>>>>>>> >> surname, ...). We even applied this configuration to engine
>>>>> to see if
>>>>
>>>>>>> >> it
>>>>
>>>>>>> >> makes a difference but the result is the same, the search
>>>>> dialog
>>>>
>>>>>>> >> returns
>>>>
>>>>>>> >> nothing and neither I can see the permission to grant.
>>>>
>>>>>>> >>
>>>>
>>>>>>> >> Any hint about this?
>>>>
>>>>>>> >
>>>>
>>>>>>> > Maybe you hit similar issue to this one[1].
>>>>
>>>>>>> >
>>>>
>>>>>>> > Can you please share engine.log, while you hit search button?
>>>>
>>>>>>>
>>>>
>>>>>>> I'm also attaching the log at the time I hit the search button,
>>>>> but I'm
>>>>
>>>>>>> afraid there's no entry about that.
>>>>
>>>>>>>
>>>>
>>>>>>> Thanks.
>>>>
>>>>>>>
>>>>
>>>>>>> > [1] https [2]://bugzilla.redhat.com/show_bug.cgi?id=1356675
>>>>> [2]
>>>>
>>>>>>> >
>>>>
>>>>>>> >> Thanks
>>>>
>>>>>>> >> _______________________________________________
>>>>
>>>>>>> >> Users mailing list
>>>>
>>>>>>> >> Users at ovirt.org
>>>>
>>>>>>> >> http [3]://lists.ovirt.org/ [3]mailman [3]/ [3]listinfo [3]/
>>>>> [3]users [3]
>>>>
>>>>>>
>>>>
>>>>>> _______________________________________________
>>>>
>>>>>> Users mailing list
>>>>
>>>>>> Users at ovirt.org
>>>>
>>>>>> http [3]://lists.ovirt.org/ [3]mailman [3]/ [3]listinfo [3]/
>>>>> [3]users [3]
>>>>
>>>>> _______________________________________________
>>>>
>>>>> Users mailing list
>>>>
>>>>> Users at ovirt.org
>>>>
>>>>> http [3]://lists.ovirt.org/ [3]mailman [3]/ [3]listinfo [3]/
>>>>> [3]users [3]
>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1] http://4.0.1.1
>>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1356675
>>>> [3] http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users