This environment uses an all Mac environment, including two mac servers. These servers use Open Directory to manage user authenticate for file shares on the system. Open Directory is the LDAP equivalent for Mac OS Server, and allows Network Level Authentication (NLA) and profile customization.
Problem Being Addressed:
There was a request to add a new user account, however none of the users in the Open Directory had directory administration privileges, meaning they could not create new user accounts. The only account with those privileges was “DirAdmin”, the default directory administrator account. However, the password for this account was not known, and there was no way to change it within the Open Directory Manager tools without Directory Administrative rights. We did, however, have local Admin rights on the server.
The Approach Taken:
After attempting to change the password with other user accounts, the next step was to find a way to reset this password from the backend, instead of using the OD management tools. To do this, first we had to find the account’s “Slot ID”, the code that represents where that account sits within the OD database stored in the server. To do this, you open the Directory Editor for the server, open the preferences, and select the option to “Show ‘All Records’ tab and inspector”. Select the DirAdmin account, click the Inspector tab, and expand the entry for AuthenticationAuthority. In this entry, there is a value that begins with “ApplePasswordServer;” followed by a string of characters, and ending with a comma. Copy this value.
Next, open a Terminal session (found under Applications -> Utilities in Finder). Execute the command “sudo su”, and enter the local admin password when prompted. This will authenticated you with root-level privilages. Next, enter “mkpassdb –setpassword [slot-ID]”, where [slot-ID] is the ID copied in the previous section. The system will prompt you for a new password. Enter the password, and then quit the terminal session fully.
Now, you should be able to Authenticate as DirAdmin using the new password in the Directory Editor. Be sure to revert the preferences for “Show ‘All Records’ tab and inspector” you changed in the Directory Editor as well.
After resetting the password for DirAdmin, we were still unable to authenticate, as previous attempts to authenticate had saved a different username and password for the Directory Editor. Mac OS Server stores all manner of Authentication in the Keychain. Deleting this entry from the Keychain manager allowed us to re-authenticate as a different user. It is generally advised to keep all Administrative logins out of the Keychain, as this allows people with physical access to the server to make changes without knowing a username and password.
Things We Would Do Differently:
It is generally Best Practices to have at least two accounts with full administrative rights, so that you can change the password on one from the other. In this case, as the password was not known by the client’s staff, this might not have prevented the issue. They had documentation on usernames and passwords, but this list did not include admin passwords, which presumably were kept privately by the previous administrator. It is always important to maintain a current list of administrative usernames and passwords in Alfresco so that it is accessible by all techs, or so it can be provided to a client in the event they need it.