On Fri, Jan 10, 2014 at 02:54:46PM +0100, Sumit Bose wrote:
On Fri, Jan 10, 2014 at 02:35:12PM +0100, Jakub Hrozek wrote:
> On Fri, Jan 10, 2014 at 12:59:05PM +0100, Sumit Bose wrote:
> > On Tue, Dec 17, 2013 at 09:00:25PM +0100, Jakub Hrozek wrote:
> > > Hi,
> > >
> > > the attached patches address ticket
> > >
https://fedorahosted.org/sssd/ticket/2142
> > >
> > > There are some things I'm still not satisfied with and one of them is
> > > refreshing subdomains. Currently the subdomain refresh happens after
> > > startup and then only if a direct lookup for a user or group happens and
> > > the timeout for subdomain refresh is over. So in theory it's possible
> > > that the user and group objects will be refreshed by the enumeration
> > > task only and there would be no lookup to trigger the subdomain refresh.
> > >
> > > With master domain enumeration we've solved this problem by
> > > re-downloading master domain info before the enumeration request. We
> > > could do something similar with subdomains (although a little more
> > > involved becase there is always precisely one subdomain), but I
didn't
> > > like doing all the changes in 1.11.3. I can code up additional patch
> > > only for master, though.
> > >
> > > Something similar is with fallback from GC to LDAP. Although here I'm
> > > not convinced we need to perform the fallback at all, since there are
> > > already patches on the list that implement the option to disable GC
> > > lookups and there will also be a patch to autodetect POSIX attributes in
> > > GC.
> > >
> > > These patches must be applied on top of my previous patches.
> >
> > Can you rebase these patches and their prerequisites? They do not apply
> > to master anymore. I also cloud not apply "AD: Retry and terminate
> > sdap_id_op if possible".
Hi,
the "AD: Retry and terminate sdap_id_op if possible" patch is not
strictly required, so I haven't rebased and resent it yet.
>
> Sure, will do.
>
> >
> > Based on the experience with AD group-memberships and the recent
> > changes where we switch back from GC to LDAP to determine
> > group-memberships I would suggest to use the LDAP connect for the group
> > enumeration as well.
>
> The last word in a private mini-thread with Simo was to use LDAP for the
> parent domain by default and GC elsewhere, right? I would also like to
> check all code is consistent when changing these patches.
I think in the general only universal group can be retrieve correctly
form the GC. If we read LDAP for the parent domain there are still the
global groups from the other domains which might be incomplete in the
GC.
I've been testing the enumeration quite a bit and unfortunately I
found a defect that is not so easily fixed with the current enumeration
architecture. Because the original patches enumerated the primary domain and
subdomain separately, cross-domain memberships were hard, if not impossible
to maintain, at least because there was no guarantee on the order or
completeness of enumeration.
So attached are rebased the original patches with the connections fixed
as you liked. But cross-domain memberships don't work.
I have two additional patches, one finished and one WIP in my ad_enum branch:
http://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/log/?h=ad_enum
The first makes sure the original_member contains the original DN and
not sysdb DN :-) The other is not finished but my intent was to
1) check if any subdomains were enumerated. If not, do nothing
2) if any of the groups saved had more original members than sysdb
members, check if members of these groups can be linked now that all
users and groups are saved.
I hope this would be acceptable, because the cost is only incurred if
subdomains are enumerated and there are cross-domain memberships at the
same time.. Any other solution I could think of would require bigger
changes, but I'd welcome other ideas.