If you're not worried about malicious insiders, here's what I'd do:
Issue each authorized user a flashdrive with a file on it. The file contains the "password" (ideally it should be too long and random to easily memorize or type, so not really a password in the usual sense). The drive is encrypted using a full-volume encryption method (BitLocker, VeraCrypt, etc.) and each authorized user has their own passphrase to decrypt their flashdrive. The software reads the LDAP "password" out of the file, once the flashdrive is installed and unlocked.
Advantages of this system:
- The LDAP admin password can be completely beyond human ability to memorize.
- The password copies are stored on physical objects that are easy to maintain an inventory of.
- An attacker who steals a user's flashdrive hopefully won't know the passphrase to unlock it, so they can't decrypt the key.
- An attacker who guesses a user's passphrase hopefully can't access their flashdrive, so they can't use the passphrase for anything.
- In theory, each user could have a unique "password" for LDAP administration, allowing monitoring of usage and easy disabling of individual accounts at need.
- Kind of a hassle both for the users and for the IT folks who need to create and manage all these flashdrives.
- Changing / rotating the LDAP admin password is a mess, especially if everybody shares the same one; all the drives need to be updated.
- More common for people to get locked out because they lose a small object or forget a passphrase than if they only needed to keep track of one of those things.
- A malicious insider can just unlock their flashdrive and then copy the file contents out of it, trivially (or probably just decrypt the flashdrive).
You could also use hardware tokens, but most of the advantage over an encrypted flashdrive there is the ability to make the secret non-exportable. Unfortunately, that would prevent having the secret be a password, which must be transmitted in some form. That puts a real damper on how hard you can hide it, and in particular makes it totally impossible to hide from an insider.
IF at all possible, don't use a password here
Establish the connection using some form of public key cryptography. Mutual TLS, SSH with public key, whatever. Use a system where there's an unpredictable string to be signed or decrypted, and proving that you have the private key is used for authorization. Then use a hardware security module (HSM) to store the private key, and make sure it's not exportable. The key can now never be extracted, so the only way to use it is if you also have access to the HSM. Depending on your needs, this could be an HSM that is given to every authorized user or that is only available by checking out one of a limited number (possibly only 1) from a trusted source, and it could be relatively tied to computer hardware (such as the TPM in a PC) or portable (such as a Yubikey).
For extra security, you might protect access to the private key with a passphrase or other secret, turning it into effectively a two-factor authentication requirement (the attacker needs both to have the HSM, and to know the string that unlocks access to its key). SSH and GPG private keys already typically are encrypted using password-derived keys, but there are better systems than those use.
You can't do anything about an attacker with root access to a machine where the software runs. If the software can communicate with the LDAP server, the attacker can tap that communication, edit it to serve their own purposes, initiate it on demand, etc. Even if there's no post-authentication session token to steal, and the authentication sent on every request is done without exposing the secret (e.g. instead of a password, you use a symmetric key to HMAC the message or a private key to sign the message, and the key is stored somewhere the attacker can't read like inside an HSM), for as long as the attacker has access to the compromised system they'll have full control over its communication with the server, and you can do a LOT of damage in a short time.