Directory Services 7.3.5

Threats

Review common threats to directory services, which you can mitigate by following the instructions in this guide.

Insecure client applications

Directory services make a good, central, distributed store for identity data and credentials.

Standard access protocols, and delegated access and data management mean you might not know which client applications use your services. Some client applications may behave insecurely:

  • Prevent insecure connections.

    Require that applications connect with LDAPS and HTTPS, and restrict the protocol versions and cipher suites for negotiating secure connections to those with no known vulnerabilities. For details, refer to Secure connections.

  • Accept only secure management of sensitive data.

    Nothing in LDAPv3 or HTTP prevents a client application from sending credentials and other sensitive account data insecurely. You can configure the directory to discourage the practice, however.

  • Encourage secure authentication.

    For details, refer to Authentication mechanisms.

  • Encourage best practices for client applications, such as scrubbing input to avoid injection vulnerabilities.

    For details, refer to Client best practices.

Client applications

Client applications can misuse directory services. They may be poorly built or incorrectly configured, and waste server resources. If your organization owns the client, help the owner fix the problem.

Misuse can be intentional, as in a denial-of-service attack. Protect the directory service to limit attacks.

Unreasonable requests from client applications include the following:

  • Unindexed searches that would require the directory to evaluate all entries.

    Unindexed searches are not allowed by default for normal accounts, adjustable with the unindexed-search privilege.

    The access log records attempts to perform unindexed searches.

  • Excessive use of overly broad persistent searches, particularly by clients that do not process the results quickly.

    Review requests before setting ACIs to grant access to use the persistent search control. Alternatively, let client applications read the external change log.

  • Extremely large requests, for example, to update directory entries with large values.

    By default, requests larger than 5 MB are refused. The setting is per connection handler, max-request-size.

  • Requests that make excessive demands on server resources.

    Set resource limits.

  • Requests to read entire large group entries only to check membership.

    Encourage client applications to read the isMemberOf attribute on the account instead.

Poor password management

Despite efforts to improve how people manage passwords, users have more passwords than ever before, and many use weak passwords. You can use identity and access management services to avoid password proliferation, and you can ensure the safety of passwords that you cannot eliminate.

As a central source of authentication credentials, directory services provide excellent password management capabilities. DS servers have flexible password policy settings, and a wide range of safe password storage options. Be sure that the passwords stored in your directory service are appropriately strong and securely stored.

For details, refer to Passwords.

Manage passwords for server administration securely as well. Passwords supplied to directory server tools can be provided in files, interactively, through environment variables, or as system property values. Choose the approach that is most appropriate and secure for your deployment.

Make sure that directory administrators manage their passwords well. To avoid password proliferation for directory administrators, consider assigning administration privileges and granting access to existing accounts for delegated administrative operations. For details, refer to Administrative roles and Access control.

Misconfiguration

With the power to administer directory services comes the responsibility to make sure the configuration is correct. Misconfiguration can arise from bad or mistaken configuration decisions, and from poor change management.

Bad configuration decisions can result in problems such as the following:

  • A particular feature stops working.

    Depending on the configuration applied, features can stop working in obvious or subtle ways.

    For example, suppose a configuration change prevents the server from making LDAPS connections. Many applications will no longer be able to connect, and so the problem will be detected immediately. If the configuration change simply allows insecure TLS protocol versions or cipher suites for LDAPS connections, some applications will negotiate insecure TLS, but they will appear to continue to work properly.

  • Access policy is not correctly enforced.

    Incorrect parameters for secure connections and incorrect ACIs can lead to overly permissive access to directory data, and potentially to a security breach.

  • The server fails to restart.

    Although failure to start a server is not directly a threat to security, it can affect dependent identity and access management systems.

    Generally a result of editing the server configuration LDIF incorrectly, this problem can usually be avoided by using configuration tools. A server that started correctly saves a copy of the configuration in the var/config.ldif.startok file. You can compare this with the config/config.ldif file if the server fails to restart.

To guard against bad configuration decisions, implement good change management:

  • For all enabled features, document why they are enabled and what your configuration choices mean.

    This implies review of configuration settings, including default settings that you accept.

  • Validate configuration decisions with thorough testing.

    For details, refer to Tests.

  • Maintain a record of your configurations, and the changes applied.

    For example, use a filtered directory audit log. Use version control software for any configuration scripts and to record changes to configuration files.

    Make sure you also maintain a record of external changes on the system, such as changes to operating system configuration, and updates to software such as the JVM that introduce security changes.

  • Strongly encourage owners of applications that change ACIs, collective attributes, and similar settings in directory data to also follow good change management practices.

Unauthorized access

Data theft can occur when access policies are too permissive, and when the credentials to gain access are too easily cracked. It can also occur when the data is not protected, when administrative roles are too permissive, and when administrative credentials are poorly managed.

To protect against unauthorized access over the network, refer to the suggestions in Insecure client applications, Poor password management, and Access control.

To protect against unauthorized access by administrators, refer to the suggestions in Data encryption and Administrative roles.

Poor risk management

Threats can arise when plans fail to account for outside risks.

Develop appropriate answers to at least the following questions:

  • What happens when a server or an entire data center becomes unavailable?

  • How do you remedy a serious security issue in the service, either in the directory service software or the underlying systems?

  • How do you validate mitigation plans and remedial actions?

  • How do client applications work when the directory service is offline?

    If client applications require always-on directory services, how do your operations ensure high availability, even when a server or data center goes offline?

For a critical directory service, you must test both normal, expected operation, and disaster recovery.