Thank you for the response, Rowland. Very helpful and we would like to move to a more modern setup. Your suggestion to move to AD means getting rid of NIS, correct? Using the users and groups from AD rather than NIS. I agree that this would be a better place to be, but have never been clear about the transition since our infrastructure has been based on NIS for so long. Can I simply run some Samba servers in the old style while converting others to all AD? Because of NFS back-end, our multiple Samba servers can serve the same files - \\SAMBA1\homes and \\SAMBA2\homes can all find my home directory. I think that Winbind handles the ID mapping between SIDs and UIDs, but I have not idea how that would work across multiple Samba servers doing things differently. -- Shannon -----Original Message----- From: Rowland Penny <rpenny at samba.org> Sent: Saturday, September 17, 2022 10:51 AM To: samba at lists.samba.org Subject: Re: [Samba] Samba 4 without winbind On 17/09/2022 16:17, Shannon Price via samba wrote:> > We support our Windows clients via Samba since the 1990s. Our main infrastructure is NIS/NFS to support our servers and Linux clients. We have Samba using ADS for authentication for many years, but our users and groups still come from NIS. Our last Samba server is running on Ubuntu 18 (Samba 4.7.6) and is rock solid using smbd/nmbd. Our newest Samba server is running on Ubuntu 20.04 (Samba 4.11.6 - we found severe problems with the current versions: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1954342 and have pinned Samba at 4.11.6 for now). We're running it the same way we always have - the machine is ADS joined (net join ads ....). I experimented with winbind for quite a while, but we don't need AD groups or user attributes, so it seems unnecessary and we couldn't get our NIS groups to work when we did that even trying to monkey with nsswitch.conf using nis for groups.NIS is dead. The link you provided refers to an old way of doing things, NT4-style domains aren't dead yet, but they are staggering along on their last legs. From Samba 4.8.0 if security is set to 'domain' or 'ads' you must run winbind.> > The problem now is only that I have full access to everything with unqualfied names (\\SERVER\homes<file://SERVER/homes> works), but FQDN (\\server.domain.edu\homes<file://server.domain.edu/homes>) doesn't work and the debug logs show that Samba wants winbind whenever I talk to the server with FQDN. > > Logs with FQDN: > [2022/09/17 08:40:16.941558, 0] ../../source3/auth/auth_winbind.c:120(check_winbind_security) > check_winbind_security: winbindd not running - but required as > domain member: NT_STATUS_NO_LOGON_SERVERS > [2022/09/17 08:40:16.943204, 2] ../../source3/auth/auth.c:343(auth_check_ntlm_password) > check_ntlm_password: Authentication for user [USERNAME] -> > [USERNAME] FAILED with error NT_STATUS_NO_LOGON_SERVERS, > authoritative=1 > [2022/09/17 08:40:16.943300, 2] > ../../auth/auth_log.c:635(log_authentication_event_human_readable) > > Logs without FQDN: > 131.204.17.34 (ipv4:131.204.17.34:28915) connect to service > USERNAME initially as user USERNAME (uid=12345, gid=123) (pid 454545) > [2022/09/17 10:15:38.595009, 0] > ../../source3/param/loadparm.c:3358(process_usershare_file) > > > Smb.conf > > [global] > # workgroup and naming > workgroup = DOMAIN > netbios name = SAMBASERVERNAME > > # server settings > interfaces = MY IP ADDRESS > bind interfaces only = yes > deadtime = 15 > strict locking = no > > # disable server ntlmv1 support > # require ntlmv2.1 or higher (windows 7 and up) > server min protocol = SMB2_10 > client max protocol = SMB3 > client min protocol = SMB2_10You do not need the 'protocol' lines, from 4.11.0 the 'min' ones have been set to SMB2 and the max ones were set to SMB3 quite some time ago.> > security = ads > password server = KERBEROS SERVERYou shouldn't set that, allow Samba to find the best one.> passdb backend = tdbsam > realm = DOMAIN.EDU > idmap config * : backend = tdb > idmap config * : range = 1000000-1999999That is totally wrong, you do not '9999999' for the default domain and there should be lines for the 'DOMAIN' domain.> > > # browsing settings > domain master = no > local master = no > preferred master = no >I suggest you upgrade to AD as soon as possible. Rowland
Hi Shannon, It is highly recommended to keep Samba-AD-DC servers separate from Samba SMB fileservers. In other words you should not serve home-dirs from a domain-controller. I would setup new AD-controllers next to the current servers (even more so because they seem to be SMB-servers as well). Then either so setup new SMB-servers or you join the SMB-servers as members to the domain. Is it correct that you serve the SMB home-dirs from a mounted NFS-share? I would think that could cause problems with ACLs, but probably Rowland has more knowledge about that. - Kees On 18-09-2022 17:46, Shannon Price via samba wrote:> Thank you for the response, Rowland. Very helpful and we would like to move to a more modern setup. > > Your suggestion to move to AD means getting rid of NIS, correct? Using the users and groups from AD rather than NIS. I agree that this would be a better place to be, but have never been clear about the transition since our infrastructure has been based on NIS for so long. Can I simply run some Samba servers in the old style while converting others to all AD? Because of NFS back-end, our multiple Samba servers can serve the same files - \\SAMBA1\homes and \\SAMBA2\homes can all find my home directory. I think that Winbind handles the ID mapping between SIDs and UIDs, but I have not idea how that would work across multiple Samba servers doing things differently. > > -- > Shannon > > -----Original Message----- > From: Rowland Penny <rpenny at samba.org> > Sent: Saturday, September 17, 2022 10:51 AM > To: samba at lists.samba.org > Subject: Re: [Samba] Samba 4 without winbind > > > > On 17/09/2022 16:17, Shannon Price via samba wrote: >> We support our Windows clients via Samba since the 1990s. Our main infrastructure is NIS/NFS to support our servers and Linux clients. We have Samba using ADS for authentication for many years, but our users and groups still come from NIS. Our last Samba server is running on Ubuntu 18 (Samba 4.7.6) and is rock solid using smbd/nmbd. Our newest Samba server is running on Ubuntu 20.04 (Samba 4.11.6 - we found severe problems with the current versions: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1954342 and have pinned Samba at 4.11.6 for now). We're running it the same way we always have - the machine is ADS joined (net join ads ....). I experimented with winbind for quite a while, but we don't need AD groups or user attributes, so it seems unnecessary and we couldn't get our NIS groups to work when we did that even trying to monkey with nsswitch.conf using nis for groups. > NIS is dead. > The link you provided refers to an old way of doing things, NT4-style domains aren't dead yet, but they are staggering along on their last legs. > > From Samba 4.8.0 if security is set to 'domain' or 'ads' you must run winbind. > >> The problem now is only that I have full access to everything with unqualfied names (\\SERVER\homes<file://SERVER/homes> works), but FQDN (\\server.domain.edu\homes<file://server.domain.edu/homes>) doesn't work and the debug logs show that Samba wants winbind whenever I talk to the server with FQDN. >> >> Logs with FQDN: >> [2022/09/17 08:40:16.941558, 0] ../../source3/auth/auth_winbind.c:120(check_winbind_security) >> check_winbind_security: winbindd not running - but required as >> domain member: NT_STATUS_NO_LOGON_SERVERS >> [2022/09/17 08:40:16.943204, 2] ../../source3/auth/auth.c:343(auth_check_ntlm_password) >> check_ntlm_password: Authentication for user [USERNAME] -> >> [USERNAME] FAILED with error NT_STATUS_NO_LOGON_SERVERS, >> authoritative=1 >> [2022/09/17 08:40:16.943300, 2] >> ../../auth/auth_log.c:635(log_authentication_event_human_readable) >> >> Logs without FQDN: >> 131.204.17.34 (ipv4:131.204.17.34:28915) connect to service >> USERNAME initially as user USERNAME (uid=12345, gid=123) (pid 454545) >> [2022/09/17 10:15:38.595009, 0] >> ../../source3/param/loadparm.c:3358(process_usershare_file) >> >> >> Smb.conf >> >> [global] >> # workgroup and naming >> workgroup = DOMAIN >> netbios name = SAMBASERVERNAME >> >> # server settings >> interfaces = MY IP ADDRESS >> bind interfaces only = yes >> deadtime = 15 >> strict locking = no >> >> # disable server ntlmv1 support >> # require ntlmv2.1 or higher (windows 7 and up) >> server min protocol = SMB2_10 >> client max protocol = SMB3 >> client min protocol = SMB2_10 > You do not need the 'protocol' lines, from 4.11.0 the 'min' ones have been set to SMB2 and the max ones were set to SMB3 quite some time ago. > >> security = ads >> password server = KERBEROS SERVER > You shouldn't set that, allow Samba to find the best one. > >> passdb backend = tdbsam >> realm = DOMAIN.EDU >> idmap config * : backend = tdb >> idmap config * : range = 1000000-1999999 > That is totally wrong, you do not '9999999' for the default domain and there should be lines for the 'DOMAIN' domain. > >> >> # browsing settings >> domain master = no >> local master = no >> preferred master = no >> > I suggest you upgrade to AD as soon as possible. > > Rowland > > >
On 18/09/2022 16:46, Shannon Price via samba wrote:> > Thank you for the response, Rowland. Very helpful and we would like to move to a more modern setup. > > Your suggestion to move to AD means getting rid of NIS, correct? Using the users and groups from AD rather than NIS. I agree that this would be a better place to be, but have never been clear about the transition since our infrastructure has been based on NIS for so long. Can I simply run some Samba servers in the old style while converting others to all AD? Because of NFS back-end, our multiple Samba servers can serve the same files - \\SAMBA1\homes and \\SAMBA2\homes can all find my home directory. I think that Winbind handles the ID mapping between SIDs and UIDs, but I have not idea how that would work across multiple Samba servers doing things differently. > > -- > Shannon > >Samba provides several different ways of mapping AD users & groups to Unix ID's, the main ones are the 'autorid', 'rid' and 'ad' backends. 'autorid' is the easiest to set up, you just add a couple of lines to the smb.conf: idmap config * : backend = autorid idmap config * : range = 10000-9999999 'rid' is very similar: idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config DOMAIN : backend = rid idmap config DOMAIN : range = 10000-999999 Neither of the above requires adding anything to AD, the first calculates the Unix ID from the Windows RID and allows multiple domains without any further lines. The second again works in a similar way, but is only used for a single domain, you can add further 'DOMAIN' lines for trusted domains. 'ad' works differently, but uses lines very similar to the 'rid' variant (and you can add multiple domains like the 'rid' backend), there is one big difference, you must add rfc2307 attributes to AD. This may be a way out of your difficulties, NIS will have its own ID's and you should be able to use these for your user & group uidNumber & gidNumber attributes. Which ever backend you use, if you use the same basic smb.conf on every Unix machine, you will always get the same ID's. You should also be aware that you cannot have the same username or group name in /etc/passwd & /etc/group that also exists in AD, the former will always be used first. My advice would be to just have users & groups in AD, apart for one or two local Unix Admins, just in case anything goes wrong. If you require any further information, just ask. Rowland