[Samba] Debian client/workstation pam_mount

Rowland penny rpenny at samba.org
Sun Sep 27 12:57:29 UTC 2020


On 27/09/2020 12:57, Robert Wooden wrote:
> The sshgroup exists on the client/workstation:
>
>     root at lws4:~# cat /etc/groups
>
>     .....................
>
>      sshgroup:x:998:adminlinux
>
>     .....................
>
>
> But, on my member server that acts as a fileserver for domain users 
> (redirected) files there is no "sshgroup" at this time.
>
> The AD has server-ssh group:
>
>     root at dc1:~# samba-tool group listmembers server-ssh
>     tuser17
>     tuser16
>
>
>  I went back and found Louis' email where he explained these two 
> groups. Here is part of that email:
>
>     Created "server-ssh" group in AD and gave it a GID.
>     Add the needed windows users that are allowed to ssh in the server,
>     only windows users in this one.
>
>     Create group "sshgroup" on member server (in Debian?)<<<<<< maybe
>     Louis meant member fileserver and not client/workstation and I
>     misunderstood?
>     yes, add the admin users for the system ( ONLY linux users here)
>
This is why I always refer to Linux members of an AD domain as 'Unix 
domain members', it is what you do with it, that says what it is capable 
of. If you use it to serve files, it is a fileserver, if you use it to 
print things, it is a printserver and so on.
>
> First, let me clarify, I am not saying Louis is incorrect here but 
> rather i think I misunderstood.
Common mistake.
>
> For me this 'client/workstation/member server' computers (generic 
> machines names) names get merged together and /create confusion/.
>
> Here is where I think (IMHO) the Linux (Debian, in my case) 
> client/workstations (C/W) are a different type of machine on the 
> network and yet carry many of the same characteristics of all member 
> servers (fileserver) just without any local (on the 
> client/workstations) shares. Maybe these machines should be called 
> "client/workstation members" and member fileserver should be referred 
> to as "member file servers" serving files to domain users logging into 
> to a "client/workstation members" weather it be a Linux based C/W or a 
> W10 based C/W? And not "lump" all member server (file servers) and 
> linux based member servers (who are actually a client/workstation) 
> together as all member servers?
>
> Like so:
> W10 client/workstation or W10 C/W for short.
> Linux client/workstation or Linux C/W for short.
> Domain Controller is a DC (of course).
> Domain member server is a member file server for the domain C/W's 
> domain users are logging into.

Forget everything, call a DC a DC, every other Unix computer that is a 
member of an AD domain is Unix domain member, in the same way that every 
PC running Windows is a Windows domain member, it is what you do with it 
that determines its role.


>
> Is the "sshgroup" to be created on the member server (fileserver) that 
> is the file server for the W10/Debian client/workstations (C/W) domain 
> users? Or, on both the fileserver and the Debian client/workstations 
> (C/W)? Or, only on the client/workstations (C/W)?
>
> Your suggesting that 'tuser16' needs to be a member of 'sshgroup' and 
> I do not understand how to make a domain user (tuser16) a member of a 
> linux group on a member server or a client/workstation?
>
> Perhaps you see now why I may have confused what users get what group 
> on what domain computer?

Yes, perhaps Louis could have explained better why he creates two 
groups, but he probably thought it was self-explanatory. You need two 
groups, one a local Unix group and the other created in AD that will be 
available to all Unix domain members. If, for some reason, there is a 
problem with the AD connection, a local Unix user can still log in via 
ssh to try and fix things.


You add AD users to the AD group and local Unix users (users not in AD) 
to the local Unix group.

You should be aware that you do not need to use groups at all with ssh, 
it is only required if you wish to only allow certain users the ability 
to log in via ssh.

Rowland





More information about the samba mailing list