Konstantin Boyandin
2018-Dec-05 02:57 UTC
[Samba] WinbinD no longer available in Samba 4.7.6
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.> 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).> winbind nss info = rfc2307 > > The above line is only any use on a Unix domain member and then, only > before Samba 4.6.0That makes sense, set it explicitle to 'template'.> dns proxy = no > > Really, on a DC that relies on DNS ?Again, makes sense, set to 'yes'.> 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 settingsYes, with the mentioned certificate files taken from real-life certificate for the real-life domain name we use.> 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. 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 ADReasonable, set both to default.> 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 memberThanks, 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. Sincerely, Konstantin
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 >
Konstantin Boyandin
2018-Dec-09 14:07 UTC
[Samba] WinbinD no longer available in Samba 4.7.6
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.pemIs 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