Completely nerdy. Migrating OSX users, and weird login issues.

Well, with a clue from Sweth (to whom I now owe Vampire Wine) I finally came up with a workaround for my OSX problem.  It was weirder than I thought, and I still don't know all the ins and outs.

FWIW, for that one other OSX sysadmin out there:  IF  you have set up a global password policy to expire an account due to inactivity, and IF you have X11 forwarding enabled for the ssh server, a newly created user's account will be disabled the first time they attempt to ssh in.  If they ssh in before the inactivity password policy is applied, no problem.  If you or they disable X11 forwarding (ssh -x disables it on the user end), no problem.  A .Xauthority file in their account solves the problem.  My workaround was to put an empty .Xauthority file in the skeleton directory, which on osx is in /System/Library/User\ Template.  That way new accounts are created with an .Xauthority file and everyone is happy.

You're welcome, that one other guy in the world who has X11 forwarding enabled and is using the inactivity setting.

Also?  I think I have finally figured out how to migrate accounts between OSX servers.  It isn't super straightforward, and it isn't in the docs.  Part of it is, sort of.  You use dsexport to export the user information from directory services.  Like this:

dsexport export.out  /Local/Default dsRecTypeStandard:Users

In my case I then manually edited out of export.out any users I didn't want getting copied over.

On the new machine,  use dsimport:

dsimport export.out /Local/Default I

The I says "ignore the record if there is a conflicting name, UID, or GID".  There are other options.

Okay, so that imports the users.  The next part is the key.  The passwords are stored in /var/db/shadow/hash.  Copy the hash files for the users you have imported.  You'll need to know their generated UID, which you can get by reading their plist file (in /var/db/dslocal/Default/nodes/users/) or by using the Inspector in WorkgroupManager (turned on in WM preferences).  The hash files for each user are listed by the generated UID.

So, in theory, you just copy over the hash files (and associated state files) for the users and Bob's your uncle.  I only found this out when it was time to leave today so I won't know for sure until the morning.

Of course, you also need to copy over the normal stuff, like their home directories, and their mail if you're running a mail server.  In /var/spool/imap/dovecot/mail, if you were wondering.

BTW, if you already knew all this?  Why didn't you tell me BEFORE?

Oh well, I guess it was sort of fun figuring it out.