Cannot authenticate in Directory Utility

So I have some bad news. This looks rather reminiscent of a server I was working with a couple of years ago, where (I honestly don't know how this happened) two simultaneous sessions of Active Directory were running at the same time. When trying to authenticate to a session, it would check against the other and I would be rejected with a "wrong authorization". Apple was stumped on how this even managed to happen.

You have a few solutions dependent on your situation. Do you have a backup from before it started rejecting you?

Can you wipe the server and start again? With a clean install of El Capitan instead of an upgrade? Did you previously have a different version of server software and install Apple Server on top of the remains of an old one?

If you can wipe the HD and start over, I would start afresh and build up from scratch.

Many Open Directory problems can be resolved by taking the following steps. Please test after each one that you haven't already taken, and back up all data before making any changes.

1. The OD master must have a static IP address on the local network, not a dynamic address. It must not be connected to the same network with more than one interface; e.g., Ethernet and Wi-Fi.

2. You must have a working DNS service, and the server's hostname must match its fully-qualified domain name. To confirm, select the server by name in the sidebar of the Server application window, then select the Overview tab. Click the Edit button on the Host Name line. On the Accessing your Server sheet, Domain Name should be selected. Change the Host Name, if necessary. The server must have at least a three-level name (e.g. "server.yourdomain.com"), and the name must not be in the ".local" top-level domain, which is reserved for Bonjour.

3. The primary DNS server used by the server must be itself, unless you're using another server for internal DNS. The only DNS server set on the clients should be the internal one, which they should get from DHCP if applicable.

4. If you have accounts with network home directories, make sure the URL's are correct in the user settings. A return status of 45 from the authorizationhost daemon in the log may mean that the URL for mounting the home directory was not updated after a change in the hostname or in the file-sharing protocol (from AFP to SMB or vice versa.) If the server and clients are all running OS X 10.10 or later, directories should be shared with SMB rather than AFP.

5. Follow these instructions to rebuild the Kerberos configuration on the server.

6. If you use authenticated binding, check the validity of the master's certificate. The common name must match the hostname and domain name. Deselecting and then reselecting the certificate in Server.app has been reported to have an effect in some cases. Otherwise delete all certificates and create new ones.

In the case of a self-signed certificate, create a trust profile in Profile Manager and deploy it on the clients. On the server, you may need to create the folder

/etc/openldap/certs

and put a copy of the server's certificate in it; for example:

/etc/openldap/certs/server-name

Also add a directive to the file

/etc/openldap/ldap.conf

of the form

TLS_CACERT /etc/openldap/certs/server-name

7. Unbind and then rebind the clients in the Users & Groups preference pane. Use the fully-qualified domain name of the master.

8. Reboot the master and the clients.

9. Don't log in to the server with a network user's account.

10. Disable any internal firewalls in use, including third-party "security" software.

11. If you've created any replica servers, delete them.

12. If OD has only recently stopped working when it was working before, you may be able to restore it from the automatic backup in /var/db/backups, or from a Time Machine snapshot of that backup.

13. If there are slapd errors in the log, try the following steps.

Turn off Open Directory in the Server app.

Enter in a shell:

cd /var/db/openldap

sudo -s

db_recover -c -h authdata

db_recover -c -h openldap-data

Turn Open Directory back on.

14. Reset the password policy database:

sudo pwpolicy -clearaccountpolicies

15. As a last resort, export all OD users. In the Open Directory pane of Server, delete the OD server. In some cases, you may have to use the shell to delete the server. Then recreate it and import the users. Ensure that the UID's are in the 1001+ range.

Enter name and password for node /LDAPv3/127.0.0.1

That should not be the node address. The node address should be the FQDN of the server. It sounds like your DNS setup is wrong.

Linc- your answer is really good except I found one discrepancy. I am able to get Profile Manager to install MDM profiles just fine, even with a .local server when I was evaluating Profile Manager (prior to DEP registration and signup). Not sure which thing was the most important but here's some stuff I did:

• My server's .local hostname is used as the iPads' DNS server

• iPads and server are on the same subnet

• The subnet (10.2.2.0/24 in my case) is set up as a Locale in Open Directory

• The .local hostname and the local IP were used in the setup of the certificates

• Server's DNS service is on, and has an entry directing its own hostname to its own local IP

• To get the Supervised clients to "Prepare" in configurator from their Welcome screen after the device reset into Managed by CompanyName mode, I had to set up a WiFi hotspot from the server so the devices would get the server as their DNS server, because you can't alter the WiFi settings (like DNS name) at that stage, and our router was still providing the ISP's DNS servers

That being said, it's important to note that despite Apple's own documentation saying nothing about it, and despite the OS X Server Profile Manager web pages not giving any indication about it, MDM profiles that get installed onto a device by being downloaded from your MDM server will always be able to be removed by the user. In other words, "profiles can never be removed" and "profiles require a password to be removed" settings will not be honored unless both of the following points (1) and (2) are true:

(1) the device is a DEP device purchased from Apple or an authorized reseller and its serial number was transferred by Apple or the reseller into your institution's DEP account; and

(2) the Apple ID that was used to set up the DEP account was also entered into Configurator and Profile Manager when the profile was created and the device downloaded it.

This is the case whether or not the device is set up as Supervised or not, according to what Apple Enterprise Support has told me today!

On the other hand if the profile is manually installed over a USB connection from Apple Configurator, then the "profiles can never be removed" and "profiles require a password to be removed" settings will be honored with a very important caveat: they can still be removed from the device using a DFU reset unless (1) and (2) above are both TRUE (also according to Apple Enterprise Support).

Now, I'm pretty peeved that these little factoids are not explicitly made clear anywhere in the documentation, since I wasted many hours trying to troubleshoot why it wasn't working, after already having wasted tons of time dealing with buggy certificate setups.

I strongly feel OS X Server should check the IP addresses and hostnames listed in certificates and validate that they will actually work given its current settings; and if they won't work, then the user should be presented with an error message stating that the certs are invalid. We should not have to wait until an actual user tries to connect before an error message is seen.

Further more, preferences that are only applicable to DEP devices should freaking say so in the UI and of course in the documentation.

Their support guy even tried to defend the fact that this requirement is not mentioned, stating "We hope that the customer will partner with us," but I told him sternly that if someone has already bought a bunch of iPads and is already running OS X server and has gotten to the point of setting up Profile Manager, then they have already partnered with Apple for all intents and purposes; they are already your customer; and software should not claim that it's doing something that it's not actually doing because that's terrible UI design.

I gave them a piece of my mind about the fact that this DEP requirement is undocumented and implicit. Since 2012 or earlier there have been many threads on these forums (many of which you've posted on, Linc) where there is never any mention of this requirement for the devices to be DEP or else the MDM profiles can simply be removed. All the documentation says is that the device must be a "Supervised" device for the profile removal restrictions to work, a patently false statement.

There are threads from FOUR YEARS AGO where people had bought 1000 iPads and distributed them to students and were having the students just delete profiles off willy nilly. Think of the amount of trouble that could have been solved if Apple had properly QA'd and documented this product, or if the ever bothered to actually read their own forums.

(The fact that Apple doesn't read and respond to these forums is a long-standing problem I have with Apple. Many companies do actually read and respond to their public forums—so many so that I would say most people honestly expect Apple to respond here. I think there are probably tens of thousands of customers who have left Apple for other brands whose attrition could have been prevented by Apple just taking the simple step of having support people respond to threads here and prevent thousands-of-post-long threads on longstanding issues to go on and on forever without ever addressing or resolving the issues that led to so many customers being frustrated.)