OS X Server, SMB, and Password Torment

There’s a new guy at work who insists that the use of “to whom” is archaic. His incorrect opinion, therefore, earns him the traditional MMH pseudonym of “The Unlettered Python Expert”, or TUPE for short.

So, TUPE comes into my office yesterday with a problem: He cannot connect to our shared file server (which runs Mac OS X Server 10.4.x) from his Linux box using SMB. He experienced the same problem a couple of weeks ago, but during my troubleshooting efforts the Server Admin utility stopped responding altogether. I had to reboot the whole thing anyway, and dismissed his inability to connect as some fux0r’d daemons and whatnot.

That wasn’t the case yesterday (and probably wasn’t the first time).

To make sure the SMB server was handling shit properly, I connected to it from my Mac using the traditional Apple+k keystroke, standard “smb://” server address, and my username & password. Success.

Next, I tried it from the Terminal application (command line) using smbclient, as he had tried from his box, again using my login credentials:

~ $ smbclient -U myname //1.1.1.1/SHARENAME
Password: (entered the right one)
Domain=[XSERVE] OS=[Unix] Server=[Samba 3.0.10]
smb: />

Success.

Aside: The above command will implicitly attempt to connect to the remote server (1.1.1.1) on port 445, which is the canonical SMB Domain Server port. If you wish to connect directly to port 139 (the “pure” SMB port), you must specify “-p 139” somewhere in the command (as I’ve done below). Add “-d 3” to the command to turn on debugging level 3, which will display IPs, ports, etc. if you want to see stuff like that.

Then, I tried it again from my box, but this time using TUPE’s username and password:

~ $ smbclient -U username -p 139 //1.1.1.1/SHARENAME
Password: (entered one)
session setup failed: NT_STATUS_LOGON_FAILURE

Failure? Agony!

This pointed to something wrong with his user account on the server. Naturally, I assumed that I’d supplied an incorrect password, and exhausted that possibility.

By this time, the Workgroup Manager app had been launched, and I was fucking around with his user account in an unholy manner. Going through it all, I noticed that my (working) user account was using a “Shadow” password, whereas his (b0rk’d) account was using a “Crypto” password.

Conclusion #1: The SMB server on OS X Server 10.4.x requires an account use shadow passwords.

Aha! Time to fix it. Go in, change his account to use shadow, re-enter his password a couple of times, and save it. Refresh the page…

“Crypto” Goddamnit!

Attempt the same procedure 4 to 23 more times. Utter “goddamnit!” 4 to 23 more times. The stupid GUI won’t let me change it!

Time to read up on some Apple Support docs, eh? I finally found one that says:

Only users whose accounts reside in the local directory domain can have a shadow password.

Huh? WTF is a “local directory domain”? As the “administrator”, am I supposed to know? Cuz fuck if I do! Further down:

Click the small globe icon above the list of users and choose from the pop-up menu to open the local directory domain where the user’s account resides.

“Small globe icon”? WTF? I can’t see any small globe…

smbshadow1.png

Yeah, so there it is. Note also that the line of text next to that elusive little prick of an icon reads, “Authenticated as xxxxxxxx to directory: /NetInfo/root”. Could this be the problem? Click the little bastard…

smbshadow2.png

Oh, shit… I can change that! I still don’t know WTF a “local directory domain” is, but that fuckin’ pulldown has a “Local” option! Select that.

Now the line of text reads, “Authenticated as xxxxxxxx to local directory: /NetInfo/DefaultLocalNode”.

Go back to his user account, change it to use shadow, do the password dance, and save it. Refresh the page…

“Shadow” w00t!

Conclusion #2: Make sure that you have “Local” selected in that crappy little pulldown menu if you experience problems doing shit to the user accounts on the server.

Try the connection again:

~ $ smbclient -U username -p 139 //1.1.1.1/SHARENAME
Password: (entered the right one)
smb: />

Success.

Advertisements

3 thoughts on “OS X Server, SMB, and Password Torment

  1. That is lame. Lame design! So lame it makes me want to disavow. I think I’ll move to Front Royal, remove my apple sticker from my car and pump gas, never wanting to hear SMB problems again.

    SMB problems, I hate you soo much … *shakes and brandishes fist*

  2. Ugh. Don’t get me started on how much the OS X Server “admin” GUI tools suck. Ever since the “new” and poorly-designed Server Admin.app decided to mangle all my internal DNS records (see here), I’ve had to manually edit zone files in /var/named.

    Despite their suckiness, Apple actually forces you to use Workgroup Manager.app to manipulate user accounts… AFAIK, there is no way to add or delete users from the CLI. Pain in my ass…

  3. It’s well hidden, but this utility lets you add users from the CLI:

    /Applications/Server/Workgroup Manager.app/Contents/Resources/dsimportexport

    The syntax is tragic :(

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s