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

Question

Level 1

25 points

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

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

Mac mini, OS X Server, Yosemite, OS X Server 4.0

Posted on Jan 4, 2015 2:45 PM

Reply

Answer 1

Jan 7, 2015 7:57 AM in response to hemmes

Hello Mike

I'm having the exam same issue.

I just got an interesting tip when logging in from a 10.9 Mac, it showed the window to accept a certificate at the login window just after login, the login window was still on the background. The server was sending it's usual certificate which is issued for the FQDN, but the client for some reason was expecting a cert for the top level domain, so the window was reporting a domain mismatch. 10.9 clients are able to login. I'm assuming 10.10 clients are more strict to evaluate the cert from the server and that's why login fails.

For some reason the client is expecting a different name for the server. Maybe there is some record or configuration in OD which makes the client look for a cert which is for the TLD instead of the server's FQDN?

For now I can't afford having services down so I'm restoring back to 10.8 and will continue investigating this issue in a test environment. I hope we can fix this...

Best

Robinson

Reply

Answer 2

hemmes Author

Level 1

25 points

Jan 7, 2015 6:01 PM in response to Robinson Nuñez

Yes, I forgot to mention that I suspected it's a certificate issue. There were a few instances in my troubleshooting, where I would add the OD using the Join button from Users and Groups preferences, then use the Directory Utility and uncheck the SSL option. This sort of worked, and let me login, but still didn't seem to add a binding on the server. When I went back to Directory Utility, it had made a duplicate entry with SSL enabled. So I now had one with SSL and one without. Let me also stress, that it adds the server using the IP address, even though I entered the FQDN in the Join dialog window. And, unlike adding an LDAP connection directly with Directory Utility, it would not let me change the server name, and also doesn't enable the "Use for authentication" or "Use for contacts" check boxes (even though those features worked intermittently). To me, that would be the cause of certificate errors and rejection of logins, no?

All in all, it's obviously a major bug, as everything worked as expected in the Mavericks iteration of the client and server software packages.

Reply

Answer 3

hemmes Author

Level 1

25 points

Jan 8, 2015 6:47 PM in response to Robinson Nuñez

Hey Robison,

I think I have it working, as I'm typing to you from my network admin account on my MacBook Pro. It's a bit strange to get going but, like I said, it's working and BINDed to the server.

I updated to Server 4.0.3 that was released a couple of days ago, hoping this would help...it did not. But I started troubleshooting agin anyway. This is what I did, and it was not started through the Join button in the User and Groups preferences:

- Open the Directory Utility (Spotlight search for Directory)

- Unlock the dialog window by clicking the lock icon and entering your credentials

- Double-click the LDAPv3 service

- Click the "New..." button

- Enter your OS X's FQDN in the "Server Name or IP Address:" box

- Check all three items (Encrypt..., Use for auth..., and Use for contacts)

- Click the "Continue" button

- After it begins processing, it will ask for Directory Admin credentials

- Enter your Directory Administrator's credentials.

* If you have been using your own, self created network user for administration, before you upgraded to Server 4, you'll likely need to add that user to the Directory Administrators group, first, using the built-in diradmin account credentials in Server.app. You can also just use the diradmin account for the BINDing credentials.

- Once it completes, you see the one entry, likely using the servers IP address as the server name.

- Click OK; you can leave it open, if you want to check how it looks after this is done, otherwise close the Directory Utility

- Now go into Login Options, under the Users and Groups settings in System Preferences

- Unlock the dialog box with the Lock button again

- The "Network Account Server:" value should state "Multiple"

- Click the "Edit..." button, at the bottom

- You should see two servers, one that is marked with a green dot (likely utilizing your server's FQDN), and one that is not communicating (likely using your server's IP address).

- Click the one that is not communicating, and then click the minus button ( – )

- Choose to stop using that server

- Now you'll need to Allow network users to log in at the login window

* I would allow all users, for now, just to test, then you can go back and change it

- Log out, and try logging in with a network user

I'm throwing these instructions out after banging my head against a wall, so I have no idea if they'll work for you or not. Plus, this has only been working for about 10 minute´s, so who knows if it'll stick. Let me know if you have any success.

-- Mike

Reply

Answer 4

hemmes Author

Level 1

25 points

Jan 12, 2015 5:42 AM in response to hemmes

This fails to work after reboot...back to the drawing board.

Reply

Answer 5

hemmes Author

Level 1

25 points

Jan 30, 2015 4:19 PM in response to hemmes

So anyone have any luck at all with this, or do we just have to wait for the next update? I can't believe I can't have network users logging in anymore, this is crazy! 10.10.2 did nothing to help...

Reply

Answer 6

Mar 13, 2015 6:06 PM in response to hemmes

Hi Mike

Just wanted to quick update... There was no way to make it work, short of trying a full clean install and explaining all users they have lost their passwords (not gonna happen here).

In the end I had to roll back to 10.8 and I've had a happy ODM since. Unfortunately replication doesn't work in 10.8.

I managed to keep upright another server with 10.10, calendar and wiki services are fine, but messages is struggling.

At this point I think we all expect more quality from Apple, they should replicate the excellent effort done with 10.6 in which they basically rewrote everything cleaning up years of mess, not focusing in hundreds of new marketing features.

Best

Robintosh

Reply

Answer 7

hemmes Author

Level 1

25 points

Mar 30, 2015 8:41 PM in response to Robinson Nuñez

Okay, gotacha'. I did start a bug report, that has now escalated into a full on email exchange. The Apple Enterprise team has me running scripts, sending results, etc...the works. I hope the articles about Apple changing focus to bug fixes is true, this is making my head spin.

Reply

Answer 8

hemmes Author

Level 1

25 points

Apr 2, 2015 12:09 PM in response to hemmes

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.

Reply