Nasty 10.4.11 to 10.5.5 Server samba/kerberos fallout

[bcoldry]

Hi all,

So, I thought I really had it understood very well. I have a bunch of Sun hosts/Linux hosts kerberized against my Mac OS X 10.4.11 Open Directory master. Had all my keytabs in all the right places, all my key exchanges worked correctly, my TGT did what it should have and everything was well. My Sun systems run samba 3.0.28a (sun supported) and use the Open Directory master as the password backend.

In this configuration, things are perfect.

However…

If we then upgrade the Mac OS X 10.4.11 Server instance to 10.5.5 Server, either via the “upgrade” option or the fresh install path (assuming reimported keys/OD database et al from the “archive/restore” function in server admin), then it all goes to hell. The samba server spits the following when you attempt to connect through Finder (on a 10.5 or 10.4 or 10.3 client) to a share on said host:

[2008/10/04 17:40:59, 1, pid=2237] libsmb/cliconnect.c:(1451)
  Error connecting to 192.168.117.150 (Connection refused)
[2008/10/04 17:40:59, 0, pid=2237] auth/auth_server.c:(89)
  password server not available

Making matters even more confusing, from the Mac OS X client perspective, and why the directory upgrade has done this, is the fact that, mount_smbfs and smbclient -k work perfectly.

I’ve logged it with radar.apple.com, but I am really not sure what else to make of this. The instant I flip back to a 10.4.11 OD master, everything is perfect again.

Thoughts? Am a bit concerned Apple will probably tell me that it isn’t their product that is at fault, because a Solaris server is involved, but the fact of the matter is, everything else remains static, only the Apple Server version changes…

Thanks for your time.

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.

[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

[Author]

Posts