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? 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? 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? 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? Hoping you're all doing well, cheers, mathias
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'> 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.> > 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 'smbd' is the fileserver component of Samba and requires winbind when running with 'security = ADS'> > 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. Rowland
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 Thu, Jun 04, 2020 at 03:13:46PM +0200, 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?NetBIOS doesn't do authentication. It's provided as a naming lookup service by nmbd. That protocol isn't secure though, so it's recommended to not run nmbd. nmbd itself doesn't have any known security issues.
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: > [...] > > 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 > > 'smbd' is the fileserver component of Samba and requires winbind when > running with 'security = ADS' > > [...]I was very surprised to read that as on CentOS 7 using Samba 4.10.4-10.el7 and on Debian 10 using Samba 4.9.5+dfsg-5+deb10u1 I was able to get a working configuration were: - only smbd is running - Windows clients are using their AD account (and SSO mechanism) - once connected users can access to shares and contained files and directories for modification. Used smb.conf in both cases: ---------------------------------------------------------------------------- [global] # AD access realm = AD.DOMAIN.TLD workgroup = AD security = ads kerberos method = secrets and keytab log level = 3 username map = /etc/samba/usermap server string = serveur #============================ Share Definitions =============================[sharename] path = /sharename writeable = yes browseable = yes guest ok = yes create mask = 0644 ---------------------------------------------------------------------------- These two test systems are using /etc/passwd and /etc/group as users and groups databases. It seems the "requirement" is not so required and so I'm kind of puzzled. mathias