[SSSD] Design Discussion: IPA Server Mode

Simo Sorce simo at redhat.com
Wed Jun 5 16:43:32 UTC 2013


On Wed, 2013-06-05 at 18:31 +0200, Sumit Bose wrote:
> On Tue, May 28, 2013 at 01:20:15PM +0200, Sumit Bose wrote:
> > Hi,
> > 
> > I have created a design page for one of the next major features of SSSD
> > at https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode . The
> > basic idea is that if SSSD is running on a FreeIPA server it should help
> > the FreeIPA server to look up users and groups from trusted domains.
> > 
> > For your convenience the content can be found below as well.
> > 
> > Comments are suggestions are welcome.
> > 
> > bye,
> > Sumit
> > 
> 
> based on a discussion on the freeipa-devel mailing list I've add an
> additional section to 'Implementation details':
> 
> Remove assumption that subdomain users always have a primary
> user-private-group (UPG)
> 
> Currently the PAC responder assumes that subdomain users always have a
> UPG as primary group. This will be only true for domains with
> algorithmic mappings because here the POSIX IDs are managed by the
> FreeIPA server and we are free to choose. But if the POSIX IDs are
> manged externally we have to use what we get from external sources. E.g.
> in the case where the POSIX IDs are managed by AD UIDs and GIDs are
> separate name spaces and assuming the UPGs can be used would most
> certainly lead to GID conflicts. The PAC responder has to respect the
> idrange type or the mpg flag of the sss_domain_info struct and act
> accordingly.
> 
> Additional the code paths where new subdomains are created must be
> reviewed and whereever the mpg flag is set code must be added so that it
> is set according to the range type.
> 
> Although I think that the code path where an IPA client (i.e.
> ipa_server-mode = false) looks up a trusted domain user adds the user to
> the cache with the data it receives from the extdom plugin, it should be
> verified that UPGs are not implicitly assumed here as well.

It seem to me that what we are ending up with is that we need to come to
a final situation where mpg is only ever used at store time, but at
retrieve time it shouldn't

This will allow the cache to be authoritative and hold whatever matters.
We can do this w/o loosing some cache optimization by adding an
attribute to user objects if mpg was assumed at store time, and not
adding the flag if not. (the flag can be as simple as 'objectclass:
group' if nothing else breaks this way).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list