[Samba] WinbinD no longer available in Samba 4.7.6

[Rowland Penny]

On 9 Dec 2018 09:07:19 -0500
Konstantin Boyandin via samba <samba at lists.samba.org> wrote:

> >>>          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.
> 
> Now that's confusing. According to
> 
> https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
> 
> (hereinafter 'man smb.conf'), the default value is 'template'. How
> does
> 
> winbind nss info = template
> 
> differ from
> 
> ; winbind nss info = template
> 
> ? I can only see one possible difference - if at some point in future
> the default changes.

I will say it again, 'winbind nss info' is only of use on a Unix
domain member (and then only before 4.6.0), it is useless on an AD DC.

> 
> >>>          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.
> 
> That's even more confusing. According to 'man smb.conf', the default
> value is
> 
> dns proxy = yes

Yes, but that is a default setting and is ignored on a DC, mainly
because the DC is a dns server, so how can it be a dns proxy as well ?

> 
> But you tell me that 'no' is wrong, and that 'yes' is wrong, too. If
> default value is 'yes', what difference does explicitly setiing is to
> 'yes' make ?
> 
> In our setup, the AD DCs running Samba 4 (there are 2, and I plan to
> add third) support their domain zone (*.example.com). Historically,
> LAN uses other DNS servers. Now they forward all example.com inquires
> to AD DCs, and the latter forward other LAN-specific inquiries to the
> mentioned non-domain DNS servers. This setup works quick enough and
> seems quite sane.

That is sane, but what does it have to do with a dns proxy ?

> 
> >>>          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
> 
> Is there any esoteric reason to not use the default (self-signed)
> certificate files names?
> 
> Most our services, Windows' including, dislike self-signed
> certificates, and I try to eliminate any default ones.

Yes, but you seem to have have used the default names for your Samba
certificates, if you have, then there is no need to have the lines in
smb.conf. If you have certs by different names, then sanitise the lines
in a way that shows this, it would have stopped this conversation in
its tracks.

> 
> >>>          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.
> 
> Once again, the default value mentioned in 'man smb.conf' is
> 
> passdb backend = tdbsam

Yes, sorry, that was a big mistake on my part, it used to be something
different, just goes to show anybody can make a mistake ;-)
However, because it is a default, it doesn't actually need to be there,
less is better in my view.


> > [...]
> >> 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.
> 
> Samba Wiki looks like a Lego blocks collection, with little or no
> actual config examples provided. Unless one knows the intrinsics by
> heart, the entire recommended options set isn't self-obvious.

I agree the wiki could be better, one of the problems is all the
hyper-links, but a way around this has been found.
 
> 
> Basically, your critique of the configuration I posted, boils down to
> these two pieces of advice
> 
> 1. Don't add anything above automatically generated (by classic
> upgrade) parameters

No, be very wary of adding lines to a Samba AD DC without being very
sure they are needed and will actually work, but this also goes for any
Samba smb.conf

> 2. Do not include parameters with default values

Because they don't actually need to be there.

> 
> Note: we were using Samba 3 domain (OpenLDAP backend + smbldap tools)
> for 12 years, it worked without major issues, and I learned that its
> configuration was somewhat brittle - minor changes in seemingly
> non-critical settings could wreak havoc. That's why I prefer to see
> defaults to the parameters I saw in Samba 3.

Samba 3 is a very different beast to Samba 4, especially when run as an
AD DC. There are many reasons why you shouldn't use a Samba AD DC as a
fileserver and a lot of the parameters and ways that worked with Samba
3, no longer work, or work differently.
 
Rowland