Secure DS server installations as outlined below.
Do not run DS servers as the system superuser (root) or Windows Administrator.
Run the server under its own account, and use system capabilities to let the server account:
Access privileged ports, such as
636, as required.
Read and write to server files, and execute server commands.
Log in to the local system.
Use system capabilities to:
Allow administrator users to run commands as the server user.
Allow other user to run commands, such as the
Prevent other users from reading configuration files.
On UNIX, set a umask such as
027to prevent users in other groups from accessing server files.
On Windows, use file access control to do the same.
By default, only passwords are protected (hashed rather than encrypted). Encrypt other content to protect your data:
- Backend files
To encrypt entries and index content, refer to Data encryption.
- Backup files
Backup files are always encrypted. The server uses its Crypto Manager configuration to determine how to encrypt the backup files, and which HMAC algorithm to use to sign and verify backup file integrity. Backup file permissions depend on the UNIX umask or Windows file access control settings.
- Changelog files
To encrypt change log files, refer to Encrypt changelog data.
- LDIF exports
When you use the
export-ldifcommand, encrypt the LDIF output.
Many DS server file permissions depend on the software distribution, not the UNIX file mode creation mask. For example, the server commands are generally executable by all users, but only the server user can read PIN code files.
The following table recommends file permission settings:
Members of the server user’s group can still read the files.
Use this setting when other processes read the files to process them independently. For example, other processes might copy backup files to a remote system, or parse the logs to look for particular patterns.
This setting can be useful when no other processes need access to server files.
Other users can still run commands delivered with the server.
This setting applies to DS-native file-based log publishers on UNIX systems. It does not apply to Common Audit file-based log publishers. Its value is a UNIX mode string.
The impact of the setting is independent of the server user’s
The default for file-based log publishers is
Windows NTFS ACLs
On Windows systems, set folder ACLs on the NTFS volume where the server files are installed. Apply folder permissions that are inherited by all old and new files.
Consider setting ACLs on at least the following folders:
status command to check which connection handlers are enabled.
Disable any unused connection handlers
dsconfig set-connection-handler-prop --set enabled:false command.
By default, DS servers write log messages on error and when the server is accessed. Access logs tend to be much larger than error logs.
The default DS server log levels and rotation and retention policies facilitate troubleshooting while preventing the logs from harming performance or filling up the disk. If you change log settings for more advanced troubleshooting, reset the log configuration to conservative settings when you finish.
Make sure you keep passwords secret in production.
By default, DS servers keystore passwords in configuration files with
These files contain the cleartext, randomly generated passwords.
Keep the PIN files readable and writable only by the user running the server.
Alternatively, configure the server to store keystore passwords in environment variables or Java properties. Key Manager Provider and Trust Manager Provider settings let you make this change.
DS commands supply credentials for any operations that are not anonymous.
Password credentials can be supplied as arguments,
such as the
--bindPassword password option shown in the documentation.
In production, do not let the password appear in commands.
--bindPassword option to provide the password interactively:
$ ldapsearch \
--hostname localhost \
--port 1636 \
--usePkcs12TrustStore /path/to/opendj/config/keystore \
--trustStorePassword:file /path/to/opendj/config/keystore.pin \
--bindDN uid=admin \
--baseDN uid=admin \
Password for user 'uid=admin':
Notice that the password appears neither in the shell history, nor in the terminal session.
When using scripts where the password cannot be supplied interactively, passwords can be read from files.
For example, the
--bindPassword:file file option takes a file
that should be readable only by the user running the command.
By default, DS servers hash passwords before storing them. DS servers support many password storage schemes.
Password policies define password storage schemes, and characteristics of valid passwords. Configure your policies to use strong password storage, and to prevent users from using weak passwords or reusing passwords.