The Samba-Bugzilla – Bug 5655
Mac OS X 10.5.4 clients fail to authenticate with Kerberos credentials
Last modified: 2008-08-08 10:55:45 UTC
Our infrastructure is set up in a cross realm auth configuration. Clients authenticate and get tickets from one realm, but all our services are deployed in a separate realm. Both realms trust each other.
A user is able to kinit on the Mac OS client to get their ticket, and is then able to connect to Samba running on the Solaris server without entering a further password on the command line using smbclient -k. However, attempts to connect to the Samba server from within Finder fail. The only indication of what went wrong is the the samba logs:
[2008/07/31 16:41:18, 1, pid=25018] libsmb/clispnego.c:(265)
Failed to parse negTokenTarg at offset 54
Has anyone experienced this before? Is it a configuration problem or a code issue?
I know this is a very vague description of the problem, but I am willing to provide more information upon request.
Please take a wireshark trace, and post a debug level 10 from the samba server in question. Thanks !
(In reply to comment #1)
> Please take a wireshark trace, and post a debug level 10 from the samba server
> in question. Thanks !
Here's some I prepared earlier: http://www.itee.uq.edu.au/~dlg/support/
These are the packet captures themselves and the wireshark output as text files.
I'll have some level 10 debug output for you shortly.
> I'll have some level 10 debug output for you shortly.
the log output is available at http://www.itee.uq.edu.au/~dlg/support/log_level_10
Sorry, the interesting part is not in the log file, you're creating user-specific log files. Can you remove the "log file =" part of your smb.conf and retry?
(In reply to comment #4)
> Sorry, the interesting part is not in the log file, you're creating
> user-specific log files. Can you remove the "log file =" part of your smb.conf
> and retry?
http://www.itee.uq.edu.au/~dlg/support/samba.log is now available. I hope it contains the information you need.
Not a Samba bug. The log file only contains an anonymous session setup, not a kerberos one. Please talk to your apple support to figure out how to make OS/X send Kerberos tickets.
(In reply to comment #6)
> Not a Samba bug. The log file only contains an anonymous session setup, not a
> kerberos one. Please talk to your apple support to figure out how to make OS/X
> send Kerberos tickets.
But it is. Mac OS X is attempting to use a Kerberos ticket for authentication. Please refer to the finder packet dump and finder.txt wireshark output, particularly frame 8.
In the meantime I'll try to figure out what I'm doing wrong with the collection of the samba logs.
Sorry, but as long as we don't get smbd log files that actually show a failed kerberos login, there is no way we can deal with it. The smbd log file you uploaded did not show any kerberos packet.
(In reply to comment #8)
> Sorry, but as long as we don't get smbd log files that actually show a failed
> kerberos login, there is no way we can deal with it. The smbd log file you
> uploaded did not show any kerberos packet.
I've generated a log file which seems to show the information you're after. This covers the daemon startup followed by two connection attempts. The one at 11:43 is from the Mac OS X client using smbclient -k which does work. The second at 11:44 is a connection attempt from Finder which fails.
Oops, I forgot to say that the log file is available at http://www.itee.uq.edu.au/~dlg/support/log.smbd.
Is there any additional information I can provide that will help you guys look into this issue?
This seems fixed in 3.2. You might want to take a look at http://article.gmane.org/gmane.network.samba.general/100386
(In reply to comment #12)
> This seems fixed in 3.2. You might want to take a look at
Ah, thank you, moving to samba 3.2 does solve this particular issue for me.
Is there any chance that this fix will be backported to the 3.0 series? I had a look at it, but the code is different enough between 3.0 and 3.2 that it is non trivial for someone who isn't familiar with the code to do.
I am hesitant to move forward to 3.2 due to the new license, and I will have to port a couple of fixes I've made to the ADS support on Solaris to the new version too.
It is unlikely we will back-port this to 3.0.x, unless Apple specifically does this. What is the problem with GPLv3 for you ? Don't want to turn this bug into a licensing discussion, so maybe you could reply on firstname.lastname@example.org.