Directory Services 7.4.3

Security features

This short introduction provides an overview of DS security features.

Encryption and digests

When DS servers must store sensitive data, and file permissions alone are not sufficient, they use encryption and digests:

  • Encryption turns source data into a reversible code. Good design makes it extremely hard to recover the data from the code without the decryption key.

    Encryption uses keys and cryptographic algorithms to convert source data into encrypted codes and back again. Given the decryption key and the details of the algorithm, converting an encrypted code back to source data is straightforward, though it can be computationally intensive.

    DS software does not implement its own versions of all encryption algorithms. Instead, it often relies on cryptographic algorithms provided by the underlying JVM. DS servers do manage access to encryption keys, however. An important part of server configuration concerns key management.

    DS servers use encryption to protect data and backup files on disk. They can encrypt password values when you configure a reversible storage scheme. Another important use of encryption is to make network connections secure.

  • A digest (also called a hash) is a non-reversible code generated from source data using a one-way hash function. (A hash function is one that converts input of arbitrary size into output of fixed size.) Good one-way hash design design makes it effectively impossible to retrieve the source data even if you have access to the hash function.

    The hash function makes it simple to test whether a given value matches the original. Convert the value into a digest with the same hash function. If the new digest matches the original digest, then the values are also identical.

    DS server use digests to store hashed passwords, making the original passwords extremely hard to recover. They also use digests for authentication and signing.

In DS software, two types of encryption keys are used:

  1. Symmetric keys , also called secret keys, because they must be kept secret.

    A single symmetric key is used for both encryption and decryption.

  2. Asymmetric key pairs , consisting of a sharable public key and a secret private key.

    Either key can be used for encryption and the other for decryption.

Connection management

DS servers manage incoming client connections using connection handlers. Each connection handler is responsible for accepting client connections, reading requests, and sending responses. Connection handlers are specific to the protocol and port used. For example, a server uses one connection handler for LDAPS and another for HTTPS.

The connection handler configuration includes optional security settings. When you configure a handler, specify a key manager provider and a trust manager provider:

  • The key manager provider retrieves the server certificate when negotiating a secure connection.

    A key manager provider is backed by a keystore , which stores the server’s key pairs.

  • The trust manager provider retrieves trusted certificates, such as CA certificates, to verify trust for a certificate presented by a peer when setting up a secure connection.

    A trust manager provider is backed by a keystore that contains trusted certificates, referred to as a truststore when used in this way.

DS servers support file-based keystores and PKCS#11 security tokens, such as HSMs.

Always use secure connections when allowing access to sensitive information. For details, refer to Secure connections.

Cryptographic key management

DS servers use cryptographic mechanisms for more than setting up secure connections:

  • Encrypted backup files must be decrypted when restored.

  • Passwords can be protected by encryption rather than hashing, although this is not recommended.

  • Database backends can be encrypted for data confidentiality and integrity.

For all operations where data is stored in encrypted form, all replicas must be trusted to access the secret key.

Trust between servers depends on a public key infrastructure. This type of infrastructure is explained in more detail in Public Key Infrastructure.

Replication requires trust between the servers. Trust enables servers to secure network connections, and to share symmetric keys securely. Servers encrypt symmetric keys with a shared master key, and store them in replicated data. When a server needs the symmetric key for decryption or further encryption, it decrypts its copy with the master key.

The component that provides a common interface for cryptographic functions is called the DS Crypto Manager.

You can configure the following Crypto Manager features with the dsconfig command:

  • Protection for symmetric keys.

  • The alias of the shared master key to use for protecting secret keys.

  • Cipher key lengths, algorithms, and other advanced properties.

Authentication

Authentication is the act of confirming the identity of a principal, such as a user, application, or device. The main reason for authentication is that authorization decisions are based on the identity of the principal.

Servers should require authentication before allowing access to any information that is not public.

Authentication mechanisms depend on the access protocol. HTTP has a number of mechanisms, such as HTTP Basic. LDAP has other mechanisms, such as anonymous bind and external SASL. For details on supported mechanisms, refer to Authentication mechanisms.

Authorization

Authorization is the act of determining whether to grant a principal access to a resource.

DS servers authorize access based on these mechanisms:

  • Access control instructions (ACI)

    Access control instructions provide fine-grained control over LDAP operations permitted for a principal.

    ACIs can be replicated.

  • Administrative privileges

    Privileges control access to administrative tasks, such as backup and restore operations, making changes to the configuration, and other tasks.

    Privileges can be replicated.

  • Global access control policies

    Global access control policies provide coarse-grained access control for proxy servers, where the lack of local access to directory data makes ACIs a poor fit.

For details about ACIs and global access control policies with proxy servers, refer to Access control.

For details about privileges, refer to Administrative roles.

Monitoring and logging

You must monitor deployed services for evidence of threats and other problems. Interfaces for monitoring include the following:

  • Remote monitoring facilities that clients applications can access over the network.

  • Alerts to notify administrators of significant problems or notable events over JMX or by email.

  • Account status notifications to send users alerts by email, or to log error messages when an account state changes.

  • Logging facilities, including local log files for access, debugging, entry change auditing, and errors.

For details, refer to Monitoring.