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.
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
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
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..
Also, how exactly (and where) would the configuration changes be
performed? Using some IPA config tool?