[SSSD] [PATCH] ipa-server-mode: add IPA group memberships to AD users

Jakub Hrozek jhrozek at redhat.com
Mon Aug 26 19:56:54 UTC 2013


On Mon, Aug 26, 2013 at 09:41:57PM +0200, Sumit Bose wrote:
> On Mon, Aug 26, 2013 at 09:17:29PM +0200, Jakub Hrozek wrote:
> > On Mon, Aug 26, 2013 at 06:18:05PM +0200, Sumit Bose wrote:
> > > On Mon, Aug 26, 2013 at 05:20:21PM +0200, Jakub Hrozek wrote:
> > > > On Fri, Aug 23, 2013 at 03:44:09PM +0200, Sumit Bose wrote:
> > > > > Hi,
> > > > > 
> > > > > currently in ipa-server-mode only the AD groups memberships are
> > > > > available. This patch adds the IPA group memberships to trusted AD
> > > > > users.
> > > > > 
> > > > > This patch is missing some unit tests for some of the helper functions.
> > > > > I will send them later, but I didn't want to delay the next release.
> > > > > 
> > > > > bye,
> > > > > Sumit
> > > > 
> > > > I haven't done any testing yet but do we need the timeout? Since the
> > > > initgroups is a rare operation and on logins we generally want to have
> > > > the correct memberships, can we just rely on responder caching?
> > > 
> > > I was thinking of situations where multiple logins happen in a short
> > > time. Additionally I think even if group memberships of a user might
> > > change often the mapping of AD to IPA group memberships via the external
> > > groups will only change rarely.
> > > 
> > > Maybe we can a cache time option to make it more flexible?
> > > 
> > > bye,
> > > Sumit
> > 
> > I was thinking about this more on my way home and I think you're
> > right we need to optimize the ipa_server_mode. This could cause the "8AM
> > login rush" to be a real bottleneck. 
> > 
> > But I think we can exploit the fact that we know the server well during
> > the ipa_server_mode. What about this approach?
> >     1. on startup we download all external groups
> >     2. store the largest lastUSN to the server mode context
> >     3. on subsequent lookups, only download and store groups with higher
> >        lastUSN
> >     4. perform the lookup always. It's on the server after all so
> >        network LDAP search is quite cheap.
> 
> I think this scheme would not detect deleted external groups.
> 
> bye,
> Sumit

Ah, right. Sorry, I tested that member modification would bump the USN
but forgout about deletion.

Then maybe we could use the scheme you came up in Brno to compare
existing DNs with originalDNs in the cache?



More information about the sssd-devel mailing list