Upgrading to Tiger broke one quizzical thing: I couldn't Samba mount the server our library website lives on. I could mount my staff account on another almost identical Solaris server, but not the library server. Extensive research led me down a blind alley thinking that the library server's authentication was being maintained by a W2K3 server using a proprietary SMB digital signing, but when the sysadmin told me this server does its own authentication, this got puzzling.
I even hunted down the BSD command that OS X uses behind the Apple-K Connect To Server GUI, mount_smbfs, and attempted to tweak every parameter possible in the Terminal. No go.
Hopefully you're here because of a Google search for "Error -36" or something like that. Here's the link to Apple's solution. In a nutshell, passwords can be sent to a server either as plaintext (which other computers on your LAN can packetsniff) or encrypted. Most Samba servers at this point are configured to handle either; the library server (for tech reasons I can't disclose) has to use plaintext.
Prior to Tiger, OS X's Samba authentication was equipped to deal with either kind; because it posed a security hazard, Tiger disables plaintext (unless you follow their instructions and restart your Mac). Apple's helpful response is that we should all force our sysadmins to go with encrypted only. Good luck on that one.
If you're not using Tiger, this won't be an issue. If you're using Tiger and your Samba server accepts encrypted passwords, this won't be an issue. But legacy servers (or servers with a specific reason for using plaintext) will require you to do the tweak mentioned before.
I have no idea whether the code behind this change is open source enough that it could be rewritten so that each entry in the Connect to Server dialog could have a checkmark next to it for encryption and let the software make the connections case by case.
Subscribe to:
Post Comments (Atom)
Posts
1 comment:
Post a Comment