Hi,
> 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.
This sounds exactly right. SSSD supports multiple domains and needs to
deal with UID ranges much more rigorously than samba.
yes, that's why the patch proposal uses the same logic as pure
Winbind/idmap_rid where mappings are controlled by smb.conf on per
domain basis - in this case mappings are controlled by sssd.conf on per
domain basis. Meaning that Winbind and SSSD would produce the same uid
mappings for the users of a domain if so configured. It would also seem
that the upcoming SSSD/Winbind backend uses the same approach so if
someone sees issues with this patch proposal those concerns would be
then valid with the SSSD/Winbind backend, too.
However, with this approach one doesn't need to run the additional
winbind daemon thus removing the need to join the machine to the AD
domain (which is a must with Winbind). As we all know AD administrators
rarely rejoice when one suggests any changes to their precious domain,
like joining a large number of Linux systems or adding the IdM for UNIX
service role and populating all the users with proper data.
we will loose SSSD functionality.
In this case we are talking about adding one small optional feature
which administrators can choose to use for additional domains if it
happens to fit their needs. If the feature is not used then nothing
changes. But it might well be a notable portion of administrators
interested in this given there'd be no need for the AD side Linux
machine accounts or the IdM for UNIX role in AD.
From the development perspective this also seems like a tempting
approach: me who haven't worked with SSSD code at all came up with this
patch in an hour or so meaning that while it of course needs some
polishing it is well contained and using production hardened code paths,
no intrusive changes or notable amount of new code needed.
Thanks,
--
Marko Myllynen