[Samba] WinbinD no longer available in Samba 4.7.6

Konstantin Boyandin lists at boyandin.info
Sun Dec 9 14:07:19 UTC 2018


Hello,

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
command.

>>>          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

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.

>>>          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

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)
parameters
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.

Sincerely,
Konstantin





More information about the samba mailing list