> this simple patch allows using AD objectSid as uid source making
> possible to use SSSD against AD instances which do not have Identity
> Management for Unix Role Service enabled. The mapping matches winbind's
> idmap_rid(8) behaviour. If ldap_user_uid_number is not objectSid then
> nothing changes.
We've discussed this upstream and we can't accept this patch. There are
a number of issues that we need to consider with this. Winbind's
approach to ID mapping makes an unhealthy assumption that it is the ONLY
source of user data on the client system.
I'm not sure I follow you here - with Winbind idmap backends you can
configure an id range to use for each domain. What kind of issues do you
see with that approach and why do you consider it unhealthy?
Furthermore, the domain mapping algorithm here can cause conflicts
local users in the 1000+ range.
This is the reason the patch proposal had:
uid = uid + dom->id_min;
At minimum, we'd need to come up with a deterministic design that
allow multiple AD and non-AD domains to work at the same time, and start
at some reasonable minimum ID (such as 10,000).
I think this is already there but instead of relying some artificial
hard coded figure such as 10,000 min_id was used from the domain section
The problem with doing that is that it would only work for clients
SSSD (because it would not map to the same IDs as clients using winbind
directly). So before any action was taken on this, we'd need to
coordinate with the Samba project to change their mapping algorithm as
This sounds backwards to me. I think we should regard Samba/Winbind as
the gold standard in this area and if anything related gets added to
SSSD it should follow Winbind conventions.
Since both idmap_rid and my patch proposal have the same scheme for id
mapping I fail to see what is the fundamental issue with the proposal
(leaving secondary issues like the configuration option name to use for
this out of the discussion for now)?
Note that I won't consider it as the end of the world even if a revised
version of the patch won't get in but I see that with a relatively small
effort we could make lives of administrators in mixed Linux/Windows
environments so much easier it'd be certainly worth it.