Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

El Capitan diradmin reset

Hello,


It seems (?) that i forgot the password of the diradmin. Tried to run the command sudo ldappasswd -x -H ldapi://%2Fvar%2Frun%2Fldapi -S uid=diradmin,cn=users,dc=ldap1,dc=example,dc=com without success:


New password:

Re-enter new password:

Result: Server is unwilling to perform (53)

Additional info: APPasswordChangeAllowed failed


In addition, i just realised that when i try to create/edit/delete users from the open directory, suddenly it start asking me for the diradmin password!


In the logs, i can see this:


server kdc[118]: ENC-TS pre-authentication succeeded -- diradmin@localhost

server kdc[118]: Client's key has expired at 2015-10-20T19:33:32 -- diradmin@localhost

server sudo[2428]: root : TTY=ttys000 ; PWD=/Users/admin ; USER=root ; COMMAND=/usr/bin/ldappasswd -x -H ldapi://%2Fvar%2Frun%2Fldapi -S uid=diradmin,cn=users,dc=ldap1,dc=domain,dc=local


Any ideas how to proceed?


Thanks.

Mac mini, OS X El Capitan (10.11)

Posted on Oct 20, 2015 10:44 AM

Reply
7 replies

Sep 29, 2017 1:46 PM in response to vasileiosg

Sometimes you DNS fails to resolve. OpenDirectory wants to use DNS, possibly to talk back to itself. If the OD system is trying to talk to mycooldomain.com and your machine is mycooldomain.com but it cannot resolve the DNS name for some reason, the diradmin login will start failing and any attempt to use the command line reset of the diradmin account:


sudo ldappasswd -x -H ldapi://%2Fvar%2Frun%2Fldapi -S uid=diradmin,cn=users,dc=ldap1,dc=mycooldomain,dc=com


will fail.


The easiest fix is to set up a DNS record in the server software on the server itself for mycooldomain.com. Have the server reference itself using its own IP address from the System Preferences. Then your diradmin should log in easily with your known password and if you failed to ldappasswd, it will probably work afterwards.

Oct 22, 2015 11:09 PM in response to vasileiosg

Many Open Directory problems can be resolved by taking the following steps. Test after each one, 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.

Jan 16, 2016 12:10 PM in response to Linc Davis

A bit more info, all my user accounts were due to require a new password by yesterday, but this shouldn't affect the admin accounts especially not diradmin.


I checked the account status:

sudo pwpolicy -u diradmin authentication-allowed

User <diradmin> is not be allowed to authenticate until password is changed: Password change is required by authentication server.

I then tried enabling root and changing the diradmin password using root as authenticator but it was denied:


Error: root privileges or authenticator required


So I think i'm in a catch 22, I need diradmin enabled to be able to enable diradmin !?

Jan 19, 2016 7:01 PM in response to Kevin Neal

Clearing the global or user-specific policy with pwpolicy might have helped:


OS X Server (Yosemite): Global policies can lock out Admin accounts - Apple Support


Once the policy is cleared (assuming one is set that has locked you out), you can reset diradmin's password using ldappasswd:


OS X Server: How to reset the Open Directory administrator password - Apple Support

El Capitan diradmin reset

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.