Re: [Users] webadmin login issues with AD

From: "Keith Mitchell" <kamitch(a)cisco.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt; Cc: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt;, users(a)ovirt.org, "Juan Antonio Hernandez Fernandez" <jhernand(a)redhat.com&gt; Sent: Sunday, March 3, 2013 5:02:59 PM Subject: Re: [Users] webadmin login issues with AD On 3/3/13 8:37 AM, Itamar Heim wrote: > On 03/03/2013 15:26, Keith Mitchell wrote: >> On 3/3/13 7:42 AM, Yair Zaslavsky wrote: >>> >>> ----- Original Message ----- >>>> From: "Keith Mitchell" <kamitch(a)cisco.com&gt; >>>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; >>>> Cc: users(a)ovirt.org, "Juan Antonio Hernandez Fernandez" >>>> <jhernand(a)redhat.com&gt;, "Itamar Heim" <iheim(a)redhat.com&gt; >>>> 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@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 >> > > actually the issue is not getting the list of groups, rather than > ovirt is is checking which other groups these groups are part of, > to > make sure user gets the right permissions from nested groups as > well. > we didn't find an easy way to do this which doesn't involve looping > on > all the groups. > is this common for most users in your AD to have 300-400 groups? > > Thanks, > Itamar Yes, my case is fairly typical of our AD setup. Not sure what other apps are doing here, but I do know that it doesn't take this long to get logged in :) Maybe they only look at direct group membership? Or they do things in reverse... i.e. look up the groups in the access list to determine if the user that is authenticating can be found rather than traversing all the groups a user is a member of and trying to match all those groups to a group (or username) on the access list. That might run into the same issue if the group had lots of group members as opposed to user members.

Changing the way the searches are made may speed up things too (if thats possible with the framework) to not reconnect for each search and to do multiple searches on the same connection. From my network capture each search request was taking about 1.5 seconds (from the bind request to the unbind request). Just some thoughts...