[Freeipa-devel] [RFC] Serving legacy systems cliens for trusts

Sumit Bose sbose at redhat.com
Mon Jun 3 16:22:56 UTC 2013


On Mon, Jun 03, 2013 at 03:32:05PM +0200, Sumit Bose wrote:
> On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote:
> > Hi,
> > 
> > 
> > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
> > 
> > 
> > === CLI ===
> > 
> > The feature is not directly exposed in CLI.
> > 
> > IPA idrange management is expanded to specify idrange type (IPA local,
> > AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users
> > SIDs are mapped to POSIX IDs.
> > 
> 
> Hi,
> 
> currently with algorithmic mapping we use user-private groups for all
> trusted user. This is in agreement with the defaults for IPA users and
> also matches with AD's RID handling because a single namespace for UIDs
> and GIDs is forced this way.
> 
> When adding support for UIDs and GIDs stored in AD we cannot do this
> anymore because AD (correctly) treats POSIX UIDs and GIDs as separate
> name spaces. As a consequence SSSD has to treat algorithmic mapping and
> IDs-in-AD mapping differently with respect to user private groups.
> 
> My question is, shall SSSD implicitly do the right thing based on the
> type of the idrange, or shall there be an extra attribute in the idrange
> object which explicitly says if the range has user private groups or
> not?
> 
> I think it is not needed because for both current mappings there is only
> one choice but maybe someone can think of a reason for such an
> attribute.

We discussed this a bit and came to the following agreement:
- no extra attribute is needed
- for all idranges type where IPA is assigning the ID user-private groups
  will be used (local IPA users, algorithmic mappings)
- for all idranges where the IDs are managed by external sources we use
  what we get

bye,
Sumit

> 
> bye,
> Sumit
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel




More information about the Freeipa-devel mailing list