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 /etc/pam.d/
auth optional pam_mount.so
session optional pam_mount.so
>
> Thanks, Sean ________________________________________ From:
> [log in to unmask]
> [[log in to unmask]] on behalf of Lars
> Behrens [[log in to unmask]] Sent: 22 July 2016 08:45 To:
> [log in to unmask] 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
[log in to unmask]
|
