The topic is quite broad, so I'm not aware of a generic "best practices list" which addresses your questions. The topic quickly becomes very platform-specific.
Very generically:
- do check your specific scenario you're trying to defend of. There is no silver bullet.
- restrict (file) access permissions to those who do need access to that file.
- Password-based encryption/authtentication is simply something which needs to go.
Considering your exact question:
Is it needed to encrypt a configuration file with these credentials,
with an administrator decrypting it (Password based encryption) when
application starts ?
This option can improve security, but also be a major nuisance or reduce the availability of the service in question. Depending on scale, it can be highly problematic.
if the application is running without acceptable levels of redundancy (e.g. n+2), the application crashes every few hours or frequent updates do require frequent application restarts, an experienced administrator will write a script to restart the application in order to get the service back online as soon as possible. If this requires entering some password, this restart script will (sooner or later) contain the password as well. This will nullify your "extra" security.
recovering e.g. from a power outage may take a very long time, as the strategy involves manual interaction. If your application is running on hundreds or thousands of servers, it may take hours or days to manually recover from this.
in comparison to cryptographic keys, passwords are very short, restricted to a small range of ASCII characters and so do provide not that much entropy, resulting in severely limited level of security. Or, otherwise: 62^16 (16 char long alphanumeric password) is a minor fraction of what just 2^1024 (1024-bit keys) does provide in terms of entropy. If you're trying to defend against brute-force (offline) attacks, passwords can't be the only protection (unless you're willing to use very lenghty passwords).
Please do re-check your attack scenario: what are you trying to defend against?
The configuration file contains "secret" information. If the server's disk fails and is replaced, a (revived) failed disk shouldn't expose this information. Most kinds of disk or file system encryption will solve this issue while being transparent to the running application. Coupled with a hardware security module (e.g. a TPM module) instead of a password, the machine may also recover from a power outage without manual interaction.
A malicious user or attacker may get access to the machine and shouldn't have access to the config file. File system ACLs do so very fine.
A malicious user or attacker may get access to the application container and access data to be protected. This can be very hard to solve: the user could just dump memory of the running application and search for passwords in there. Many application containers also contain debugging and administration interfaces, from which a user can also directly access e.g. variables (who may contain the LDAP credentials). Securing those interfaces/consoles is also an important task.
You also didn't specify a platform or environment; e.g. in the windows environment (since you mentioned Active Directory), it may be a good idea to store passwords as a securestring in the registry. This does bind access to the specific application who stored that password. However, if the malicious user is running code or under the application's identity, this quickly results in the previous issue.
It seems the best way but it is not very easy to update LDAP account password
because you need to modify and re-encrypt the configuration file.
If the LDAP account password is changed, the configuration file needs to be modified anyway (and the application may require a reload/restart). Touching the file yet one more time by re-encrypting it isn't that much more work to do and can be automated in a very simple and yet secure way (e.g. gpg-encrypting the config-file using a public key whose private key is only known to the running application/machine, before pushing it to the machine).
If you're changing the LDAP account password to comply with some corporate password policy, the same policy will probably apply to the password used to encrypt the configuration file - so you need to re-encrypt that file anyway, why not combine this?
If running in a larger setup of application nodes, changing the LDAP account password may also become more complicated: you may have to shut down all running applications, change the password, wait for it to replicate to all LDAP/AD nodes, re-start the application. This does "require" an outage, and an alternative to this is to create a new LDAP/AD user with a different password, but using the same LDAP/AD permissions than the original user. You reconfigure your applications to use that new user and sequentially restart your application containers; given that those application containers are running with some redundancy mechanism, this can be an almost-seamless migration.
However, doing so requires you to maintain two user accounts with identical permissions; if they're manually managed, this will probably not work out very well.
