[SSSD-users] Re: UID collision possibility in SSSD with a mix of WindowsAD and non-AD domains?
On Thu, Oct 06, 2016 at 01:43:53PM -0000, sambitnayak+subscribe(a)gmail.com wrote:
Hi,
Requesting answers to some queries.
On a client system, SSSD can be configured to query identity and authenticate against
multiple domains - Windows Active Directory (AD) as well as non-AD ones like LDAP store or
say, FreeIPA.
I understand that SSSD offers ID mapping for Windows AD objects (users, groups etc.) to
offer a separate ID range/namespace for separate Windows AD domains.
(1) What about non-AD domains?
Can SSSD "map" separate ID ranges for different non-AD domains?
That is : assume that LDAP id provider backend is used by SSSD for the two non-AD domains
"abc.com" and "xyz.com".
Can SSSD allot two different UIDs to user "alice(a)abc.com" and
"alice(a)xyz.com" who have same UID in their respective domains?
No, the ID mapping is a feature specific to AD users and groups. For
historical reasons the related option is called 'ldap_id_mapping' and is
available in the plain LDAP provider as well. Nevertheless it is AD
specific as it requires that the user and group objects have a SID in
the related LDAP object.
If you have ID collisions with two configured LDAP domains you might
want to look at the local override feature, see man sss_override for
details.
(2) And, does SSSD ensure that ID ranges for such non-AD "abc.com" and
"xyz.com" will not clash with another Windows AD domain "win.com" that
SSSD is configured to work with? (I think the answer is yes here, but just double
checking...)
For non-AD domains, see above.
Even if you join SSSD to multiple AD domains this is not done
automatically because the collisions checks are preformed only inside of
a configured sssd domain, e.g. for each [domain/...] section in
sssd.conf separately. To be on the safe side you have to set
ldap_idmap_range_min and ldap_idmap_range_max for each configured domain
so that they won't overlap. We plan to make the id ranges configurable
in sssd.conf as well (https://fedorahosted.org/sssd/ticket/2651) which
would be an alternative to avoid collisions.
HTH
bye,
Sumit
>
> Thanks & Regards,
> Sambit
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org