On Wed, Jun 12, 2013 at 06:19:38PM +0200, Jakub Hrozek wrote:
On Mon, Jun 10, 2013 at 11:45:08AM +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
> >
>
> I added bullet points 3 and 4 to 'Enhance libsss_idmap' and extended
> number 2. If there is no disagreement I will open/extended the related
> tickets in the evening.
>
> bye,
> Sumit
>
Sorry for late response.
np, thank you for the review.
> Enhance libsss_idmap
>
> 1. Allow algorithmic mapping where the first RID is not 0
> Currently it is implicitly assumed that the first POSIX ID of a range is mapped to
the RID 0. To support multiple ranges for a single domain a different first RID must
handled as well.
> Ticket: #1938
>
> 2. Add a range type to handle mappings in AD
> The idea is that ranges for IDs from AD can be used in libsss_idmap as well, but
whenever a mapping is requested for this range a specific error code like
IDMAP_ASK_AD_FOR_MAPPING is returned to tell SSSD to do an AD lookup. This way SSSD does
not need to inspect the ranges itself but all is done inside if libsss_idmap. Additionally
a new call is needed to check whether the returned externally managed ID belongs to a
configured range, if not the ID cannot be mapped in the given configuration and the
related object should be ignored.
> Ticket: #1960
>
Ack
updated #1960
> 3- Add an optional unique range identifier
> To be able to detect configuration changes in idranges managed by FreeIPA an
identifier should be stored on the client together with the other idrange related data.
For simplicity the DN of the related LDAP object on the FreeIPA server can be used here.
>
Ack
created #1979 and assigned it to me, because I already have a patch
> 4. Allow updates and removal of ranges
> To support configuration changes at runtime, it must be possible to update and
remove ranges. As a first step I would recommend that the changes will only affect new
requests and not the cached data, because in general changes to centrally manages ranges
should be done with care to avoid conflicts. In a later release we can decided if we just
want to invalidate all cached entries of the domain which idrange was modified or if a
smarter check is needed to invalidate only objects which are affected by the change.
Do we need to support runtime changes even now? It sounds like a future
enhancement to me..
yes, the most common use case is to read and include new ranges which we
already cover. Runtime changes should be rare and imo should be only
done with great care.
I created #1981 and put it in 1.11 beta, but marked it as minor, so that
it can be pushed out to a later version.
Also, how exactly (and where) would the configuration changes be
performed? Using some IPA config tool?
yes
bye,
Sumit
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel