[Users] webadmin login issues with AD

[Keith Mitchell]

On 3/3/13 7:42 AM, Yair Zaslavsky wrote:
>
> ----- Original Message -----
>> From: "Keith Mitchell" <kamitch at cisco.com>
>> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> Cc: users at ovirt.org, "Juan Antonio Hernandez Fernandez" <jhernand at redhat.com>, "Itamar Heim" <iheim at redhat.com>
>> Sent: Sunday, March 3, 2013 2:28:38 PM
>> Subject: Re: [Users] webadmin login issues with AD
>>
>> On 3/3/13 6:57 AM, Yair Zaslavsky wrote:
>>> Please elaborate on "quite a few groups" - actually this is a well
>>> known issue.
>>> I was afraid you might have permissions on "too many objects" or
>>> that the account is a member of too many groups.
>>> However, being a member of too many groups should have caused the
>>> search to be slow/hang as well.
>> I don't have an exact count, but I think its along the order of
>> magnitude of 300-400.
> Hi,
> I gave an incorrect explanation before (I thought about it and understood where my error lies ).
> If I add a user using engine-manage-domains and do not provide -addPermissions, I will still be able to login to the system using admin at internal, and perform search for users & groups.
> This means I do not need to have permissions for the user I added for that domain to perform search so the "permissions" check is of course not performed at search!
>
> The number of groups is important in login - oVirt will try to calculate all the permissions of the users, and this is based on the permission the user have directly on an object, or that its group has.
> If the user is a member of 300 groups, oVirt tries to get information for all that groups.
> THis is why login hands, but search does not hang.
I guess I don't understand why ovirt needs to do that.  You should be 
able to get the list of groups a user is a member which I thought was 
sufficient for most apps to determine authorization.

I know we use AD authentication for a lot of things and i've never hit 
this before.

Changing the AD config isn't something I can do so it sounds like there 
is no workaround and i'll just have to live with the local 
authentication.  Or pehaps I can stick some ldap server in front of AD that