[Samba] File server questions

Thu Jun 4 16:00:42 UTC 2020

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
>