LinuxQuestions.org - Automounting Windows Share using user's kerberos ticket

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - Automounting Windows Share using user's kerberos ticket (https://www.linuxquestions.org/questions/linux-server-73/automounting-windows-share-using-users-kerberos-ticket-750347/)

0ddba11:
Despite being something you'd think would be relatively simple, there's a huge amount of complexity behind the scenes getting all this to work, so without more information, there's only so much I can suggest.

Check the patch on the Red Hat bug report with the absolute latest cifs.upcall source from the master branch from samba git. The guy assigned that bug report is also a samba developer and the maintainer of the cifs.upcall source, and I know he made multiple commits addressing this problem, so it's possible that patch is not the latest in the samba master.
You might consider logging in as root (or another local user) and removing all kerberos tickets from /tmp so that all the tickets are recreated as each user in kerberos logs on again. This may help to eliminate any potential permissions issues, as if the tickets aren't accessible for the user trying to authenticate to the share, then the mount is obviously going to fail as the kerberos client can't read the ticket.
Try using -v judiciously to determine exactly what is being passed to the kernel from mount.cifs (see previous posts). Try the uid/gid parameters to determine if it is a likely kerberos/permissions issue, or something else. You might need to resort to strace to try and trace exactly what is going on as the mount call proceeds (and eventually fails).

These are all kind of generic, but they should point you in the right direction, and perhaps help to obtain some more useful debugging data.

Here's an update.

Two things have ocurred recently....

Number One
If you check this bug at https://bugzilla.redhat.com/show_bug.cgi?id=517195 you'll note that it now says 'Fixed In Version: samba-3.0.33-3.23.el5 '.

This is great news.

However...

Number Two
I have now implemented a different (and I think more appropriate solution) using the pam_mount module.

I'd never seen this pam module before, and when I read what it does I couldn't believe my eyes - it mounts volumes when a user starts a session and unmounts them when their session ends!

Perfect.

Whilst an RPM wasn't available for Red Hat 4 I found some extra packages for Cent OS 4 here: http://centos.karan.org/el4/extras/stable/ which install and run just fine on RHEL4. (remember to get both the 32 bit and 64 bit RPMS if you're running a 64 bit system as some 32 bit apps like Exceed onDemand need the 32 bit pam_mount.so)

For those who are interested, here is my /etc/security/pam_mount.conf:

Code:

debug 0

mkmountpoint 1



fsckloop /dev/loop7



options_allow  nosuid,nodev,loop,encryption

options_require nosuid,nodev



lsof /usr/sbin/lsof %(MNTPT)

fsck /sbin/fsck -p %(FSCKTARGET)

losetup /sbin/losetup -p0 "%(before=\"-e \" CIPHER)" "%(before=\"-k \" KEYBITS)" %(FSCKLOOP) %(VOLUME)

unlosetup /sbin/losetup -d %(FSCKLOOP)

cifsmount /bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER)%(before=\",\" OPTIONS)"

smbmount /bin/mount -t smbfs //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER)%(before=\",\" OPTIONS)"

ncpmount /bin/mount -t ncpfs %(SERVER)/%(USER) %(MNTPT) -o "pass-fd=0,volume=%(VOLUME)%(before=\",\" OPTIONS)"

umount  /bin/umount %(MNTPT)

lclmount /bin/mount -p0 %(VOLUME) %(MNTPT) "%(before=\"-o \" OPTIONS)"

cryptmount /bin/mount -t crypt "%(before=\"-o \" OPTIONS)" %(VOLUME) %(MNTPT)

nfsmount /bin/mount %(SERVER):%(VOLUME) "%(MNTPT)%(before=\"-o \" OPTIONS)"

mntagain /bin/mount --bind %(PREVMNTPT) %(MNTPT)

mntcheck /bin/mount # For BSD's (don't have /etc/mtab)

pmvarrun /usr/sbin/pmvarrun -u %(USER) -d -o %(OPERATION)



volume * cifs server1 data /winmounts/&/data uid=&,gid=users,dirmode=0700,filemode=0700 - -

volume * cifs server2 home /winmounts/&/home uid=&,gid=users,dirmode=0700,filemode=0700 - -

The 'mkmountpoint 1' line means that the mount points get created automatically

On the 'volume' line '&' gets replaced with the current user

uid=& makes the current user the owner for all files and directories

Setting filemode and dirmode 0700 means that only the owner ends up with permission to it, which stops user B accessing a share that user A has mounted.

And to make it all work, here my /etc/pam.d/sshd:

Code:

#%PAM-1.0

auth      required    pam_stack.so service=system-auth

auth      required    pam_mount.so use_first_pass

auth      required    pam_nologin.so

account    required    pam_stack.so service=system-auth

password  required    pam_stack.so service=system-auth

session    required    pam_stack.so service=system-auth

session    required    pam_loginuid.so

session    optional    pam_mount.so

So it's not exactly what we set out to fix, but it works better.

And that's it for the year from me - I'm off to Malaga for Christmas now!!! :D

Merry Christmas everybody, and Happy New Year.

I just finished reading about pam_mount and it sounds absolutely perfect, not to mention being a more elegant solution than the autofs kludge I was going to put together. Thanks a bunch for enclosing your detailed configuration information and explanation, it should be a major time saver!

Unfortunately, while the Red Hat patch is good news, it doesn't apply to me as I'm using the unofficial SerNet Samba binaries for CentOS 5 that upgrade the Samba packages to 3.2 (as well as having RPMs for 3.3 and 3.4 available). The reason for this is the 3.2 branch is the earliest Samba branch that supports certain features I need, in particular SMB signing.

Fortunately, the relevant fix for cifs.upcall is simple and can easily be patched into the 3.2 source and compiled with the included SerNet SRPMs. Of course, this is fairly tedious and a time sink, as it really ought to be done each time the packages are upgraded (even if you can get away with not doing so). I might see if I can convince SerNet to backport the fix into their packages, otherwise, the SRPM recompiles will have to continue.

Still, the pam_mount solution sounds excellent, so thanks again for reporting back. Also, I hope you enjoy your Christmas holiday :)

There is actually another fix which works just perfectly:

Code:

/etc/auto.cifs

echo  "-fstype=cifs,sec=krb5,uid=`id -u $1`,user=$1 ://files/Users/$1"

Now the uid is equal to the uid of the user share we want to mount, which means the ticket is now being retrieved as the actual user logging in which gets rid of the error 126 in my case.

Now, when user daenney with uid 10005 logs in the following is being called:

Code:

"-fstype=cifs,sec=krb5,uid=10005,user=daenney ://files/Users/daenney"

This now mounts the homedir for user daenney using the according kerberos ticket. It's a stupid workaround but it does wonders.