Automounting Windows Share using user's kerberos ticket

0ddba11 · 08-26-2009, 05:34 AM

The goal is to create separate (auto)mounts on Red Hat Enterprise 5.3 machine to shares on various Windows 2003 file servers (64 bit) on a per user basis (just like drive mappings on XP clients) for example:

/home/bob/winmounts/projects
/home/bob/winmounts/data
/home/bob/winmounts/shared

This will eliminate the need to use NFS file sharing on the Windows servers (which seems to be fraught with permission mapping issues).

Steps taken so far:
I have configured our Red Hat Enterprise 5.3 machines to use Winbind authentication and they are all a member of AD so that users can log in to them using their AD credentials, which is all working nicely.

It should now be possible is to mount the Windows shares using the kerberos ticket already obtained during login.

So I have done:

Code:

chmod +s /sbin/*.cifs

to allow the users to actually run the mount.cifs and umount.cifs programs (probably not required for autumouting, but usefull for testing mounts manually).

Added:

Code:

/home /etc/auto.cifs --timeout=5

to /etc/auto.master

Created /etc/auto.cifs with the following two lines:

Code:

#!/bin/bash
echo "-fstype=cifs,sec=krb5,user=$1 ://our-file-server/our-home-share/$1"

Added the following two lines to /etc/request-key.conf:

Code:

create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k

A quick test by trying to cd into /home/bob reveals mount error 126 (which is required key not available) in /var/log/messages.

Stopping autofs and trying to mount manually using:

Code:

/sbin/mount.cifs //our-file-server/our-home-share/bob /home/bob -o sec=krb5

Does indeed give the same response: "mount error 126 = Required key not available"

But a quick 'klist' shows that I do have a valid ticket.

HOWEVER....

If I log in as root, and get my kerberos ticket using 'kinit bob' and then try it, everything works (both manually and for autofs.

I suspect this is something to do with the fact that autofs runs as root, and the setuid on mount.cifs means it also runs as root, where there is indeed no valid kerberos ticket.

I'm obviously missing something here, surely automounting cifs shares should be possible?

Are there any options I can pass to cifs.upcall that will tell it to use MY cached kerberos credentials?

klwilson78 · 09-04-2009, 05:45 PM

I'm having the same problem. Has anyone found a solution?

ralish · 09-18-2009, 03:11 AM

I'm having the exact same problem as detailed by 0ddba11.

Can we get any advice on how to troubleshoot this problem?

ralish · 09-18-2009, 07:36 AM

0ddba11: Are you pulling user and group IDs from LDAP (or possibly some other remote service)? I'm guessing you are through Samba + Winbind.

After some serious troubleshooting some limited progress has been made on establishing the cause. With the help of a more knowledgeable person than me on Linux systems, we've discovered that when calling mount.cifs from a user account, uid and gid parameters matching the user uid/gid are appended transparently to the command sent to the cifs kernel module. However, if you explicitly set the uid/gid to the root uid/gid, the mount will work flawlessly using the cached kerberos credentials for the user.

My hypothesis is that the kernel isn't correctly handling IDs pulled from LDAP, only working with IDs that are local to the machine (explicitly defined in group/passwd?). It would appear as long as you override the appended uid/gid combination with ones local to the box, it will work fine. I note that when mounting from root, uid/gid parameters are NOT transparently added to the kernel command being passed to cifs module, so it may be the case these are only added for users where the uid/gid can't be found locally, and the problem manifests further down the codepath.

For example, under a standard user account that is on the AD server:

Code:

/sbin/mount.cifs //whatever/whatever /home/whatever/test --verbose -o sec=krb5

The above command will fail. However:

Code:

/sbin/mount.cifs //whatever/whatever /home/whatever/test --verbose -o sec=krb5,uid=0,gid=0

Will work fine for me.

Note that verbose will show you what exactly is being sent to the cifs kernel module, allowing you to see the appended parameters.

Can anyone else confirm our findings? Better yet, can anyone shed some light on them and how to resolve this issue elegantly? Is this a kernel bug?

ralish · 09-23-2009, 11:05 AM

The problem has been resolved.

This is a known issue with the cifs.upcall program that has been fixed in the latest sources available from the git master branch on samba gitweb.

It does not appear to be fixed in any of the latest samba releases as of now and so you'll probably have to compile it yourself from the latest sources or backport it to your release of choice.

klwilson78 · 10-06-2009, 11:01 AM

Do you have a bug number for the known issue? Can you specify the version of cifs.upcall which contains the fix? I'd like to be able to determine if and when it makes it into various distributions.

ralish · 10-06-2009, 11:05 PM

I'm not aware of any particular bug filed for this issue; there may be one, but I don't know of it (though if there is one I'd be interested). However, this is the particular commit in the Samba git repository that fixes the issue. As of now it does not appear to be in any of the stable trees but only in the Master tree and I have no idea if this is likely to change in the near future.

The particular version of cifs.upcall that contains the fix is v1.3, with cifs.upcall v1.2 what is currently shipping in all of the above stable branches. Keep in mind that this doesn't *guarantee* that you have the fix, there are several commits preceding the above fix that are all part of cifs.upcall v1.3. As of now, it seems the only way to get the fix is to either pull the latest sources from Master and compile them yourself, or backport the fix to a previous version and recompile the sources yourself.

munta · 11-20-2009, 03:56 AM

Hi all. Had simillar issue on ubuntu 9.10
Installed keyutils
http://www.linuxquestions.org/questi....-krb5-770384/

ralish · 11-21-2009, 02:18 AM

Thanks for the link munta.

I checked the system that was originally affected and it already has keyutils installed however (as it should), so I think our problems are somewhat different.

acid_kewpie · 11-23-2009, 04:08 PM

not a network question. moved to Linux - Server.

0ddba11 · 12-02-2009, 04:37 AM

Hi chaps,

Sorry I've not been around for a while, been going through a massive file system migration from Netware to Windows (which is why I wanted this to work). Due to time constraints we ended up implementing 'Microsoft Server for NFS' which now seems to be causing more problems than it's solving so I'm actively looking at this as a solution once again.

I'm downloading RHEL 5.4 to see if the fixes to cifs.upcall have made it in (5.4 also supports DFS so potentially a double benefit).

It was really good to see your responses, if not only to know that I'm not alone on this

and particular thanks to ralish for finding out that the correct credentials do indeed make it through to the cifs kernel module!

More news later...

acid_kewpie · 12-02-2009, 12:26 PM

You're downloading 5.4, when you're already using 5.3? What's wrong with a yum update??

0ddba11 · 12-03-2009, 03:05 AM

Quote:

Originally Posted by acid_kewpie

You're downloading 5.4, when you're already using 5.3? What's wrong with a yum update??

Although off topic, we are actually running 4.4 across the board, the 5.3 box was a dev box to test this CIFS functionality which is no more.

Now then, I have now setup a 5.4 box exactly as per our previous 5.3 dev box (no further patches yet) and the problem still exists.

Doing:

Code:

cifs.upcall -v

reveals that it is still version 1.2 so no suprises why it doesn't work.

Now I'm off to update the box to and see if cifs.upcall gets updated.

0ddba11 · 12-03-2009, 05:19 AM

Quote:

Originally Posted by ralish

I'm not aware of any particular bug filed for this issue

https://bugzilla.redhat.com/show_bug.cgi?id=517195

0ddba11 · 12-03-2009, 06:35 AM

Now I need some help...

I did the following:

Downloaded samba-3.0.33-3.15.el5_4.src.rpm

Downloaded samba-3.0.33-cifs.upcall-update.patch from https://bugzilla.redhat.com/show_bug.cgi?id=517195

Built new RPMS's

Freshened my RPM's with the ones I built

Doing:

Code:

cifs.upcall -v

now shows it to be version 1.3, but I STILL get the 'Required key not available' error.