- Limit the total number of concurrent sessions to the server and limit the number of concurrent sessions per client
- Set size-limit, lookthrough-limit, and time-limit per client appropriate to client requirements (be aware of the server’s default settings, often these settings are not conducive to a hardened server)
- Limit the time a connection can be unused, that is, open but no requests (idle-timeout). Hint: some load-balancers insist on leaving health-check connections open – administrators can use client connection policies and connection criteria to permit load-balancers to leave connections open indefinitely (no idle-timeout)
- Use Client Connection Policies to configure address-based authentication, that is, know each and every client by IP address range or domain and create a client connection policy that will terminate all unknown client connections immediately
- Create a Log Publisher for each IP address range or domain – this allows administrators to rapidly locate connection activity. See this example.
- Use SSL or TLS for client connections and reject non-secure connections from clients – configure the server to permit only the StartTLS Extended Operation on a non-secure connection.
- Use a separate physical network to connect for administrative sessions and use client connect criteria and policies to enforce administrative activity on the administrative network
- Use a separate physical network for replication sessions
- Use secure connections for replication traffic
- Use third-party certificates
- Reject all operations that are unauthenticated – this is better than simply disallowing anonymous BIND operations
- Reject all requests on the non-secure network except for the StartTLS Extended Request
- Ensure that selected administrators are trained and certificated on the procedure used for disconnecting clients
- Reject requests that would result in an unindexed search; consider deploying a directory server farm for data mining operations that is separate from main-line client LDAP traffic.
- Use Client Connection Policies to:
- restrict operations clients are allowed to perform
- restrict request controls and extended operations clients are allowed to use
- restrict authentication types and SASL mechanisms
- restrict the types of search filters
- enforce a minimum substring length
- reject requests that would result in an unindexed search
- restrict access to portions of the Directory Information Tree (DIT)
- to blacklist IP addresses that conduct denial-of-service attacks
- restrict operation-rates
Oracle makes critical patch updates to the Java platform from time to time.
Check the critical patch update website or subscribe to email or receive an RSS feed.
Do not permit servers with known bad JVM versions to participate in main-line LDAP traffic.
- Reject LDAPv2 except for legacy applications which do not support LDAPv3; consider upgrading those applications to a version which uses LDAPv3
- Use SHA-2 with a 512-bit digest for password digests
- Reject all operations on an unauthenticated session except for the StartTLS Extended Request
- Disable (or reject) all SASL mechanisms except for EXTERNAL and GSSAPI. This includes DIGEST-MD5, which is a weak scheme which requires the directory server have access to the clear text password, meaning the password must be stored in the clear (horrors) or be encrypted with a reversible encryption (almost as bad)
- Reject Simple BIND requests which have no password since no authentication takes place
- Reject Simple BIND requests which have a null DN and a null password since no authentication takes place
- Reject Simple BIND requests have a null DN and a non-null password since no authentication takes place
- Reject attempts to use pre-encoded passwords – the only exception is the use of external software which is capable of managing password history and password quality. As of 2013, the professional-quality UnboundID Directory Server is still the best option for low-level password management
- Do not allow weak encoding schemes for password storage, deny requests to use reversible storage schemes for password storage
- Suppress failure or explanatory text in BIND results unless users are prevented from seeing diagnostic/explanatory text by some other means, such as a web front end
- Reject proxied authentication if that feature is not required
- Use strict password validators
- Use account expiration
- Use password history
- Use the Password Modify Extended Request to change passwords
- Consider modifying the Default Password Policy to be more restrictive, creating a new default password policy, or using the Secure Password Policy as the default
Root DN (root user) accounts have an extensive set of privileges in the default distribution of the server products; therefore the root DN account(s) should not be used in normal operation except where a task cannot be performed by an administrator account.
Furthermore, root user accounts are not replicated whereas administrator accounts created in a replicated backend can be used on each server in a replicated topology.
The number of administrators with root user DNs and passwords should be as small as is practicable.
- Configure administrator accounts with privilege levels appropriate to need.
- Create groups for administrator accounts to make the task of specifying access controls easier.
- Select a small number of users who may hold passwords for any root DN accounts.
- Use a strict password policy for all users.
- Reject all BIND requests that specify a root DN from all but IP address range or domain.
LDAP Servers which do not have sufficient granularity of privileges and access controls should be avoided, or at least not used in professional, mission-critical environments.
Backups and Exports
- Digitally sign and encrypt all backups.
- Digitally sign and encrypt all LDIF exports.
- Reserve the backup, import, and export privileges for all accounts but a select few.
LDAP Servers which do not have the capability of digitally signing exports and backups should be avoided, or at least not used in professional, mission-critical environments. Under what circumstances would an operator be safe in importing an exported LDIF file when the server could not verify the contents by signature? Probably only the initial import when first installing the server or migrating away from some other server, any other time is just too dangerous because the data cannot be trusted.
- Create a
dsconfigbatch-file with all necessary configuration instructions for use in building new servers
- Consume all administrative alerts and notifications; do not ignore alerts and notifications
- report accounts with expired passwords
- report accounts with multiple passwords
- report accounts holding privileges
- report disabled accounts
- report entries with access control information
- report locked accounts
- report weakly encoded passwords
- Use configuration server groups to ensure configurations are constant in a group of servers
- Consider encrypting Directory Server data, especially if the data is subject to regulatory restrictions
- If encrypting data, consider the limitations on encrypted data, for example, index key values are not encrypted – do not index attributes with sensitive data
- Consider using sensitive attributes for those attribute values requiring additional protection
- limit the scope of access control instructions
- use global access controls only when there is no other way to solve a problem
|size-limit||the maximum number of objects to return in a search request|
|lookthrough-limit||the maximum number of objects the directory server will examine in the course of executing a search request|
|time-limit||the maximum amount of time the server will spend processing a request|
|connection criteria||an object used to classify LDAP client connections according to the properties of the search|
|client connection policy||an object used to constrain LDAP clients and set resources limitations|
|StartTLS Extended Operation||an LDAP extension used to promote a non-secure connection to a secure connection|