[bcoldry]

Indeed, and this makes it so much more confusing. As follows:

1. Bring open “connect to server” box

2. Type credentials in

3. Before hitting “connect”, in a terminal window “klist -v”:

macintosh:~ coldry$ klist -A
klist: No Kerberos 5 tickets in credentials cache

4. Hit connect, try and put credentials in. Watch it fail, then, klist -A again:

macintosh:~ coldry$ klist -A
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: coldry@OPENDIRECTORY01.MNU.EDU.DK

Valid Starting     Expires            Service Principal
10/06/08 05:42:10  10/06/08 15:42:10  krbtgt/OPENDIRECTORY01.MNU.EDU.DK@OPENDIRECTORY01.MNU.EDU.DK
	renew until 10/13/08 05:42:10
10/06/08 05:42:11  10/06/08 15:42:10  cifs/fileserver-public.mnu.edu.dk@OPENDIRECTORY01.MNU.EDU.DK
	renew until 10/13/08 05:42:10

So, in reality, I am being granted the ticket, and that part of the transaction goes to completion, but then all I get is sadness from Finder. For clarity, the exact error message is “Sorry, you have entered an incorrect username or password, please try again”.

If I do the same thing with mount_smbfs (which, from a little bit of Dtrace, shows me that it uses some of the same libraries as Finder connect, at least!)

macintosh:Desktop coldry$ mount_smbfs //coldry@home.mnu.edu.dk/group_it ~coldry/Desktop/testmount
Password:
mount_smbfs: server rejected the connection: Authentication error

But then, expecting that it can’t automatically generate krb by itself, if I:

kinit -V coldry

…perfect:

macintosh:Desktop coldry$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s2 149Gi 109Gi 40Gi 74% /
devfs 117Ki 117Ki 0Bi 100% /dev
fdesc 1.0Ki 1.0Ki 0Bi 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% /net
map auto_home 0Bi 0Bi 0Bi 100% /home
map -fstab 0Bi 0Bi 0Bi 100% /Network/Servers
//coldry@home.mnu.edu.dk/group_it 1.6Ti 1.4Ti 203Gi 88% /Users/coldry/Desktop/testmount

So, near as I understand it, it is behaving correctly, albeit, differently to Tiger Server (in Tiger Server, I didn’t have to kinit before trying mount_smbfs, it just handed the ticket out at this point and passes through).

Now that I have a share mounted, using mount_smbfs, I can then use Finder as I normally would, and it allows me to mount shares perfectly, but only once I’ve initiated some kind of interchange with mount_smbfs.

I then had the bright idea of unmounting everything, then killing all tickets (kdestroy -A). I thought that if I could kinit -V THEN try Finder, it might work, but no. If I have mounted through mount_smbfs, subsequent finder driven mount requests work from the server in question, but if I try first with finder, with a ticket or not, no love.

Man, this is really confusing :(.

Thanks for hearing me on this one Joel. I really don’t know who else will have any idea, from here on in!

BC

[bcoldry]

MacTroll wrote:

Single Kerberos realm?

Using the FQDN in the Finder when making the connection?

Thanks for the speedy reply.

1. Indeed, no cross-realm stuff happening here

2. Yup, like so, from “Connect to server” dialog:

smb://home.mnu.edu.dk

I also tried other things, like specifying the IP, to see if it may have been DNS related, then tried things like:

smb://userName@FQDN.OF.SERVER.HERE/shareHere

and

smb://DOMAIN.HERE;then.FQDN.OF.SERVER.HERE/shareHere

…to no avail.

Thanks.

[Author]

Posts