[Samba] WinbinD no longer available in Samba 4.7.6

[Rowland Penny]

On Wed, 05 Dec 2018 09:57:56 +0700
Konstantin Boyandin via samba <samba at lists.samba.org> wrote:

> Rowland Penny via samba писал 2018-12-04 17:17:
> > On Tue, 04 Dec 2018 16:45:43 +0700
> > Konstantin Boyandin via samba <samba at lists.samba.org> wrote:
> > 
> >> 
> >> Are there possibly missing some winbind settings (the smb.conf has
> >> been generated by domain upgrade process).
> >> 
> > 
> > Sorry, but I do not believe that is true:
> 
> True. The configuration works. I assume that parameters that aren't  
> applicable to AD DC role, are just ignored, even if mentioned.

No it isn't true, you have added to your smb.conf, no Samba tools would
have produced your smb.conf.

> 
> >          winbind enum users = yes
> >          winbind enum groups = yes
> > 
> > The lines above should only be used for testing purposes, they
> > serve no other purpose.
> 
> According to the 'man smb.conf', "On large installations using 
> winbindd(8) it may be necessary to suppress enumeration...". Orus
> isn't large installations (number of users and computers taken
> together is below 100).

Believe me, it can slow things down and the only thing that is does is
make 'getent passwd' & 'getent group' work without supplying a
username or groupname. You do not need it.
 
> 
> >          winbind nss info = rfc2307
> > 
> > The above line is only any use on a Unix domain member and then,
> > only before Samba 4.6.0
> 
> That makes sense, set it explicitle to 'template'.

Changing it makes no sense, just remove it.

> 
> >          dns proxy = no
> > 
> > Really, on a DC that relies on DNS ?
> 
> Again, makes sense, set to 'yes'.

Again, changing it makes no sense. Making something a dns proxy at the
same time as it is an authoritative dns server is just wrong.

> 
> >          tls enabled  = yes
> >          tls keyfile  = tls/key.pem
> >          tls certfile = tls/cert.pem
> >          tls cafile   = tls/ca.pem
> >          tls verify peer = no_check
> >          acl:search = no
> > 
> > They are default settings
> 
> Yes, with the mentioned certificate files taken from real-life 
> certificate for the real-life domain name we use.

Those are default certificate locations and names, if you have your own
certs, then sanitise it in a way that shows this e.g. tls/ourkey.pem

> 
> >          passdb backend = tdbsam
> > 
> > Big mistake, you have turned off the correct password database.
> 
> I assume you are talking about ldapsam. Again, our installation isn't 
> huge to feel the impact of the passwords backend.

No, I do not mean 'ldapsam', just remove the line.

> 
> Also, I might get somewhat confused by the 'classic upgrade' 
> description, where old ldapsam was explicitly disabled in favor of 
> switching to tdbsam.
> 
> >          obey pam restrictions = yes
> > 
> > Useless on a DC
> > 
> >          unix password sync = yes
> > 
> > Extremely useless on a DC, you cannot have Unix users in /etc/passwd
> > and AD
> 
> Reasonable, set both to default.

reasonable is not adding them.

> 
> >          passwd program = /usr/bin/passwd %u
> >          passwd chat = *Enter\snew\s*\spassword:* %n\n
> > *Retype\snew\s*\spassword:
> >          pam password change = yes
> >          map to guest = bad user
> >          usershare allow guests = yes
> > 
> > Only of real use on a Unix domain member
> 
> Thanks, set to default.
> 
> > [profiles]
> >          comment = Users profiles
> >          path = /srv/samba/profiles/
> >          browseable = No
> >          read only = No
> >          force create mode = 0600
> >          force directory mode = 0700
> >          csc policy = disable
> >          store dos attributes = yes
> >          vfs objects = acl_xattr
> > 
> > The above is a cut & paste from here:
> > 
> > https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles
> > 
> > The only problem is, it also tells you, just above that block on the
> > page, that it doesn't work on an AD DC.
> 
> Actually, I used the 'above block' to set the permissions from
> Windows system.
> 
> Question is, do the above settings actually conflict (I noticed no 
> problems so far), if I do not attempt to change whatever after the 
> mentioned permissions change has been performed?
> 
> I really appreciate your comments. Pity there are no 'typical'
> smb.conf examples for typical roles, such as AD DC.

The info is in the Samba wiki.

The best thing with the smb.conf on an AD DC is to not add anything to
it, if possible. If you have to add something to it, add as little as
possible and follow the Samba wiki.

Rowland

> 
> Sincerely,
> Konstantin
>