Directory Services 7.4.3

Server security

Secure DS server installations as outlined below.

Server account

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 389, 443, and 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 users to run commands, such as the ldapsearch command.

  • Prevent other users from reading configuration files.

    On Linux, set a umask such as 027 to prevent users in other groups from accessing server files.

    On Windows, use file access control to do the same.

Encryption

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 Linux 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-ldif command, encrypt the LDIF output.

File permissions

Many DS server file permissions depend on the software distribution, not the Linux 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:

Setting Impact

umask of 027

A Linux umask setting of 027 for the server account prevents members of other groups from reading files, and listing keystore contents.

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.

umask of 077

A Linux umask setting of 077 for the server account prevents members of the server user’s group from reading files, and listing keystore contents.

This setting can be useful when no other processes need access to server files.

Other users can still run commands delivered with the server.

log-file-permissions

This setting applies to DS-native file-based log publishers on Linux systems. It does not apply to Common Audit file-based log publishers. Its value is a Linux mode string.

The impact of the setting is independent of the server user’s umask setting.

The default for file-based log publishers is 600. A value of 640 allows only the user read/write access to the logs.

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:

  • The backup folder, by default /path/to/opendj/bak.

  • The configuration folder, /path/to/opendj/config.

  • The logs folder, by default /path/to/opendj/logs.

Disable unused features

Use the status command to check which connection handlers are enabled.

Disable any unused connection handlers with the dsconfig set-connection-handler-prop --set enabled:false command.

Log settings

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.

Password management

Make sure you keep passwords secret in production.

In configuration files

By default, DS servers keystore passwords in configuration files with .pin extensions. 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.

In command arguments

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. Omit the --bindPassword option to provide the password interactively:

$ ldapsearch \
 --hostname localhost \
 --port 1636 \
 --useSsl \
 --usePkcs12TrustStore /path/to/opendj/config/keystore \
 --trustStorePassword:file /path/to/opendj/config/keystore.pin \
 --bindDN uid=admin \
 --baseDN uid=admin \
 "(&)" \
 userPassword

Password for user 'uid=admin':
dn: uid=admin
userPassword: {PBKDF2}10000:<hash>

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.

In directory data

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.