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

Jakub Hrozek jhrozek at redhat.com
Mon Aug 26 19:41:09 UTC 2013


On Mon, Aug 26, 2013 at 03:35:09PM -0400, Simo Sorce wrote:
> On Mon, 2013-08-26 at 21:17 +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
> 
> it could be a huge set, and would cause a huge load if someone runs a
> puppet script to reconfigure and restart a few 1000 machines with sssd.
> 

A huge set of external groups?

> >     2. store the largest lastUSN to the server mode context
> 
> we already have this afaik

No we don't. This is new code just for the server mode.

> 
> >     3. on subsequent lookups, only download and store groups with higher
> >        lastUSN
> 
> if you change server you are back to square zero though
> 

Which is never during in the server mode. (except for slapd outages etc)

> >     4. perform the lookup always. It's on the server after all so
> >        network LDAP search is quite cheap.
> 
> not sure I understand what this means ?

The current patch re-downloads external groups every 600 seconds and if
600 seconds hasn't passed, uses cache. I'm proposing we download
(&(objectClass=externalGroup)(lastUSN>=stored_last_usn)) on every
request because in the server mode the latency is not an issue.

> 
> 
> The point of checking initgroups at login is to assure the right
> memberships are in place, both for security reasons and to allow a user
> to logoff and login back again and make sure eh gets new group
> memberships if he has been granted any new ones.
> 
> Loggin off then back on is the only way to gain system-wide the new
> memberships so that's what an administrator will tell a user to do if
> the user complains he can't access something.
> 
> This means that caching can't last long as the side effects are severe.
> So anything more than a few seconds would probably be bad. A few seconds
> make total sense for load issues when someone is abusing pam atuh (for
> example someon eusing basic auth wired to pam auth for a a web server
> that will receive potentially many tens of authentications for the same
> user within a fraction of a second as each image and file is loaded in a
> new connection).
> 
> In this case you really want to completely cache the whole operation and
> not touch the network for any reason, otherwise latency will make things
> unbearable. But that's the extent to which you want to go, a few seconds
> for auth bursts, nothing more.
> 
> Simo.

The latency in the server mode is really small, we should always be
talking to the local server.



More information about the sssd-devel mailing list