Le jeu. 4 juin 2020 ? 15:43, Rowland penny via samba <samba at lists.samba.org> a ?crit :> On 04/06/2020 14:13, mathias dufresne via samba wrote: > > Hi everyone, > > > > I'm back working on Samba subjects and rather than writing stupidities, I > > decided to come and use your knowledge : ) > > > > nmbd: in modern configurations running nmbd is not necessary and could > > perhaps even be seen as security issue: it seems to allow NetBIOS > > authentication which is not secure. > > Is that true or not? > As far as I am aware 'nmbd' is used for network browsing etc and it > requires SMBv1, If you are not using SMBv1, you can remove 'nmbd' >OK, so in short, nmbd needs SMBv1 and so must be removed in any secured configuration. (And thanks to the Samba team to keep it for older configurations : )> > winbindd: is responsible to grab information from AD to produce system > > users (through NSS) and possibly provides a way for these generated > system > > users to authenticate against AD (through PAM) > > Is that true or not? > Define 'system users', if you mean users like 'www-data' etc, then these > have nothing to do with AD. If you mean the users in AD, then, yes, > winbind is used to authenticate them, amongst other things. >System users are users which can be used in system side. Typically those in /etc/passwd but for a more generic approach I mean "each and every users available through 'getent passwd [username]'" In fact winbindd seems to me responsible to grab AD information to generate user lines like those in /etc/passwd. These lines will be added to system user list if and only if NSS is configured to using "winbind" keyword in /etc/nsswitch.conf. Now for these system users coming from AD, for they can authenticate (ie use their AD password and log into the system, like having a shell) this is managed by pam_winbind.so and PAM configuration. Without PAM configured we can have winbindd generating users which will be available in "getent passwd" commands (with the need of username mentioned if enumeration is not permitted into smb.conf) but these users won't be usable in interactive sessions, they won't be able to authenticate in system side. And when I write "[users] won't be able to authenticate in system side" that does not mean they won't be able to use Samba. Samba uses its own way through smbd to authenticate its own users (even for users coming from AD).> > > smbd: the file server, at least for modern usage. It can also grab user > > information from AD but not for system users, only for Samba users (the > > applicative users, used to authenticate when accessing Samba and later, > to > > shares) > > Is that true or not? > > Not any more, smbd used to be able to fallback to AD, but this was > removed at 4.8.0 >What do you mean by "smbd used to be able to fallback to AD"?> > 'smbd' is the fileserver component of Samba and requires winbind when > running with 'security = ADS' >I do have configurations where Samba users are coming from AD and Winbind is not running. System users are in my client's case stored into /etc/passwd. They don't have lines in /etc/shadow, these system useres can't be used (as long as goes my system knowledge) to gain access to some shell or any interactive session. So I do not believe winbind is a requirement. See previous part about winbindd on my views about winbindd is meant for.> > > > > smb.conf -> username map: when adding "root = administrator" in the file > > referenced by "username map", the Samba user named administrator will be > > granted access to files that root system user can access. If some system > > user is named administrator too, remote/Samba user named administrator > will > > not have access to files owned by system's administrator user. > > Is that true or not? > > Probably not, though I have never tried it ;-) > > If you have a user called 'administrator' in /etc/passwd , this user > would be used first on the computer because it is 'passwd files winbind' > in /etc/nsswitch.conf , but I would still expect winbind to map > 'Administrator' to 'root' when connecting via Samba. >Here it's also a bit more complex than that. Using 'passwd files winbind'in /etc/nsswitch.conf and adding in /etc/passwd lines with username which is already existing into AD, final system user (ie what you get when using "id username") will be a mix of passwd information and AD information. This is quite surprising but still. filesrv:~# id username *uid=2103(username) gid=20000002(domain users)* groups=20000002(domain users),100(users),20000001(domain admins),1001(BUILTIN\users) filesrv:~# grep username /etc/passwd #username:x:2103:2103::/home/username:/bin/bash filesrv:~# vi /etc/passwd filesrv:~# grep username /etc/passwd username:x:1234:1234::/home/username:/bin/bash filesrv:~# id username *uid=1234(username) gid=1234 groups=1234*,100(users),20000002(domain users),20000001(domain admins),1001(BUILTIN\users) I believe to avoid that behaviour, I would have to change "passwd: files winbind" in something like "passwd: files [success=return] winbind". Unfortunately I haven't yet found the right syntax to confirm that. Anyway, don't bother about that one, I'll make some deeper tests. Cheers ; )> Rowland > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
On 04/06/2020 15:25, mathias dufresne wrote:> > System users are users which can be used in system side. Typically > those in /etc/passwd but for a more generic approach I mean "each and > every users available through 'getent passwd [username]'"'system users' are usually the users with an ID of less than 1000> > In fact winbindd seems to me responsible to grab AD information to > generate user lines like those in /etc/passwd. These lines will be > added to system user list if and only if NSS is configured to using > "winbind" keyword in /etc/nsswitch.conf.Yes, but it also depends on a correctly setup smb.conf.> > Now for these system users coming from AD, for they can authenticate > (ie use their AD password and log into the system, like having a > shell) this is managed by pam_winbind.so and PAM configuration. > > Without PAM configured we can have winbindd generating users which > will be available in "getent passwd" commands (with the need of > username mentioned if enumeration is not permitted into smb.conf) but > these users won't be usable in interactive sessions, they won't be > able to authenticate in system side.No, Samba will know and use them, but the underlying OS wouldn't.> > And when I write "[users] won't be able to authenticate in system > side" that does not mean they won't be able to use Samba. Samba uses > its own way through smbd to authenticate its own users (even for users > coming from AD).smbd when joined to AD cannot authenticate since 4.8.0, it now uses winbind (this is one of the reasons you cannot use sssd any more).> > > > What do you mean by "smbd used to be able to fallback to AD"?Before 4.8.0, sssd used to be able to connect to AD without winbind, this is no longer possible.> > > 'smbd' is the fileserver component of Samba and requires winbind when > running with 'security = ADS' > > > I do have configurations where Samba users are coming from AD and > Winbind is not running. System users are in my client's case stored > into /etc/passwd. They don't have lines in /etc/shadow, these system > useres can't be used (as long as goes my system knowledge) to gain > access to some shell or any interactive session. > So I do not believe winbind is a requirement. See previous part about > winbindd on my views about winbindd is meant for.They are probably using a Samba version before 4.8.0. From 4.8.0 and using 'security = ADS', you must run winbind and you cannot have the same users in /etc/passwd and AD, users in /etc/passwd are local users.> > > > > > smb.conf -> username map: when adding "root = administrator" in > the file > > referenced by "username map", the Samba user named administrator > will be > > granted access to files that root system user can access. If > some system > > user is named administrator too, remote/Samba user named > administrator will > > not have access to files owned by system's administrator user. > > Is that true or not? > > Probably not, though I have never tried it ;-) > > If you have a user called 'administrator' in /etc/passwd , this user > would be used first on the computer because it is 'passwd files > winbind' > in /etc/nsswitch.conf , but I would still expect winbind to map > 'Administrator' to 'root' when connecting via Samba. > > > Here it's also a bit more complex than that. Using 'passwd files > winbind'in /etc/nsswitch.conf and adding in /etc/passwd lines with > username which is already existing into AD, final system user (ie what > you get when using "id username") will be a mix of passwd information > and AD information. This is quite surprising but still. > > filesrv:~# id username > *uid=2103(username) gid=20000002(domain users)* groups=20000002(domain > users),100(users),20000001(domain admins),1001(BUILTIN\users) > filesrv:~# grep username /etc/passwd > #username:x:2103:2103::/home/username:/bin/bash > filesrv:~# vi /etc/passwd > filesrv:~# grep username /etc/passwd > username:x:1234:1234::/home/username:/bin/bash > filesrv:~# id username > *uid=1234(username) gid=1234 groups=1234*,100(users),20000002(domain > users),20000001(domain admins),1001(BUILTIN\users)There is a name for that, it is 'botch' Some how (and I do not want to know how), you seem to be mixing local Unix users and Domain groups.> I believe to avoid that behaviour, I would have to change "passwd: ? ? > ? ? files winbind" in something like "passwd: ? ? ? files > [success=return] winbind". Unfortunately I haven't yet found the right > syntax to confirm that. > > Anyway, don't bother about that one, I'll make some deeper tests. >I wont bother about it, it is your mess to fix ;-) Rowland
Le jeu. 4 juin 2020 ? 16:48, Rowland penny via samba <samba at lists.samba.org> a ?crit :> On 04/06/2020 15:25, mathias dufresne wrote: > > > > System users are users which can be used in system side. Typically > > those in /etc/passwd but for a more generic approach I mean "each and > > every users available through 'getent passwd [username]'" > 'system users' are usually the users with an ID of less than 1000 >:D Yes, you're right. But I do believe this distinction as nothing to do here. If some Samba server has local/system user declared with UID > 1000 it is still a valid user for this system and as it a server, this user and its UID has to be taken in consideration when preparing smb.conf and "range *". Then, what's left? Samba user database and system users databases. So, Samba users and system users. Sorry about that but that's the best way I found to make this clear in my fellow colleagues heads.> > > > In fact winbindd seems to me responsible to grab AD information to > > generate user lines like those in /etc/passwd. These lines will be > > added to system user list if and only if NSS is configured to using > > "winbind" keyword in /etc/nsswitch.conf. > Yes, but it also depends on a correctly setup smb.conf. >... sure, we're speaking about Samba configuration and winbind is part of Samba.> > > > Now for these system users coming from AD, for they can authenticate > > (ie use their AD password and log into the system, like having a > > shell) this is managed by pam_winbind.so and PAM configuration. > > > > Without PAM configured we can have winbindd generating users which > > will be available in "getent passwd" commands (with the need of > > username mentioned if enumeration is not permitted into smb.conf) but > > these users won't be usable in interactive sessions, they won't be > > able to authenticate in system side. > No, Samba will know and use them, but the underlying OS wouldn't. >So, that's a yes :D> > > > And when I write "[users] won't be able to authenticate in system > > side" that does not mean they won't be able to use Samba. Samba uses > > its own way through smbd to authenticate its own users (even for users > > coming from AD). > smbd when joined to AD cannot authenticate since 4.8.0, it now uses > winbind (this is one of the reasons you cannot use sssd any more). >That is very interesting. As my current client has some Samba version which can authenticate AD users without winbind, knowing that is very important, they should update their servers soon and not knowing that would father lot of useless questions : )> > > > > > > > What do you mean by "smbd used to be able to fallback to AD"? > Before 4.8.0, sssd used to be able to connect to AD without winbind, > this is no longer possible. >ok> > > > > 'smbd' is the fileserver component of Samba and requires winbind when > > running with 'security = ADS' > > > > > > I do have configurations where Samba users are coming from AD and > > Winbind is not running. System users are in my client's case stored > > into /etc/passwd. They don't have lines in /etc/shadow, these system > > useres can't be used (as long as goes my system knowledge) to gain > > access to some shell or any interactive session. > > So I do not believe winbind is a requirement. See previous part about > > winbindd on my views about winbindd is meant for. > They are probably using a Samba version before 4.8.0. From 4.8.0 and > using 'security = ADS', you must run winbind and you cannot have the > same users in /etc/passwd and AD, users in /etc/passwd are local users. >I just reconnect on my client's VPN and they are using CentOS 7 and Samba 4.10.4-10.el7. Samba authentication is in ADS mode, only smbd is running, all works like a charm.> > > > > > > > > > smb.conf -> username map: when adding "root = administrator" in > > the file > > > referenced by "username map", the Samba user named administrator > > will be > > > granted access to files that root system user can access. If > > some system > > > user is named administrator too, remote/Samba user named > > administrator will > > > not have access to files owned by system's administrator user. > > > Is that true or not? > > > > Probably not, though I have never tried it ;-) > > > > If you have a user called 'administrator' in /etc/passwd , this user > > would be used first on the computer because it is 'passwd files > > winbind' > > in /etc/nsswitch.conf , but I would still expect winbind to map > > 'Administrator' to 'root' when connecting via Samba. > > > > > > Here it's also a bit more complex than that. Using 'passwd files > > winbind'in /etc/nsswitch.conf and adding in /etc/passwd lines with > > username which is already existing into AD, final system user (ie what > > you get when using "id username") will be a mix of passwd information > > and AD information. This is quite surprising but still. > > > > filesrv:~# id username > > *uid=2103(username) gid=20000002(domain users)* groups=20000002(domain > > users),100(users),20000001(domain admins),1001(BUILTIN\users) > > filesrv:~# grep username /etc/passwd > > #username:x:2103:2103::/home/username:/bin/bash > > filesrv:~# vi /etc/passwd > > filesrv:~# grep username /etc/passwd > > username:x:1234:1234::/home/username:/bin/bash > > filesrv:~# id username > > *uid=1234(username) gid=1234 groups=1234*,100(users),20000002(domain > > users),20000001(domain admins),1001(BUILTIN\users) > > There is a name for that, it is 'botch' > > Some how (and I do not want to know how), you seem to be mixing local > Unix users and Domain groups. >It is not only that it seems they are mixed, they are mixed ; ) I do believe this can be due to my lack of knowledge about NSS and so, an error in my configuration (as I explained eralier in fact).> > > I believe to avoid that behaviour, I would have to change "passwd: > > files winbind" in something like "passwd: files > > [success=return] winbind". Unfortunately I haven't yet found the right > > syntax to confirm that. > > > > Anyway, don't bother about that one, I'll make some deeper tests. > > > I wont bother about it, it is your mess to fix ;-) >This configuration which uses local /etc/passwd is not what I recommend to them. Pkus they don't want to have Samba/MS domain user able to connect on Samba server system. So, no winbind keyword in NSS configuration. I just wrote this paragraph to show you your misunderstanding about Linux/NSS/winbind behaviour ; )> > Rowland > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >