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

Sumit Bose sbose at redhat.com
Mon Aug 26 19:41:57 UTC 2013


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
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list