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