I have a setup where the user and the Samba server are on different Kerberos realms (and accordingly, different DNS domains). Both realms use MIT Kerberos, and SERVER-REALM is set up to trust tickets from USER-REALM. `smbclient -kU username //server/share` can connect just fine, obtaining tickets for "krbtgt/SERVER-REALM@USER-REALM" and "cifs/server@SERVER-REALM". However, when using `mount.cifs` it requests a ticket for "cifs/server@USER-REALM" directly, which doesn't work in this case. The following is sent to syslog: > cifs.upcall: handle_krb5_mech: getting service ticket for cifs/server.example.com > cifs.upcall: cifs_krb5_get_req: unable to get credentials for cifs/server.example.com > cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328377) > cifs.upcall: handle_krb5_mech: getting service ticket for host/server.example.com > cifs.upcall: cifs_krb5_get_req: unable to get credentials for host/server.example.com > cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328377) (USER-REALM uses krb5 1.8.1, SERVER-REALM unknown.)
Hi, We here at the University of Cambridge (UK) have been hit by the same bug. The bug is in cifs.upcall utility. We are using our own Linux distro based on openSUSE 11.4 but I also tried cifs utils 5.0 compiled from source and both fail in the same way. The reason for the failure is that cifs.upcall specifies the principal as cifs/hostname from mount command which is not qualified thus Kerberos adds the default realm to qualify the unqualified principal which in our case as in the original reporter's case results in the incorrect realm being used (we have two realms - one for users and one for computers is a broad simplification). What cifs.upcall should be doing is to query Kerberos for the realm that matches the unqalified cifs/hostname and then qualify the unqalified cifs/hostname with that returned realm and then use that as the principal. Authentication then works fine. Actually not quite, at least in openSUSE 11.4 I also had to change /etc/request-key.conf to add the "-l" option to cifs.upcall otherwise when roots tries to mount volumes on behalf of users either by hand, script, or via the automounter it fails because the creduid is used which is then root/0 rather than the user's uid. The -l option fixes this for us in combination with uid and gid mount options (which also activate the force_uid and force_gid options). Anyway, I am going to attach the patch that makes things work for us. It would be great if it (in this form or feel free to do it differently) could be applied! Best regards, Anton
Created attachment 6925 [details] Patch implementing multi realm support to cifs.upcall As mentioned in my comment, here is the patch implementing multi realm support for cifs.upcall. Without this patch cifs.upcall always causes Kerberos to use the default realm instead of the actual realm the server is in and if the default realm is not the same as the realm the server is in authentication fails as no matching Kerberos credential can be obtained. Best regards, Anton
Forgot to say the patch is against cifs-utils 5.0 source code...
Sorry for the long delay on this. This got assigned to Steve instead of me. I'm working on fixing that in the near future. In any case... I did just commit a fix to cifs-utils that should make it behave better in multi-realm environments. It's considerably simpler than your patch since it just makes it use krb5_sname_to_principal, but I think it will make it do the right thing here too. Would you be able to test the latest cifs.upcall in git and let me know if it fixes this issue too? I'll probably cut a 5.4 release here in the near future at which point this patch will make its way into distros too.
Works with latest Git master.
Thanks for testing it!