[Users] webadmin login issues with AD

[Alon Bar-Lev]

----- Original Message -----
> From: "Keith Mitchell" <kamitch at cisco.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "Juan Antonio Hernandez Fernandez" <jhernand at redhat.com>, users at ovirt.org
> Sent: Sunday, March 3, 2013 5:48:48 PM
> Subject: Re: [Users] webadmin login issues with AD
> 
> On 3/3/13 10:12 AM, Yair Zaslavsky wrote:
> >
> > ----- Original Message -----
> >> From: "Keith Mitchell" <kamitch at cisco.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, users at ovirt.org, "Juan
> >> Antonio Hernandez Fernandez" <jhernand at redhat.com>
> >> 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 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
> >>>>
> >>> 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.
> > Keith,
> > Not sure I understood this, can you please elaborate?
> 
> Say you configure ovirt so that 'groupa' has some permissions.
> 
> Rather than enumerating every group the user belongs to and comparing
> the group name to one of the groups in the ovirt permissions list, we
> would enumerate the groups in the ovirt permissions list and then
> search
> for the authenticated user in those.  Then you only have enumerate
> groups that are actually used for authorization.  I bet that there
> are
> typically just a few groups used in the permissions list in a typical
> deployment.
> 
> The current method also seems to want to query the server to get all
> possible information and then make the decisions.  Ideally you want
> to
> do the fewest number of searches possible... and short circuit the
> authorization algorithm as soon as sufficient data is gathered. One
> common optimization is to compare all of the members of a group first
> before you start recursing to optimize for the direct member case.
> 
> In my current case I just have my user listed in the permissions. It
> should be able to fully authorize me without having to look at a
> single
> one of the group memberships...  here are no groups listed in ovirt
> so
> all it really needs to do is match the user.

Well, this is not entirely true.
Application need to gather user security profile which is the user and his roles.
Once the roles are in place, the privileges allocation can happen.
So application cannot really avoid searching the directory for groups.

The problem is that ovirt is not actually role based, I hope we can gradually improve this.

What we are working now is the actual LDAP interaction, I think it be more optimized then current implementation.

> 
> It was just a thought... I don't know much about the implementation
> of
> ovirt... just what I saw in the network trace.
> 
> For my initial deployment, it looks like i'm going to have to just
> use
> local authentication as this is just way to slow with our AD
> infrastructure currently.
> 
> >> 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...
> > One of the things we tested is introducing ldap connection pooling.
> > Unfortunately, the current JDK implementation automatically turns
> > off ldap connection pooling if more than one domain is used.
> > Ravi, care to elaborate a bit on your findings?
> >>
> >>
> >>
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>