Re: [Samba] WinbinD no longer available in Samba 4.7.6
- Date: 9 Dec 2018 09:07:19 -0500
- From: Konstantin Boyandin via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] WinbinD no longer available in Samba 4.7.6
On 05.12.2018 15:36, Rowland Penny via samba 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.
I added some parameters to the smb.conf generated by classic upgrade
>>> 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.
I believe you. In practice, in our rather small domain, that slowdown
wasn't an issue. But yes, outside of health checks, the enumeration has
no critical importance.
>>> 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
(hereinafter 'man smb.conf'), the default value is 'template'. How does
winbind nss info = template
; winbind nss info = template
? I can only see one possible difference - if at some point in future
the default changes.
>>> 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
dns proxy = yes
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.
>>> 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.
>>> 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
So, two questions:
1. Will explicitly setting the default make any difference
2. Will omitting it break the current TDB-based setup ?
>> 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.
Since they are set to defaults, does it actually matter?
>> 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.
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)
2. Do not include parameters with default values
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.
Thanks for your insights.
To unsubscribe from this list go to the following URL and read the