[Samba] File server questions

[Rowland penny]

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