"No mapping between account names and security IDs was done."

I want to chronicle this in the case someone runs into it in the future.  To begin with, this post very specifically refers to OS X Server, so, if you're seeing this message, and you're joining to a real Windows server or other Samba server, this isn't the answer.

I had to troubleshoot an OS X Server that had a little OpenDirectory meltdown.  That was easy enough to restore, and all of the Macs had no problem logging in and authenticating.  The Windows XP machines on this network, however, couldn't connect up.  Trying to re-join the domain provided by the OS X Server would result in the message "No mapping between account names and security IDs was done."

I immediately ran "net groupmap list".  True to form, everything looked mapped just fine.  Like all other Samba installations, the OS X variant relies on several text and binary files for its configuration:

- /etc/smb.conf
This is the main configuration file, and determines which shares are available, how the server acts, and more.  The Server Admin tool actually does a pretty good job of maintaining this file.  If you ever do need to customize it beyond what SA provides y editing it directly (like, changing the umask for a share, perhaps), lock it with chflags and never use SA to edit it again.

- Contents of /var/samba
This contains various tdb files (trivial database) that samba uses to keep track of group mappings and other settings.

- /var/db/samba/secrets.tdb
Stores the domain SID and ldap admin's password.  Super critical.  You will need to keep this file in-sync if you change your ldap admin password with the opendirectorypdb utility.  It's not well documented, but you can glean some of its use from the the /etc/smb.conf file.  To update the password and admin authority, right from the server, use:

# opendirectorypdbconfig -c set_authenticator -r (ldap-admin) -p (password) -n "/LDAPv3/127.0.0.1"

You can also update the SID in secrets.tdb with
# net rpc GETSID
So, what happened in the case of said server?  Interestingly, Apple stores one more bit of information, and not in the file system like the traditional samba config.  It's stored in LDAP.

Launch Workgroup Manager, and make sure you have "Show 'All Records' tab and Inspector" selected in the preferences.  Click on the 'Inspector' tab:

Figure 1: Highlighted inspector tab

Change the drop-down menu to 'Config'.  The first choice in the list is "CIFSServer".  Very strange that this is the only reference to the protocol as CIFS, rather than smb.  This record stores, among other things, two plist files, each of which references the domain SID.  If this doesn't match what samba knows as the SID, things just aren't going to work out.  You can find out what samba thinks the SID is with the net command:
# net getlocalsid example
SID for domain example is: S-1-5-21-345636990-1847564683-8037561256

...where "example" is the domain name in question.  Copy the SID, edit the XMLPlist and apple-xmlplist and paste in the 'correct' SID where appropriate.

You should be able to reset samba by setting the smb server as "Standalone", stopping smb, nuking the contents of /var/samba and /var/db/samba and restarting.  You can them promote to PDC again and test joining the domain.

Do note, though, that user profiles may act up after this SMloBotomy.  There are ways and tools that deal with this, like the 'profiles' utility, and some from Microsoft (that don't ship with Windows Server!!!  Why do I have to download admin utilities separately?).  You can also export the profile ahead of time and mark it for use by 'everyone'.

Presumably, you could go the other way and update your samba SID to match the value stored in the directory.  Frankly, I just found this to be a little easier: no group remapping involved.

Why the directory wasn't updated after configuring (and reconfiguring) samba is a bit odd.  Not sure if you can just nuke the CIFSServer record and let it reconstruct.  I get the feeling this is a bug buried somewhere, but I really haven't had the time to do any in-depth testing.

Hope that helps someone out there!