PingDS 8.0.0

Trusted replicas (advanced)

This information applies to advanced deployments.

By default, all replication servers in a replication topology trust all replicas. If a replica allows an update, then other servers relay and replay the update without further verification. This simplifies deployments where you control all the replicas.

In deployments where you don’t control all the replicas, you can configure replication servers to accept updates only from trusted replicas. The trust depends on the certificate a replica presents to the replication server when connecting. Specifically, replication servers can verify trust when:

  • Trusted certificates have the OID 1.3.6.1.4.1.36733.2.1.10.1 in their extended key usage certificate extension.

    Use this policy when you control the CA signing the replicas' certificates, and can enforce that only authorized replicas have certificates with this setting.

  • They store fingerprints for all trusted certificates in their configurations.

    Use this policy when you don’t control the CA.

You choose the policy by setting the replication server advanced property, allow-updates-policy. It takes the following values:

all

(Default) Trust all replicas.

verify-certificate-key-usage

Only trust updates from replicas whose certificates' ExtendedKeyUsage includes 1.3.6.1.4.1.36733.2.1.10.1.

verify-certificate-fingerprint

Only trust updates from replicas with certificate fingerprints in the advanced property, allow-updates-server-fingerprints.

Avoid replication divergence

When a replication server doesn’t trust a directory server, it logs an error message explaining why. The replication server discards updates from untrusted servers. This can cause replication to diverge between the trusted and untrusted replicas. When replicas diverge, they respond differently to client applications.

To avoid divergence, don’t let untrusted replicas accept updates from client applications and prevent internal updates unless they’re from replication servers:

  1. Configure the untrusted replicas you control to be read-only.

    This prevents updates from client applications.

  2. Prevent internal updates arising from authentication.

    When an account binds (authenticates), the following password policy settings lead to internal updates:

    Per-server password policies DS subentry password policies

    deprecated-password-storage-scheme

    ds-pwp-deprecated-password-storage-scheme

    grace-login-count

    ds-pwp-grace-login-count

    idle-lockout-interval

    ds-pwp-idle-lockout-interval

    last-login-time-attribute

    ds-pwp-last-login-time-attribute

    lockout-duration

    ds-pwp-lockout-duration

    lockout-failure-count

    ds-pwp-lockout-failure-count

    lockout-failure-expiration-interval

    ds-pwp-lockout-failure-expiration-interval

    In your deployment, avoid using these password policy settings on untrusted replicas.

Trust extended key usage

  1. For each trusted DS server, get the certificate for replication signed with the appropriate extended key usage.

    If you use dskeymgr to generate server key pairs, use the dskeymgr create-tls-key-pair --writableReplica option.

    If not, the following example demonstrates a certificate signing request with the appropriate extended key usage:

    $ keytool \
 -certreq \
 -ext ExtendedKeyUsage:critical=clientAuth,serverAuth,1.3.6.1.4.1.36733.2.1.10.1 \
 -alias ssl-key-pair \
 -keystore /path/to/opendj/config/keystore \
 -storepass:file /path/to/opendj/config/keystore.pin \
 -file ssl-key-pair.csr

    The full process for each server involves generating a certificate signing request, signing the certificate in the request with the CA signing certificate, and importing the CA-signed certificate on the server.

  2. For each replication server, update the configuration to trust certificates with the appropriate extended key usage:

    $ dsconfig \
 set-replication-server-prop \
 --provider-name "Multimaster Synchronization" \
 --set allow-updates-policy:verify-certificate-key-usage \
 --hostname localhost \
 --port 4444 \
 --bindDN uid=admin \
 --bindPassword password \
 --usePkcs12TrustStore /path/to/opendj/config/keystore \
 --trustStorePassword:file /path/to/opendj/config/keystore.pin \
 --no-prompt

  3. For each replication server, make the directory servers reconnect.

    When a directory server connects, the replication server evaluates whether it trusts updates from the directory server.

    For example, restart the replication server:

    $ stop-ds --restart

Trust fingerprints

  1. For each trusted DS server, get the certificate fingerprint:

    $ keytool \
 -list \
 -alias ssl-key-pair \
 -keystore /path/to/opendj/config/keystore \
 -storepass:file /path/to/opendj/config/keystore.pin \
    Show output 
    ssl-key-pair, <date>, PrivateKeyEntry,
Certificate fingerprint (SHA-256): 05:55:BD:A5:E1:4C:35:A6:A5:4E:78:DD:3E:FD:EA:5A:66:5D:E0:DC:9C:C5:18:7E:E9:CA:A9:1E:CD:87:4B:78

  2. For each replication server, update the configuration to trust replicas by their certificate fingerprints:

    $ dsconfig \
 set-replication-server-prop \
 --provider-name "Multimaster Synchronization" \
 --set allow-updates-policy:verify-certificate-fingerprint \
 --hostname localhost \
 --port 4444 \
 --bindDN uid=admin \
 --bindPassword password \
 --usePkcs12TrustStore /path/to/opendj/config/keystore \
 --trustStorePassword:file /path/to/opendj/config/keystore.pin \
 --no-prompt

  3. For each replication server, update the configuration to recognize each certificate fingerprint.

    The following example demonstrates adding a trusted certificate fingerprint:

    $ dsconfig \
 set-replication-server-prop \
 --provider-name "Multimaster Synchronization" \
 --add allow-updates-server-fingerprints:\
"{SHA-256}05:55:BD:A5:E1:4C:35:A6:A5:4E:78:DD:3E:FD:EA:5A:66:5D:E0:DC:9C:C5:18:7E:E9:CA:A9:1E:CD:87:4B:78" \
 --hostname localhost \
 --port 4444 \
 --bindDN uid=admin \
 --bindPassword password \
 --usePkcs12TrustStore /path/to/opendj/config/keystore \
 --trustStorePassword:file /path/to/opendj/config/keystore.pin \
 --no-prompt

  4. For each replication server, make the directory servers reconnect.

    When a directory server connects, the replication server evaluates whether it trusts updates from the directory server.

    For example, restart the replication server:

    $ stop-ds --restart

  5. Repeat the relevant steps each time a trusted certificate changes.