[SSSD] Design Discussion: IPA Server Mode

Sumit Bose sbose at redhat.com
Mon Jun 10 09:45:08 UTC 2013


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

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

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.

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.



More information about the sssd-devel mailing list