[Samba] AD domain member with sssd: any downside not running winbindd?

[steve]

On Tue, 2014-01-28 at 10:19 +0100, Michael Adam wrote:
> On 2014-01-28 at 08:39 +0100, steve wrote:
> > On Tue, 2014-01-28 at 09:37 +1300, Andrew Bartlett wrote:
> > > 
> > > The key point here is *on the DC*.  On the domain member server,
> > > winbindd still does all these things, just like it has for quite some
> > > time.  It is more of a pain to configure than I would like, but it can
> > > do it.
> > > 
> > > Andrew Bartlett
> > > 
> > 
> > Thank you. Common sense comments from a developer. Summary:
> > 1. On the DC it doesn't work.
> 
> On the DC you don't need it:
> A Samba AD/DC has its limited built-in winbind task
> which is going to be replaced by the superior
> winbindd at least when we are starting to support
> trusted domains.
> 
> It is also correct that you currently can't run the
> separate winbindd daemon together with the AD/DC's
> built-in winbind.
> 
> But if you plug anything other than winbind into nsswitch
> on a Samba AD/DC, particularly, anything that does
> id mapping differently, then I guess you'll end up
> in trouble since the shell will have a different notion
> which UID belongs to a user than samba has...
> 
> So why do you really want or need to use something else
> than winbind in nsswitch on the AD/DC?

Hi
Our domain contains many Linux workstations. We create user accounts on
the DC by populating the rfc2307 attributes. We need to check that they
are correct without having to go to e.g. a member server or a Linux
client. sssd or nss-ldapd allows us to do that. It makes it easy for me
to get us out of trouble when something goes wrong like file access: I
can do it all on the DC, mount files, check permissions... Unorthodox
maybe, but a lifesaver when working with poor quality hardware within a
strict budget.
Cheers,