Microsoft Windows Server has a some vaguely-worded options which must be disabled to allow OS X's Samba to connect. I never did fix the "name or password is incorrect" error connecting via Samba to my Windows 2000 Server install, so I always passed data back and forth using an XP machine. Seeking to end that kluge with my new Windows 2003 Server install, I hacked everything I could find on the OS X side to no avail. I finally gave up and turned to the Domain Server for salvation. Eventually, I found the right settings:

Start -> All Programs -> Administrative Tools -> Domain Controller Security Policy. You can ignore any errors about truncated strings ... gotta love one-button alerts. Then navigate into Local Policies: Security Options, and set the following:

I suppose these same policies are found in a similar location in Windows 2000 Server, but I'm not going to reinistall it just to know. Why all of this was so hard to find and/or figure out, I don't know -- it seems pretty simple once I collected it all from about 10 different places.

Warning: This hint lowers your network's security a bit, use at your own risk.

[robg adds: I can't test this one, nor can I vouch for the impact it has on security. If anyone has any comments one way or the other, please add them. And yes, I know it's not really an OS X hint, but it's a hint to help OS X machines in a Windows-server world...]

I don't have a Win2k Domain Controller but the following is true on a member server and Win2k Pro. Setting digital signatures to "always" is only really possible when you have a 100% Win2k or newer Active Directory domain.

While you're there, test the different configuration options for "LAN Manager Authentication Level." Ideally you set it to "Send NTLMv2 response only\refuse LM & NTLM." There should be no reason to set it lower than "Send NTLM response only." Even Win98 can use NTLM and it can use NTLMv2 if the ADclient software is installed. I haven't tested the version of Samba installed in OS X to see if it supports NTLMv2.

"LM" is short for LanManager and if your traffic is sniffed the password can be cracked like a walnut. "NTLM" is better but still flawed. NTLMv2 is *a lot* better, I think if you can stick to NTLMv2 you don't have to worry about network sniffing.

A W2K server does not do this by default. W2K3 server expects to be used in a 'native environment' and thus acts this way per default.
I think the implications of this 'hint' are to be overlooked, since a mailicious machine must be a Samba client of some sort or a Windows client bound to Active Directory and have access to a known AD user's login and password, or at least know the ip-address of your AD servers and have access to a known AD user's login and password in order to do much.
Of course you will need to secure your subnet by turning off outside connections to your servers via ftp, telnet and smb.
This all said, this is still a corner stone in getting Single Sign-On, SSO, working for Mac OS X and Windows clients alike with your W2K3 Active Directory. -At least when integrating Open Directory services with AD servers through the LDAPv3 plugin. I do not know if this is actually the case with the AD plugin but expect it to be.
And yes: client ntlmv2 auth = yes works!!
For more information on Kerberos SSO and Mac OS X with W2K3 AD

Perfectly normal behavior. Apple's SMB client doesn't do signing, and their interoperation documentation goes into this. What you are doing is dropping the security requirements for the domain such that downlevel (pre-Windows 2000 clients) can still connect. As the other poster mentioned, it does do Very Bad Things whenever the downlevel client is connecting, as the transmissions of username and password via plain NTLM are trivial to decode.

Considering this turns off some significant security stuff, has anyone tried upgrading the version of Samba that comes with OSX? Does anyone know if such an in-place upgrade has been attempted? Samba can now handle being a member of an AD, with AD kerberos tickets, SMB signing (required in 2003) and encrypted passwords. I realize most people aren't going to require these things at home, but in a corporate environment, turning off security to accomodate down-level clients is never a good idea.

---
Answering the age-old question: which is more painful, going to work or gouging your eye out with a spoon?
www.workorspoon.com

Samba in OS X 10.3 is currently version 3.0.5 which should be new enough to support all these features. However in my opinion most people can be satisfied with NTLMv2 only and don't need to figure out SMB signing (which this tip is about). I don't think Win98 or NT support SMB signing so OS X clients are not alone. My guess is use of Kerberos requires somehow joining Mac clients to the AD domain.

FYI, OS X 10.2 has Samba 2.2.3a (plus patches). I'm not certain but I think it only supports NTLM, not NTLMv2. As time goes by, it's a lot less likely that Apple will issue an update for OS X 10.2 that would break a self-installed upgrade to Samba but it's still a risk.

Having tried setting up Mac OS X clients to work with Kerberos and W2K3 AD servers and relying on password encryption and smb signing to work for the Mac OS X clients (Samba v.3.05) I am sad to say that I have had very little, if any, success client wise. On my XServe everything worked server wise: W2K and XP clients easily accessed shares on the XServe using Kerberos authentication, however, none of the samba clients could do the same 'to' the AD servers....

I have never tried actually replacing the built-in Samba 3.05 with the darwinports version, 3.0.11 and retried the magic....

I can vouch for this hint. I was faced with exactly the situation described during a client visit last October. Here are my notes from that visit:

BEGIN QUOTE
Macs were unable to mount volumes on the Windows 2003 server. Message was bad user name or password, console message: no credentials cache found krb5_cc_get_principal. Needed to disable 2 security policies in win2003 server.

Solution came from:

http://www.wlug.org.nz/MacSambaNotes

The easiest solution to this problem is to disable the default server setting of always requiring "digitally signed communication". To do this, log in to the domain controller and open the DC policy editor. Look for "Security Settings -> Local Policies -> Security Options" and change "Microsoft network server: Digitally sign communications (always)" from "Enabled" to "Disabled". Leave everything else. This means that the server will digitally sign communications if the client is capable, but won't reject a connection if your client is not.
END QUOTE

I do not know enough about Win2003 server to intelligently discuss the security implications of the procedure, except to say that my client has not experienced any issues since I made the change...

Well, followed the instructions and managed to connect from a Tiger 10.4.3 G5 to Win 2003 server via SMB. But everytime I try to copy a file to the server from the Mac I get an "out of disk space" message even though there's space available. Also, a Get Info for the shares shows them to be precisely 1GB even though they're bigger than that.

Put the Microsoft User Authentication Module on the client machines and you shouldn't need to monkey with the security options on the server. You can get it here:
http://www.microsoft.com/mac/otherproducts/otherproducts.aspx?pid=windows2000sfm

I too had the same problem and had some major battles with the PC techs who were trying to convince my client that it was the fault of the Mac guy (me) that the Mac's couldn't connect to the Windows 2003 server.
With a little research I found this on the Microsoft site:

Windows Server 2003 uses secure encryption which the version of samba in Panther (Mac Operating System) doesn't support. The server's authentication needs to be changed to allow unsigned authentication, per the following:
On the server, go to "Start" ->"Administrative Tools" -> "Domain Controller Policy" (not Domain Policy) and look for "Security Settings" -> "Local Policies" -> "Security Options" -> "Microsoft network server: Digitally sign communications (always)". It should show "Enabled" by default. Double-click on it and set to "Disabled". Then close the app and reboot the server.

It worked like a charm and shut the PC techs up real quick. It really embarrassed them.

Look for Local Security Policy instead of Domain Controller Security Policy. This is where I found the same settings for my "workgroup server" since my school isn't running active directory. Making the same changes works like a charm.

I too had the same problem and had some major battles with the PC techs who were trying to convince my client that it was the fault of the Mac guy (me) that the Mac's couldn't connect to the Windows 2003 server. With a little research I found this on the Microsoft site:

Windows Server 2003 uses secure encryption which the version of samba in Panther (Mac Operating System) doesn't support. The server's authentication needs to be changed to allow unsigned authentication, per the following: On the server, go to "Start" ->"Administrative Tools" -> "Domain Controller Policy" (not Domain Policy) and look for "Security Settings" -> "Local Policies" -> "Security Options" -> "Microsoft network server: Digitally sign communications (always)". It should show "Enabled" by default. Double-click on it and set to "Disabled". Then close the app and reboot the server.

It worked like a charm and shut the PC techs up real quick. It really embarrassed them.

Huh? Why would the PC techs be embarrassed for using a more secure method of logging in? By making the above changes to your 2000/2003 server, you're effectively sending all your usernames and passwords in plaintext across the network. Hardly what any good system administrator would want in the year 2005. You're asking the Windows server to lower it's security for ALL clients, in order for your Macs to connect.

----------Here is the true solution--------
the proper solution will cost money and will not sacrifice security. The solution is to use Thursby Dave 6.2. It is compatible with OS 8-x.4. 680x0, PPC and x86/intel. This is the only proper solution.

One comment. Setting up copiers such as lanier, xerox, cannon, etc., to
function as scanners with delivery to a network share also requires this
exact same fix. Or works just fine to a macintosh share, which is due to
the copiers using SMB authentication to accesss the network share.

So if you require the increased security as above, but need to scan files
through a copier to a file, it's better to set the share up from a macintosh than
from a Windows 2003 server. Then just move it along to where it needs to go.

Actually, changing those settings doesn't have any effect on the encryption of usernames and password. There just isn't any authentication of the communications between the client and the server; this does leave the setup open to man-in-the-middle attacks, but in any reasonably controlled network, that shouldn't be a real issue.

---
If everyone used macs, we'd be working on how to get to Alpha Centauri rather than how to get to Mars.

After reading Vista's EULA, I ordered a macbookpro. I've been playing with RH & Debian based distros for years, now I plan to stick with a *nix OS. Bash is my friend. Tiger is impressive and FAST! XP runs faster on Parallels than on a new Dell laptop. (I administer a medium size 2003 AD domain and need the XP mmc tools on my laptop).

One disappointment with Mac is the 2003 share smb access. I can't believe this has not been corrected by Apple. It appears I will have to change the domain security policies to allow the mac to connect to my 2003 servers.

I have successfully configured FC5 and Centos4 to use winbind and kerberos AD authentication. When using a login that is AD authenticated (FC or Centos), I can access my 2003 servers. Tiger's bash command line can access the servers also by using smbclient. What gives? If FC and RH can do it, why can't Apple? The fact these types of posts go back to 2004 leaves me confused. This is a big deal in my book. Until someone creates a directory better than AD (and as easy to administer), interoperability with samba is critical. If another solution besides a commercial smb OS X client is known, please post. I don't want to change the existing security policies in AD unless absolutely necessary.

I can't believe what a trial this has been and that there isn't more info on it. Am I the only person out there who uses my 2003R2 server for the few things Mac JUST CAN"T do?

Anyway, for over 10 years I have used my server to run QuickBooks, RDC to effect the program, and the little side bar that shows "shared" things to access files on the "server". On 10.8 none it flies. I have solved my QB problem with CoRD. I have followed your instructions to the letter and am having no luck with the "shared" things thing. Following the very few other threads I've found, I learned about the Network Access Server in my Users Prefs. Should I be doing something there? I could really use some help here.