Can't Login With Network Account After Upgrade To Yosemite Server 4

Question

I've been putting off this troubleshooting for a while now, and after trying everything I could find, decided to post.
- After upgrading my server to Yosemite with Server 4, and my MacBook to Yosemite, I can no longer login with any network accounts.
- I was on clean installs of Mavericks before the upgrade.
- I'm using SSL for the OD, with a GoDaddy cert, the same one that was working on Mavericks.
- I've tried removing the laptop's binding using the Users and Groups preferences dialog, which does not remove the laptop's entry from Open Directory, so I manually deleted the record on the server.
- I then choose to Join again, and it looks as though everything goes through, but I still cannot login with a network account.  Also, when rejoining, it does not create a binding on the server.
- If I use the Directory Utility->Services->LDAPv3, and add it that way, entering the FQDN and checking Encrypt..., Use for auth and Use for contacts, it asks me for the directory admin username and password, and does in fact create the binding on the server, but I still cannot login.  What's strange about that method, is that it forces the use of the IP address of the server, rather than the FQDN, like I entered it, which would of course have problems, because the certificate's common name is the server's FQDN.  It does not allow me to change from using the IP address, graying out that field.
- I've also tried destroying the OD and restoring from archive to no avail.
It looks like many users have hit dead ends with this, with some having success by completely formatting and setting up a new iteration of the server, but I will not be doing that.  However, I'll be happy to try any other suggestions.
Thanks for your time,
   -- Mike

Answer 1

     Okay, I've finally resolved the issue, thanks to the Apple Enterprise tech support team.  I'm thinking they wouldn't mind if I share this information, but I can't guarantee that this will work on your system or, worse yet, degrade your system further.  However, that's fairly unlikely, just make sure you have plenty of backups before you begin any troubleshooting session.
     So I was told to perform the following instructions, which I did, line for line.  The part about closing Server.app seems a given, but I'm not sure why they want you to open Server.app at the the end (maybe taken out of context from some other instructions?).  I did it anyway, but you should be able to begin testing, on a client workstation, right after rekerberizing is complete.  I did, however, need to reboot my client, login as local admin, and then binding would proceed, and network users are able to login again.  The engineer also let me know to expect an error, something like the following: "2015-03-11 21:58:38 +0000 Error synchronizing removal of attribute draft-krbPrincipalACL from record 72519e4c-7ac7-15e4-bd42-10adb1944cbc: 77013 result: 16 No such attribute" - this is apparently normal, and did in fact happen in my experience.
So here's the fix:
- Quit Server.app (don’t just close the window)
- On the Open Directory Server, execute these Terminal commands:
  - sudo mkdir /var/db/openldap/migration/
  - sudo touch /var/db/openldap/migration/.rekerberize
  - sudo slapconfig -firstboot
- Open Server.app
And that's it.  I did nothing else on my OD server, just logged out.  Immediately tried binding on my MacBook client, it failed, I rebooted, tried again, it worked quickly, and I'm able to login with network user accounts again.