[linux-cifs-client] mount.cifs w/ sec=krb5i still non-op when DC != Fileserver

[Harald Milz]

Hi all,

in the meantime I did some more testing, and the wrapup can be read on
https://bugzilla.redhat.com/show_bug.cgi?id=574750. In any case, I will try to
make sure cifs-utils 4.0 gets tested in this environment.

In a nutshell, mounting with 

mount.cifs //Server/share /mnt/point -o sec=krb5i

(with mount.cifs = suid root and /etc/request-key.conf set up as per the
cifs.upcall man page)

as a normal user results in this pathological error 126 "required key not
available", and adding "uid=0" makes it work but then all files belong to
root. What appears to happen is that in the case of "uid=0", cifs.upcall
retrieves root's TGT which happens to belong to a domain admin (we join the
domain because we need winbind for uid/gid mapping of domain users) who has
all the rights, while without "uid=0", cifs.upcall uses the invoking user's
TGT. If we give this invoking user domain admin rights in AD, it still gives
us error 126, so it appears not related to AD permissions (and mind you, with
"smbclient -k" or logged into a Vista machine, the very same user can access
his shares just fine). Apparently, cifs.upcall fails in handle_krb5_mech(),
cifs_krb5_get_req(). 

(the cifs.upcall we use is the one in the RHEL 5.5 samba-client-3.3.8-0.50
package and should be the fixed version wrt the KRB5CCNAME bug). 

We traced the network connection and noticed that when using mount.cifs sans
uid=0, no krb5 request is even received on the AD controller. So apparently,
cifs_krb5_get_req() fails when the key description uid= is not 0:

cifs.spnego;0;10513;3f000000;ver=0x2;host=FS0Z0LLQ;ip4=10.63.84.228;sec=mskrb5;uid=0x1f4;user=user04

The full transcript including the cifsFYI and cifs.upcall logs can be found on
the above mentioned bugzilla page. 

One thing that I came across is the behaviour of mount.cifs / cifs.upcall (not
sure which) concerning the uid= option, which I think is wrong.  Methinks the
option should only be used to explicitly set the ownership of the mounted
share as documented in the mount.cifs man page, and not interfere with getting
a service ticket.   

Please do not hesitate to contact me if you need more info. 


On Thu, Mar 04, 2010 at 08:25:24AM +0100, Harald Milz wrote:
> On Wed, Mar 03, 2010 at 10:53:21AM -0500, Jeff Layton wrote:
> > On Wed, 3 Mar 2010 15:13:27 +0100 Harald Milz <hm at seneca.muc.de> wrote:
> > > http://lists.samba.org/archive/linux-cifs-client/2009-October/005391.html
> > > (Required key not available). 
> 
> > As far as I could tell in that email thread, the problem was that the
> > server wasn't accepting service principals for all of its possible
> > hostnames. What exactly are you proposing that we fix on the client
> > side?
> 
> In our case we just need to make sure that the DC's TGT is accepted by the
> fileserver, respectively we get a proper cifs/ principal. In case of
> "smbclient -k" this works right (albeit this is not a cifs connection AFAIK),
> just not in the case "mount -t cifs". What needs to be done technically I
> can't tell. 
> 
> -- 
> When the weight of the paperwork equals the weight of the plane, the
> plane will fly.
> 		-- Donald Douglas

-- 
Any fool can paint a picture, but it takes a wise person to be able to
sell it.