[Samba] File server questions

Thu Jun 4 14:25:13 UTC 2020

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
>