It's possible that you need to set the Authentication Search Path inside of Directory Utility -> Search Policy -> Authentication...Make sure "Search" says "Custom Path", and that your Active Directory domain is listed below.
If you do not see your AD domain in the list, you can authenticate to Directory Utility by clicking the lock in the lower-left corner, and then add a new search path by clicking the "+" button below the list of paths. Your domain should show up under "Available Directory Domains".
This setting should allow users to authenticate against Active Directory when connecting to your server. However, if AD users can authenticate against your OS X server successfully, the Search Path is not likely to be the culprit.
Alternatively, Workgroup Manager still exists, and may allow you to investigate the AD node more explicitly.
Lastly, you may be required to enable cleartext authentication to be able to authenticate your AD users to your OS X Server hosted wiki (the article applies to Mountain Lion and lower systems, but may be the same procedure that is required for Mavericks).
I'd recommend creating another self-signed cert in Server.app that you can use for securing services (if the others were expired/deleted). By creating the certificate using Server.app, it will automatically be available for other services (like Open Directory).
After you've created a new self-signed certificate, follow steps 6 through 12 in this article (which describe how your SSL certificate can be configured for use with Open Directory). Performing the Open Directory -> Settings -> LDAP -> SSL configuration through Server Admin will write the correct certificate paths into the slapd
config file.
Once you've corrected the certificate problems, Open Directory (slapd
) should start normally (without you having to start it by hand). If Password Server still doesn't show running after that, you might try a reboot (or check to see if it's generating crash logs or other errors in Console.)
Edit
After modifying the certificate configuration for use with LDAP, it's probably worth checking to see that the machine has provided updated certificate paths to slapd
in the slapd_macosxserver.conf
file. That is, the unique string of numbers and characters in the key/cert paths should have changed.
To confirm that slapd
can access the corresponding private key for the certificate that you're securing LDAP services with, you can check the file at /etc/openldap/slapd_macosxserver.conf
...Look for a line mentioning certadmin
...That line specifies the command that slapd
is using to retrieve the private key from the Keychain. It's possible to perform that command (copy and paste) in Terminal to see if the private key passphrase can be retrieved:
/usr/sbin/certadmin --get-private-key-passphrase /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem
Once you've retrieved the passphrase, see if you can view the private key using that passphrase:
sudo openssl rsa -in /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem -text -noout
When prompted for the pass phrase, copy and paste the value that you obtained in the step above. You should see the private key data output on the screen. This would confirm that:
1.) Your private key passphrase can be retrieved from the Keychain
2.) The pass phrase in the Keychain can be used to decrypt the key
If you are unable to get the pass phrase and unlock the key, it's possible that slapd
is not able to either. I believe that the software is using a keychain item in the System keychain named "Mac OS X Server certificate management" with a kind of "application password". The "Account" for that keychain item should be set to the same unique string of characters and numbers (456DACFFC771F8EB2F5A8E0EBB269969B8164097
in this example) that you see in the cert/key paths in /etc/certificates
. If you do not see one of these corresponding application passwords in the System keychain, it may be your issue.
Best Answer
The instructions for enforcing a default shell for users in macOS Catalina through Active Directory is available at Apple: https://support.apple.com/guide/directory-utility/set-a-unix-active-directory-user-accounts-diru34cb1e36/mac
Here's the procedure to manually update the shell (independently of any AD setting):
If the computer a natively installed with Catalina, then all user accounts will use
zsh
.If the computer was upgraded to Catalina, then:
all existing accounts will use
bash
and will see a warning thatzsh
is now the preferred shell in macOS.all newly created accounts will use
zsh
If a user wants to change their default shell environment from
zsh
tobash
, the following command can be issued at the command line prompt in Terminal.app:chsh -s /bin/bash
You can also change the default shell via System Preferences → Users & Groups. First unlock the padlock at the bottom-left, then control-click the user to edit and chose "Advanced options..." from the popup context menu. Edit the Login shell property by selecting the shell from the drop-down control.