Hey,
Shyam Prasad N <nspmangalore@xxxxxxxxx> writes:
>> IIRC the keyring used is the session one, so each user gets a different keyring.
>
> Ah, I see. So I'm wondering how the multiuser mounts for ntlmssp work?
> On each login, does the user have to populate the keyring with his/her
> credentials?
I think that was the idea yes, or maybe integrate with PAM somehow? But
you'll have to do some archeological work with Jeff Layton to get to the
bottom of this :)
> Agreed for majority cases. But Steve makes a good point that this only
> gets us the local uid/username.
> However, the actual domain user name could be very different. For
> example, local user user1 could be logged in as domain1\user1 or
> domain2\user1. How do we handle this scenario?
This is a sadistic puzzle game with many pieces...
If the Linux client is properly integrated with AD ({winbind or ssd} +
PAM module + nsswitch conf), you login with your AD user and get an AD
uid. There is no local user.
$ ssh 'NUC\administrator@192.168.122.50'
Password:
Last login: Mon Sep 21 10:41:34 2020 from 192.168.122.1
Have a lot of fun...
NUC\administrator@twmember:~> id
uid=20501(NUC\administrator) gid=20514(NUC\domain users) groups=20514(NUC\domain users),10000(BUILTIN\administrators),10001(BUILTIN\users),20501(NUC\administrator),20513(NUC\domain admins),20519(NUC\schema admins),20520(NUC\enterprise admins),20521(NUC\group policy creator owners),20573(NUC\denied rodc password replication group),21108(NUC\netmon users)
$ mount.cifs //adnuc.nuc.test/data /x -o sec=krb5i,multiuser,cifsacl,username=administrator,domain=NUC
$ ls -l /x
-rwx------ 1 NUC\user1 NUC\domain users 0 Aug 5 22:14 from_u1
-rwx------ 1 NUC\user2 NUC\domain users 0 Aug 5 22:16 from_u2
I don't know what is the situation at Redhat but at SUSE the only
supported way to use multiuser mounts (if even documented) is via a
properly AD-joined system and kerberos. Even then, I think I've only
seen 1 ticket from a multiuser setup in 5 years. Most setups are 1 mount
per user for user dirs, where it makes sense to have everything owned by
the user.
> I'm guessing (please correct me if I'm wrong here) that an user
> session corresponds to only one of those two remote users
> (domain1\user1 or domain2\user1). In that case, how do we get the
> fully qualified name in the context of this session?
At the SMB level you only see Windows SIDs and cifs.ko will report all
files as being owned by the mounter's uid (or uid= mount opt).
When you mount with cifsacl mount option, cifs.ko will try to map those
SIDs to uids by upcalling cifs.idmap. This program will ultimately query
winbind or sssd to get the mapping.
So userspace tools will see AD uids. Now to get the text username from
it they use regular POSIX libc calls like getpwuid(). If your system is
properly integrated with AD, this call gets rerouted via nsswitch to
again use winbind/sssd.
There is a book that covers some of this called "Mechanics of User
Identification and Authentication: Fundamentals of Identify
Management". It's from 2007 but still relevant. Here's a diagram from
page 96: https://i.imgur.com/PBwXIuJ.png
Glibc:
https://www.gnu.org/software/libc/manual/html_node/Lookup-User.html
Nsswitch: allows to replace the various traditional text-based databases
of the system (/etc/passwd, /etc/hosts, ....) by calling into different
backends.
https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html
nsswitch winbind backend:
https://gitlab.com/samba-team/samba/-/blob/master/nsswitch/winbind_nss_linux.c
cifs.idmap plugin API:
https://github.com/piastry/cifs-utils/blob/master/idmap_plugin.h
cifs.idmap winbind backend (ships with cifs-utils):
https://github.com/piastry/cifs-utils/blob/master/idmapwb.c
cifs.idmap sssd backend (ships with sssd):
https://github.com/SSSD/sssd/blob/12f74f8c98fac6a7eeb3937f623949bcb3adb547/src/lib/cifs_idmap_sss/cifs_idmap_sss.c
Cheers,
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
