Hi Lars, Machine credentials are useful when using automounts so that the share can be mounted before a kerberos ticket is available. That's pretty much all allows you to do from a technical perspective, so its good for /home directories. I just think its the easiest way if you are already part of the AD or some other kerberos realm, but "pretending" root is some other user in the AD, also works as a concept. I'm not going to describe implementation because you may not need it.
yum install autofs5 For each user, work out their id (N), gid (M), name, where you want to put the share on the local file system (lets say /basepath/username), the SMB server (S) and the path to share on the server (P/U). Add this to /etc/auto.master ################### /basepath /etc/auto.smb ################### where auto.smb looks like this, with one line for each user, replacing the capital letters with the relevant information related to your setup. U -fstype=cifs,sec=krb5,uid=N,cruid=N,gid=M,$OTHEROPTS "://S/P/U" OK a real example would be: brisbane -fstype=cifs,hard,intr,sec=krb5,uid=10624,cruid=10624,gid=30160,$OTHEROPTS "://cifsserver.com/Users/brisbane" The user need will need to have have logged in or otherwise have a kerberos ticket before the share is accessible. You can add "multiuser" to the list of $OTHEROPTS above, but under my understanding of what you are doing you don't need to (though I'd definitely look into the file_mode=0700 and dir_mode=0700 mount options if you havn't already). My comments about multiuser are actually only important if more than one user needs access to the same files. Looking at what you are trying to do (mount a user's own personal share - I think). All you really need is a kerberos ticket available before you try to mount the share, but for /home directories, the above wont work so I go back to root credentials mechanism. I'll say there are a number of ways to do this and it may not be too difficult to achieve, but you may not need that so I will stop there. I've rambled on a bit at the end but ultimately there's not a lot of setup to do if I've understood what you are trying to achieve correctly. *I have an automount script that spits out the actual configuration, but for the sake of argument I'm going to pretend its a static map for the users. Sean ________________________________________ From: Lars Behrens [[email protected]] Sent: 22 July 2016 10:26 To: Sean Brisbane; [email protected] Subject: Re: pam_mount Am 22.07.2016 um 10:21 schrieb Sean Brisbane: > I have a working set up to do what you describe without pam_mount, > though I will point out that a direct replacement for pam_mount could > be pam_script wlinked to a script which calls mount.cifs with the > required options on log in. The approach should be fine for > single-user systems I think. Hehe, one more option. But we have multiuser here. > There are almost enough pointers in this thread already I think to do > it a different way, using some form of auto-mounter (I use yet > another automounter, autofs5), in a way that works for multi user > systems, or if there is a large or dynamic list of cifs shares to > mount. > > I think theres one comment missing about how to deal with the fact > that its the root user who needs to mount the share but is probably > not the user accessing it. This causes issues for samba in a way that > it doesn't for NFS. > > Autofs runs as root and mount.cifs has a number of protections built > in to prevent non-root users using it. Unlike with NFS, the ordinary > behavior with cifs is to treat the share so that all operations on > that share are as the user who mounted it. I just accepted this and > mounted the share using roots kerberos's ticket or keytab; if the > system has machine credentials already then you have credentials for > root. You can then change the behavior of the cifs mount to > 'multiuser', so that the user accessing the share's kerberos ticket > is used rather than the user 's ticket who mounted the share. Not sure what you mean by "machine credentials". They are not in AD if you mean that. And I am not root in the AD. > I can go into more detail about any part of my set up if you would > like. How could I reject that? Just to give an idea about our currrent setup: ATM one of our mounts looks like that in /etc/security/pam_mount.conf.xml: <volume mountpoint="$XXX/%(DOMAIN_USER)" user="*" server="$YYY"\ options="user=%(DOMAIN_USER),uid=%(USERUID),\ domain=$DOMAIN,$OTHER_OPTIONS"path="$ZZZ" fstype="cifs"/> and in /etc/pam.d/[lightdm,login,sshd,xdm] auth optional pam_mount.so session optional pam_mount.so > > Thanks, Sean ________________________________________ From: > [email protected] > [[email protected]] on behalf of Lars > Behrens [[email protected]] Sent: 22 July 2016 08:45 To: > [email protected] Subject: Re: pam_mount > > Am 22.07.2016 um 01:11 schrieb David Sommerseth: > >> Have a look at authconfig and sssd. The former should help >> configure all these things for you, including proper PAM setup as >> well as LDAP and Kerberos. For SSSD it is in particular helpful on >> laptops, where authentication data can be cached locally to be >> capable of offline authentication as well as caching enough >> information to automatically fetch a Kerberos ticket once the >> network access has been established. > > I already had been using authconfig for sssd setup. Authentication > (via AD/ldap) and caching works well. I only need per user mounting > of their AD-directories and hadn't found a hint in the authconfig man > page. > >> And SSSD do have some support for handling the autofs/automount >> stuff too. > > Ok, that seems the way to go. Through your tip I now found that there > is an autofs/automount via "ldap_autofs_*" in sssd. Let's see if I > get this set up. > >> Otherwise, do have a look at the FreeIPA stuff too. There's a lot >> of good things in that package, which also doesn't require much >> resources on the server side. For clients, it gets even easier. >> You just need to install the proper IPA packages and run >> ipa-server-install or ipa-client-install, that's mostly all you >> need. FreeIPA also makes use of SSSD and authconfig under the >> hood. > > Yeah, looks like good thing but afaics I would have to set up a > server for that. I think at first I have to get comfy with the basics > in the "red hatted" world (I am coming from a debianic and SUSE > background). > > Thank you for your hints! > > Cheerz, Lars > -- Karlsruher Institut für Technologie (KIT) Physikalisches Institut +49 721 608-43448 [email protected]
