Kerberized CIFS client?
Atte Peltomäki
oranki at gmail.com
Fri Jun 13 11:09:03 UTC 2008
I don't think I can be of much further help, since smbnetfs and fuse
are unfamiliar to me (except at concept level).
Anyway, here's a few more shots in the dark:
- Make sure DNS reverse records are correct
- Whatever runs the fs share needs to have access to the local /etc/krb5.keytab
Debugging Kerberos can be a real PITA, as the MIT libs don't show too relevant
info about failures, but instead mask failures behind more generic
errors. I've tried
stabbing the source a bit to circumvent this, but it's not such an
easy task and
would only be useful for debugging anyway, since revealing too much information
about a failed authentication can easily lead to security issues.
-Atte
On 6/12/08, Derek Taylor <det135 at psu.edu> wrote:
> On Sun, 08 Jun 2008, Atte Peltomki wrote:
>>smbclient (and other samba utilities) do not refer to krb5.conf when
>>figuring out the kerberos realm.
>>
>>you will have to put to your krb5.conf on both client and server:
>>
>>[domain_realms]
>> cifs.example.com = realm.example.com
>
> I've done this step, but there seems to be no difference. When I did a
> tcpdump and viewed the results in wireshark there was no attempt to do
> anything kerberos related, the first thing related to auth mentioned was
> NTLM.
>
> I don't see anything with lsknobs or make config. Am I missing
> something?
>
> -Derek.
>
>>Otherwise it will just try to use example.com as the realm.
>>
>>On 6/6/08, Derek Taylor <det135 at psu.edu> wrote:
>>> On Tue, 03 Jun 2008, Atte Peltomki wrote:
>>>>You will have to adjust your krb5.conf to map a given domain or hostname
>>>>to a kerberos realm, if you are doing cross-realm authentication. See MIT
>>>>kerberos admin guide for details.
>>>
>>> I'm pretty sure it's set up ok. I can use smbclient -k just fine:
>>> $ kinit
>>> det135 at realm.example.com's Password:
>>> kinit: NOTICE: ticket renewable lifetime is 1 week
>>> $ klist
>>> Credentials cache: FILE:/tmp/krb5cc_1001
>>> Principal: det135 at realm.example.com
>>>
>>> Issued Expires Principal
>>> Jun 6 15:08:47 Jun 7 01:08:47
>>> krbtgt/realm.example.com at realm.example.com
>>> $ smbclient -k -U det135 //cifs.example.com/dir1
>>> OS=[Unix] Server=[Samba 3.0.30]
>>> smb: \> ls
>>> . D 0 Thu Feb 14 14:46:42
>>> 2008
>>> .. D 0 Fri Jun 6 10:16:29
>>> 2008
>>> [ other files/directories here ]
>>>
>>> smb: \> quit
>>> $ cd ~/mount/smbbeta.pass.psu.edu/pass
>>> $ ls
>>> ls: .: Permission denied
>>> $ klist
>>> Credentials cache: FILE:/tmp/krb5cc_1001
>>> Principal: det135 at dce.psu.edu
>>>
>>> Issued Expires Principal
>>> Jun 6 15:08:47 Jun 7 01:08:47
>>> krbtgt/realm.example.com at realm.example.com
>>> Jun 6 15:09:17 Jun 7 01:08:47 cifs/cifs.example.com at realm.example.com
>>> $
>>>
>>> -Derek.
>>>
>>>>On 6/3/08, Derek Taylor <det135 at psu.edu> wrote:
>>>>> On Tue, 03 Jun 2008, Harti Brandt wrote:
>>>>>>On Tue, 3 Jun 2008, Derek Taylor wrote:
>>>>>>
>>>>>>DT>On Thu, 22 May 2008, Hartmut Brandt wrote:
>>>>>>DT>>Derek Taylor wrote:
>>>>>>DT>>> This question was previously posed of the freebsd-questions list,
>>>>>> but
>>>>>>DT>>> with no response for a week, I'd like to try my luck here. If
>>>>>> there's
>>>>>>DT>>> any more information I should include, please speak up: I would
>>>>>> be
>>>>>> glad
>>>>>>DT>>> to oblige.
>>>>>>DT>>>
>>>>>>DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs
>>>>>> doesn't
>>>>>>DT>>> seem to support this.
>>>>>>DT>>>
>>>>>>DT>>> Is anyone aware of an alternate means of performing a mount via
>>>>>> smb/cifs
>>>>>>DT>>> or any patches to provide such functionality?
>>>>>>DT>>>
>>>>>>DT>>> I already have smbclient working with -k, but I am also
>>>>>> interested
>>>>>> in
>>>>>> a
>>>>>>DT>>> mount.
>>>>>>DT>>
>>>>>>DT>>Try smbnetfs from ports. It's fuse based and seems to work very
>>>>>> nice.
>>>>>> If
>>>>>>DT>>you have a large amount of shares floating in your network you want
>>>>>> to
>>>>>>DT>>restrict it to mount only the needed shares via the config file.
>>>>>>DT>>Otherwise it will mount what it can find...
>>>>>>DT>>
>>>>>>DT>>It plays nicely with kerberors. When your ticket expires you
>>>>>> immediately
>>>>>>DT>>loose access; when you renew it you gain access again. All without
>>>>>> the
>>>>>>DT>>need to unmount/mount. Just call smbnetfs once you have your
>>>>>> ticket.
>>>>>> You
>>>>>>DT>>may even do this from your .profile.
>>>>>>DT>>
>>>>>>DT>>harti
>>>>>>DT>
>>>>>>DT>Sorry for not replying sooner.
>>>>>>DT>
>>>>>>DT>Initial tests here are promising (I can see some mount paths being
>>>>>>DT>exported from the server), but it's not fully working (I don't see
>>>>>> all
>>>>>>DT>of the mount paths that *should* be exported and I get permission
>>>>>> denied
>>>>>>DT>errors). My thoughts are leaning towards an issue in negotiating
>>>>>> auth
>>>>>>DT>with the server -- perhaps my krb creds aren't being used?
>>>>>>
>>>>>>You can test this easily: if your ticket expires you get permission
>>>>>> denied
>>>>>>errors when you try to look into the mounted directories. As soon as
>>>>>> you
>>>>>>renew the ticket you get access again. All without restarting smbnetfs.
>>>>>>
>>>>>>harti
>>>>>
>>>>> I replaced all server names below with "example.com" (and derivatives)
>>>>> where appropriate:
>>>>>
>>>>> From my FreeBSD machine, using smbnetfs:
>>>>>
>>>>> $ klist
>>>>> klist: No ticket file: /tmp/krb5cc_1001
>>>>> $ kinit det135
>>>>> det135 at realm.example.com's Password:
>>>>> kinit: NOTICE: ticket renewable lifetime is 1 week
>>>>> $ klist
>>>>> Credentials cache: FILE:/tmp/krb5cc_1001
>>>>> Principal: det135 at realm.example.com
>>>>>
>>>>> Issued Expires Principal
>>>>> Jun 3 11:51:20 Jun 3 21:51:04
>>>>> krbtgt/realm.example.com at realm.example.com
>>>>> $ cd ~/mount/cifs.example.com/dir1
>>>>> $ ls
>>>>> ls: .: Permission denied
>>>>> $ cd ..
>>>>> $ ls
>>>>> dir1 dir2
>>>>> $ klist
>>>>> Credentials cache: FILE:/tmp/krb5cc_1001
>>>>> Principal: det135 at realm.example.com
>>>>>
>>>>> Issued Expires Principal
>>>>> Jun 3 11:51:20 Jun 3 21:51:04
>>>>> krbtgt/realm.example.com at realm.example.com
>>>>>
>>>>>
>>>>> From my Mac, using (from Finder)
>>>>> Go -> Connect to Server -> cifs://cifs.example.com/dir1
>>>>>
>>>>> $ klist
>>>>> klist: No Kerberos 5 tickets in credentials cache
>>>>> $ kinit det135
>>>>> Please enter the password for det135 at realm.example.com:
>>>>> $ klist
>>>>> Kerberos 5 ticket cache: 'API:Initial default ccache'
>>>>> Default principal: det135 at realm.example.com
>>>>>
>>>>> Valid Starting Expires Service Principal
>>>>> 06/03/08 11:59:41 06/03/08 21:59:41
>>>>> krbtgt/realm.example.com at realm.example.com
>>>>> renew until 06/10/08 11:59:41
>>>>>
>>>>> #### Here I mount via Finder before continuing with the commands below
>>>>>
>>>>> $ cd /Volumes/dir1/
>>>>> $ ls
>>>>> subdir1 subdir2 file1 file2
>>>>> $ klist
>>>>> Kerberos 5 ticket cache: 'API:Initial default ccache'
>>>>> Default principal: det135 at realm.example.com
>>>>>
>>>>> Valid Starting Expires Service Principal
>>>>> 06/03/08 11:59:41 06/03/08 21:59:41
>>>>> krbtgt/realm.example.com at realm.example.com
>>>>> renew until 06/10/08 11:59:41
>>>>> 06/03/08 12:00:31 06/03/08 21:59:41
>>>>> cifs/cifs.example.com at realm.example.com
>>>>> renew until 06/10/08 11:59:41
>>>>>
>>>>>
>>>>> It looks like my creds aren't being used on the FreeBSD machine.
>>>>>
>>>>> -Derek.
>>>>> _______________________________________________
>>>>> freebsd-hackers at freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>>> To unsubscribe, send any mail to
>>>>> "freebsd-hackers-unsubscribe at freebsd.org"
>>>>>
>>>>
>>> _______________________________________________
>>> freebsd-hackers at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to
>>> "freebsd-hackers-unsubscribe at freebsd.org"
>>>
>>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
More information about the freebsd-hackers
mailing list