PortsConfiguring This chapter shows you how to configure OpenDJ directory server to listen for directory client requests, using connection handlers. You can view information about connection handlers in the OpenDJ Control Panel, and update the configuration using the dsconfig command.

You configure LDAP client access by using the command-line tool dsconfig. By default you configure OpenDJ to listen for LDAP when you install. The standard port number for LDAP client access is 389. If you install OpenDJ directory server as a user who can use port 389 and the port is not yet in use, then 389 is the default port number presented at installation time. If you install as a user who cannot use a port < 1024, then the default port number presented at installation time is 1389. Change the port number using the dsconfig command. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAP Connection Handler" --set listen-port:11389 --trustAll --no-prompt This example changes the port number to 11389 in the configuration. Restart the connection handler so the change takes effect. To restart the connection handler, you disable it, then enable it again. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAP Connection Handler" --set enabled:false --trustAll --no-prompt $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAP Connection Handler" --set enabled:true --trustAll --no-prompt

Certificates One common way to protect connections between OpenDJ and client applications involves using StartTLS for LDAP or LDAPS to secure connections. OpenDJ and client applications use X.509 digital certificates to set up secure connections. Both OpenDJ and client applications check that certificates are signed by a trusted party before accepting them. Merely setting up a secure connection therefore involves a sort of authentication using certificates. If either OpenDJ or the client application cannot trust the peer certificate, then the attempt to set up a secure connection must fail. By default OpenDJ client tools prompt you if they do not recognize the server certificate. Other clients might not prompt you. OpenDJ server has no one to prompt when a client presents a certificate that cannot be trusted, so it must simply refuse to set up the connection.Unless you use the Blind Trust Manager Provider, which is recommended only for test purposes. In other words, it is important for both OpenDJ and client applications to be able to verify that peer certificates exchanged have been signed by a trusted party. In practice this means that both OpenDJ and client applications must put the certificates that were used to sign each others' certificates in their respective trust stores. Conventionally, certificates are therefore signed by a Certificate Authority (CA). A CA is trusted to sign other certificates. The Java runtime environment for example comes with a trust store holding certificates from many well-known CAs.$JAVA_HOME/jre/lib/security/cacerts holds the CA certificates. To read the full list, use the following command. $ keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit If your client uses a valid certificate signed by one of these CAs, then OpenDJ can verify the certificate without additional configuration, because OpenDJ can find the CA certificate in the Java CA certificate trust store. Likewise if you set up StartTLS or LDAPS in OpenDJ using a valid certificate signed by one of these CAs, then many client applications can verify the OpenDJ server certificate without further configuration. In summary, if you need a certificate to be recognized automatically, get the certificate signed by a well-known CA. You can, however, choose to have your certificates signed some other way. You can set up your own CA. You can use a CA whose signing certificate is not widely distributed. You can also use self-signed certificates. In each case, you must add the signing certificates into the trust store of each peer making secure connections. For OpenDJ directory server, you can choose to import your own CA-signed certificate as part of the installation process, or later using command-line tools. Alternatively, you can let the OpenDJ installation program create a self-signed certificate as part of the OpenDJ installation process. In addition, you can add a signing certificate to the OpenDJ trust store using the Java keytool command. The following example shows the keytool command to add a client application's binary format, self-signed certificate to the OpenDJ trust store (assuming OpenDJ is already configured to use secure connections). This enables OpenDJ to recognize the self-signed client application certificate. (By definition a self-signed certificate is itself the signing certificate. Notice that the Owner and the Issuer are the same.) $ keytool -import -alias myapp-cert -file myapp-cert.crt -keystore /path/to/opendj/config/truststore -storepass `cat /path/to/opendj/config/keystore.pin` Owner: CN=My App, OU=Apps, DC=example, DC=com Issuer: CN=My App, OU=Apps, DC=example, DC=com Serial number: 5ae2277 Valid from: Fri Jan 18 18:27:09 CET 2013 until: Thu Jan 13 18:27:09 CET 2033 Certificate fingerprints: MD5: 48:AC:F9:13:11:E0:AB:C4:65:A2:83:9E:DB:FE:0C:37 SHA1: F9:61:54:37:AA:C1:BC:92:45:07:64:4B:23:6C:BC:C9:CD:1D:44:0F SHA256: 2D:B1:58:CD:33:40:E9:ED:...:EA:C9:FF:6A:19:93:FE:E4:84:E3 Signature algorithm name: SHA256withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 54 C0 C5 9C 73 37 85 4B F2 3B D3 37 FD 45 0A AB T...s7.K.;.7.E.. 0010: C9 6B 32 95 .k2. ] ] Trust this certificate? [no]: yes Certificate was added to keystore When working with a certificate in printable encoding format (.pem) rather than binary format, use the -rfc option, too. Restart OpenDJ after adding certificates to the trust store to make sure that OpenDJ reads the updated trust store file. On the client side, if your applications are also Java applications, then you can also import the OpenDJ signing certificate into the trust store for the applications using the keytool command. The following example shows the keytool command to export the OpenDJ self-signed certificate in binary format. $ keytool -export -alias server-cert -file server-cert.crt -keystore /path/to/opendj/config/keystore -storepass `cat /path/to/opendj/config/keystore.pin` Certificate stored in file <server-cert.crt> Importing the server certificate is similar to importing the client certificate, as shown above. The following sections describe how to get and install certificates for OpenDJ directory server on the command line, for use when setting up StartTLS or LDAPS. First you create a server certificate in a Java Key Store. Next you issue a signing request to the CA, and get the CA-signed certificate as a reply. Then you set up the Key Manager Provider and Trust Manager Provider to rely on your new server certificate stored in the OpenDJ key store. Generate the server certificate by using the Java keytool command. The CN attribute value is the FQDN for OpenDJ directory server, which you can see under Server Details in the OpenDJ Control Panel. $ keytool -genkey -alias server-cert -keyalg rsa -dname "CN=opendj.example.com,O=Example Corp,C=FR" -keystore /path/to/opendj/config/keystore -storepass changeit -keypass changeit Notice that the -storepass and -keypass options take identical password arguments. OpenDJ requires that you use the same password to protect both the keystore and also the private key. Create a certificate signing request file for the certificate you generated. $ keytool -certreq -alias server-cert -keystore /path/to/opendj/config/keystore -storepass changeit -file server-cert.csr Have the CA sign the request (server-cert.csr). See the instructions from your CA on how to provide the request. The CA returns the signed certificate. If you have set up your own CA and signed the certificate, or are using a CA whose signing certificate is not included in the Java runtime environment, import the CA certificate into the key store so that it can be trusted. Otherwise, when you import the signed certificate in the reply from the (unknown) CA, keytool fails to import the signed certificate with the message keytool error: java.lang.Exception: Failed to establish chain from reply. The following example illustrates import of a CA certificate created with the openssl command. See the openssl documentation for instructions on creating CAs and on signing other certificates with the CA you created. $ keytool -import -keystore /path/to/opendj/config/keystore -file ca.crt -alias ca-cert -storepass changeit Owner: EMAILADDRESS=admin@example.com, CN=Example CA, O=Example Corp, C=FR Issuer: EMAILADDRESS=admin@example.com, CN=Example CA, O=Example Corp, C=FR Serial number: d4586ea05c878b0c Valid from: Tue Jan 29 09:30:31 CET 2013 until: Mon Jan 24 09:30:31 CET 2033 Certificate fingerprints: MD5: 8A:83:61:9B:E7:18:A2:21:CE:92:94:96:59:68:60:FA SHA1: 01:99:18:38:3A:57:D7:92:7B:D6:03:8C:7B:E4:1D:37:45:0E:29:DA SHA256: 5D:20:F1:86:CC:CD:64:50:...:DF:15:43:07:69:44:00:FB:36:CF Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 30 07 67 7D 1F 09 B6 E6 90 85 95 58 94 37 FD 31 0.g........X.7.1 0010: 03 D4 56 7B ..V. ] [EMAILADDRESS=admin@example.com, CN=Example CA, O=Example Corp, C=FR] SerialNumber: [ d4586ea0 5c878b0c] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 30 07 67 7D 1F 09 B6 E6 90 85 95 58 94 37 FD 31 0.g........X.7.1 0010: 03 D4 56 7B ..V. ] ] Trust this certificate? [no]: yes Certificate was added to keystore Import the signed certificate from the CA reply into the keystore where you generated the server certificate. In this example the certificate from the reply is ~/Downloads/server-cert.crt. $ keytool -import -trustcacerts -alias server-cert -file ~/Downloads/server-cert.crt -keystore /path/to/opendj/config/keystore -storepass changeit -keypass changeit Certificate reply was installed in keystore Configure the File Based Key Manager Provider for JKS to use the file name and key store PIN that you set up with the keytool command. $ dsconfig set-key-manager-provider-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --provider-name JKS --set enabled:true --set key-store-pin:changeit --remove key-store-pin-file:config/keystore.pin --trustAll --no-prompt Configure the File Based Trust Manager Provider for JKS to use the key store and PIN as well. $ dsconfig set-trust-manager-provider-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --provider-name JKS --set enabled:true --set trust-store-file:config/keystore --set trust-store-pin:changeit --trustAll --no-prompt At this point, OpenDJ directory server can use your new CA-signed certificate, for example for StartTLS and LDAPS connection handlers. If you use a CA certificate that is not known to clients, such as a CA that you set up yourself rather than a well-known CA whose certificate is included with the client system, import the CA certificate into the client application trust store. Otherwise the client application cannot trust the signature on the OpenDJ CA-signed server certificate. If you choose to configure LDAP Secure Access when setting up OpenDJ directory server, the setup program generates a key pair in the Java Key Store /path/to/opendj/config/keystore, and self-signs the public key certificate, which has the alias server-cert. The password for the key store and the private key is stored in clear text in the file /path/to/opendj/config/keystore.pin. If you want to secure communications, but did not chose to configure LDAP Secure Access at setup time, this procedure can help. The following steps explain how to create and install a key pair with a self-signed certificate in preparation to configure LDAPS or HTTPS. First you create a key pair in a new Java Key Store, and then self-sign the certificate. Next, you set up the Key Manager Provider and Trust Manager Provider to access the new server certificate in the new key store. If instead you want to replace the existing server key pair with self-signed certificate, then first use keytool -delete -alias server-cert to delete the existing keys before you generate a new key pair with the same alias. You can also either reuse the existing password in keystore.pin, or use a new password as shown in the steps below. Generate the server certificate using the Java keytool command. $ keytool -genkey -alias server-cert -keyalg rsa -dname "CN=opendj.example.com,O=Example Corp,C=FR" -keystore /path/to/opendj/config/keystore -storepass changeit -keypass changeit In this example, OpenDJ is running on a system with fully qualified host name opendj.example.com. The Java Key Store (JKS) is created in the config directory where OpenDJ is installed, which is the default value for JKS. Notice that the -storepass and -keypass options take identical password arguments. OpenDJ requires that you use the same password to protect both the key store and also the private key. Keep track of the password provided to the -storepass and -keypass options. Self-sign the server certificate. $ keytool -selfcert -alias server-cert -keystore /path/to/opendj/config/keystore -storepass changeit Configure the File Based Key Manager Provider for JKS to access the Java Key Store with key store/private key password. In this example, the alias is server-cert and the password is changeit. If you are replacing a key pair with a self-signed certificate, reusing the server-cert alias and password stored in keystore.pin, then you can skip this step. $ echo changeit > /path/to/opendj/config/keystore.pin $ chmod 600 /path/to/opendj/config/keystore.pin $ dsconfig set-key-manager-provider-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --provider-name JKS --set enabled:true --set key-store-file:config/keystore --set key-store-pin-file:config/keystore.pin --trustAll --no-prompt Configure the File Based Trust Manager Provider for JKS to use the key store and PIN as well. If you skipped the previous step, you can also skip this step. $ dsconfig set-trust-manager-provider-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --provider-name JKS --set enabled:true --set trust-store-file:config/keystore --set trust-store-pin-file:config/keystore.pin --trustAll --no-prompt At this point, OpenDJ directory server can use your new self-signed certificate, for example for StartTLS and LDAPS or HTTPS connection handlers.

StartTLS StartTLS (Transport Layer Security) negotiations start on the unsecure LDAP port, and then protect communication with the client. You can opt to configure StartTLS during installation, or later using the dsconfig command. Make sure you have a server certificate installed. $ keytool -list -alias server-cert -keystore /path/to/opendj/config/keystore -storepass `cat /path/to/opendj/config/keystore.pin` server-cert, Jun 17, 2013, PrivateKeyEntry, Certificate fingerprint (SHA1): 92:B7:4C:4F:2E:24:...:EB:7C:22:3F Activate StartTLS on the current LDAP port. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAP Connection Handler" --set allow-start-tls:true --set key-manager-provider:JKS --set trust-manager-provider:JKS --trustAll --no-prompt The change takes effect. No need to restart the server.

SSL You configure LDAPS (LDAP/SSL) client access by using the command-line tool dsconfig. You can opt to configure LDAPS access when you install. The standard port number for LDAPS client access is 636. If you install OpenDJ directory server as a user who can use port 636 and the port is not yet in use, then 636 is the default port number presented at installation time. If you install as a user who cannot use a port < 1024, then the default port number presented at installation time is 1636. Make sure you have a server certificate installed. $ keytool -list -alias server-cert -keystore /path/to/opendj/config/keystore -storepass `cat /path/to/opendj/config/keystore.pin` server-cert, Jun 17, 2013, PrivateKeyEntry, Certificate fingerprint (SHA1): 92:B7:4C:4F:2E:24:...:EB:7C:22:3F Configure the server to activate LDAPS access. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAPS Connection Handler" --set listen-port:1636 --set enabled:true --set use-ssl:true --trustAll --no-prompt This example changes the port number to 1636 in the configuration. Change the port number using the dsconfig command. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAPS Connection Handler" --set listen-port:11636 --trustAll --no-prompt This example changes the port number to 11636 in the configuration. Restart the connection handler so the change takes effect. To restart the connection handler, you disable it, then enable it again. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAPS Connection Handler" --set enabled:false --trustAll --no-prompt $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAPS Connection Handler" --set enabled:true --trustAll --no-prompt

Access control Using the OpenDJ directory server global configuration properties, you can add global restrictions on how clients access the server. These settings are per server, and so much be set independently on each server in replication topology. These global settings are fairly coarse-grained. For a full discussion of the rich set of administrative privileges and fine-grained access control instructions that OpenDJ supports, see the chapter on Configuring Privileges & Access Control. Consider the following global configuration settings. bind-with-dn-requires-password Whether the directory server should reject any simple bind request that contains a DN but no password. Default: true To change this setting use the following command. $ dsconfig set-global-configuration-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --set bind-with-dn-requires-password:false --no-prompt max-allowed-client-connections Restricts the number of concurrent client connections to the directory server. Default: 0, meaning no limit is set To set a limit of 32768 use the following command. $ dsconfig set-global-configuration-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --set max-allowed-client-connections:32768 --no-prompt reject-unauthenticated-requests Rejects any request (other than bind or StartTLS requests) received from a client that has not yet been authenticated, whose last authentication attempt was unsuccessful, or whose last authentication attempt used anonymous authentication. Default: false To shut down anonymous binds use the following command. $ dsconfig set-global-configuration-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --set reject-unauthenticated-requests:true --no-prompt return-bind-error-messages Does not restrict access, but by default prevents OpenDJ directory server from returning extra information about why a bind failed, as that information could be used by an attacker. Instead, the information is written to the server errors log. Default: false To have OpenDJ return additional information about why a bind failed use the following command. $ dsconfig set-global-configuration-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --set return-bind-error-messages:true --no-prompt

TLS By default OpenDJ supports the SSL and TLS protocols and the cipher suites supported by the underlying Java virtual machine. For details see the documentation for the Java virtual machine in which you run OpenDJ. For Oracle Java, see the Java Cryptography Architecture Oracle Providers Documentation for the The SunJSSE Provider. To list the available protocols and cipher suites, read the supportedTLSProtocols and supportedTLSCiphers attributes of the root DSE. Install unlimited strength Java cryptography extensions for stronger ciphers. $ ldapsearch --port 1389 --baseDN "" --searchScope base "(objectclass=*)" supportedTLSCiphers supportedTLSProtocols dn: supportedTLSCiphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 supportedTLSCiphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 supportedTLSCiphers: TLS_RSA_WITH_AES_128_CBC_SHA256 supportedTLSCiphers: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 supportedTLSCiphers: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 supportedTLSCiphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 supportedTLSCiphers: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 supportedTLSCiphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA supportedTLSCiphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA supportedTLSCiphers: TLS_RSA_WITH_AES_128_CBC_SHA supportedTLSCiphers: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA supportedTLSCiphers: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA supportedTLSCiphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA supportedTLSCiphers: TLS_DHE_DSS_WITH_AES_128_CBC_SHA supportedTLSCiphers: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA supportedTLSCiphers: TLS_ECDHE_RSA_WITH_RC4_128_SHA supportedTLSCiphers: SSL_RSA_WITH_RC4_128_SHA supportedTLSCiphers: TLS_ECDH_ECDSA_WITH_RC4_128_SHA supportedTLSCiphers: TLS_ECDH_RSA_WITH_RC4_128_SHA supportedTLSCiphers: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA supportedTLSCiphers: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA supportedTLSCiphers: SSL_RSA_WITH_3DES_EDE_CBC_SHA supportedTLSCiphers: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA supportedTLSCiphers: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA supportedTLSCiphers: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA supportedTLSCiphers: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA supportedTLSCiphers: SSL_RSA_WITH_RC4_128_MD5 supportedTLSCiphers: TLS_EMPTY_RENEGOTIATION_INFO_SCSV supportedTLSProtocols: SSLv2Hello supportedTLSProtocols: SSLv3 supportedTLSProtocols: TLSv1 supportedTLSProtocols: TLSv1.1 supportedTLSProtocols: TLSv1.2 You can restrict the list of protocols and cipher suites used by setting the ssl-protocol and ssl-cipher-suite connection handler properties to include only the protocols or cipher suites you want. For example, to restrict the cipher suites to TLS_EMPTY_RENEGOTIATION_INFO_SCSV and TLS_RSA_WITH_AES_256_CBC_SHA use the dsconfig set-connection-handler-prop command as shown in the following example. $ dsconfig set-connection-handler-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDAPS Connection Handler" --add ssl-cipher-suite:TLS_EMPTY_RENEGOTIATION_INFO_SCSV --add ssl-cipher-suite:TLS_RSA_WITH_AES_256_CBC_SHA --no-prompt --trustAll

HTTP JSON REST OpenDJ offers two ways to give RESTful client applications HTTP access to directory data as JSON resources. Enable the listener on OpenDJ directory server to respond to REST requests. With this approach, you do not need to install additional software. Configure the external REST LDAP gateway Servlet to access your directory service. With this approach, you must install the gateway separately. OpenDJ directory server has a handler for HTTP connections, where it exposes the RESTful API demonstrated in the chapter on Performing RESTful Operations. The HTTP connection handler is not enabled by default. You configure the mapping between JSON resources and LDAP entries by editing the configuration file for the HTTP connection handler, by default /path/to/opendj/config/http-config.json. The configuration is described in the appendix, REST LDAP Configuration. The default mapping works out of the box with Example.com data generated as part of the setup process and with Example.ldif. Enable the connection handler. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "HTTP Connection Handler" --set enabled:true --no-prompt --trustAll Enable the HTTP access log. $ dsconfig set-log-publisher-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --publisher-name "File-Based HTTP Access Logger" --set enabled:true --no-prompt --trustAll This enables the HTTP access log, opendj/logs/http-access. For details on the format of the HTTP access log, see the section on Server Logs. Try reading a resource. The HTTP connection handler paths start by default at the root context, as shown in the following example. $ curl http://bjensen:hifalutin@opendj.example.com:8080/users/bjensen ?_prettyPrint=true { "_rev" : "00000000315fb731", "schemas" : [ "urn:scim:schemas:core:1.0" ], "manager" : [ { "_id" : "trigden", "displayName" : "Torrey Rigden" } ], "contactInformation" : { "telephoneNumber" : "+1 408 555 1862", "emailAddress" : "bjensen@example.com" }, "_id" : "bjensen", "name" : { "familyName" : "Jensen", "givenName" : "Barbara" }, "userName" : "bjensen@example.com", "displayName" : "Barbara Jensen" } If necessary, change the connection handler configuration using the dsconfig command. The following example shows how to set the port to 8443, and to configure the connection handler to do SSL (using the default server certificate). If you did not generate a default, self-signed certificate when installing OpenDJ directory server see the instructions, To Create & Install a Self-Signed Certificate, and more generally the section on Preparing For Secure Communications for additional instructions including how to import a CA-signed certificate. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "HTTP Connection Handler" --set listen-port:8443 --set use-ssl:true --set key-manager-provider:JKS --set trust-manager-provider:"Blind Trust" --no-prompt $ stop-ds --restart Stopping Server... .... The Directory Server has started successfully $ keytool -export -rfc -alias server-cert -keystore /path/to/opendj/config/keystore -storepass `cat /path/to/opendj/config/keystore.pin` -file server-cert.pem Certificate stored in file <server-cert.pem> $ curl --cacert server-cert.pem --user bjensen:hifalutin https://opendj.example.com:8443/users/bjensen?_prettyPrint=true { "_rev" : "0000000018c8b685", "schemas" : [ "urn:scim:schemas:core:1.0" ], "contactInformation" : { "telephoneNumber" : "+1 408 555 1862", "emailAddress" : "bjensen@example.com" }, "_id" : "bjensen", "name" : { "familyName" : "Jensen", "givenName" : "Barbara" }, "userName" : "bjensen@example.com", "displayName" : "Barbara Jensen", "manager" : [ { "_id" : "trigden", "displayName" : "Torrey Rigden" } ] } Follow these steps to set up OpenDJ REST LDAP gateway Servlet to access your directory service. Download and install the gateway as described in To Install OpenDJ REST LDAP Gateway. Adjust the configuration for your directory service as described in REST LDAP Configuration.

DSML Directory Services Markup Language (DSML) client access is implemented as a servlet that runs in a web application container. You configure DSML client access by editing the WEB-INF/web.xml after you deploy the web application. In particular, you must at least set the ldap.host and ldap.port parameters if they differ from the default values, which are localhost and 389. The list of DSML configuration parameters, including those that are optional, consists of the following. ldap.host Required parameter indicating the host name of the underlying directory server. Default: localhost. ldap.port Required parameter indicating the LDAP port of the underlying directory server. Default: 389. ldap.userdn Optional parameter specifying the DN used by the DSML gateway to bind to the underlying directory server. Not used by default. ldap.userpassword Optional parameter specifying the password used by the DSML gateway to bind to the underlying directory server. Not used by default. ldap.authzidtypeisid This parameter can help you set up the DSML gateway to do HTTP Basic Access Authentication, given the appropriate mapping between the user ID, and the user's entry in the directory. Required boolean parameter specifying whether the HTTP Authorization header field's Basic credentials in the request hold a plain ID, rather than a DN. If set to true, then the gateway performs an LDAP SASL bind using SASL plain, enabled by default in OpenDJ to look for an exact match between a uid value and the plain ID value from the header. In other words, if the plain ID is bjensen, and that corresponds in the directory server to Babs Jensen's entry with DN uid=bjensen,ou=people,dc=example,dc=com, then the bind happens as Babs Jensen. Note also that you can configure OpenDJ identity mappers for scenarios that use a different attribute than uid, such as the mail attribute. Default: false ldap.usessl Required parameter indicating whether ldap.port points to a port listening for LDAPS (LDAP/SSL) traffic. Default: false. ldap.usestarttls Required parameter indicating whether to use StartTLS to connect to the specified ldap.port. Default: false. ldap.trustall Required parameter indicating whether blindly to trust all certificates presented to the DSML gateway when using secure connections (LDAPS or StartTLS). Default: false. ldap.truststore.path Optional parameter indicating the trust store used to verify certificates when using secure connections. If you want to connect using LDAPS or StartTLS, and do not want the gateway blindly to trust all certificates, then you must set up a trust store. Not used by default. ldap.truststore.password Optional parameter indicating the trust store password. If you set up and configure a trust store, then you need to set this as well. Not used by default. The DSML servlet translates between DSML and LDAP, and passes requests to the directory server. For initial testing purposes, you might try JXplorer, where DSML Service: /webapp-dir/DSMLServlet. Here, webapp-dir refers to the name of the directory in which you unpacked the DSML .war file. JXplorer accessing OpenDJ through DSML

JMX You configure Java Management Extensions (JMX) client access by using the command-line tool, dsconfig. Configure the server to activate JMX access. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "JMX Connection Handler" --set enabled:true --trustAll --no-prompt This example uses the default port number, 1689. Restart the server so the change takes effect. $ stop-ds --restart After you set up OpenDJ directory server to listen for JMX connections, you must assign privileges in order to allow a user to connect over protocol. Assign the privileges, jmx-notify, jmx-read, and jmx-write as necessary to the user who connects over JMX. See the section on Configuring Privileges for details. Connect using the service URI, user name, and password. Service URI Full URI to the service including the hostname or IP address and port number for JMX where OpenDJ directory server listens for connections. For example, if the server IP is 192.168.0.10 and you configured OpenDJ to listen for JMX connections on port 1689, then the service URI is service:jmx:rmi:///jndi/rmi://192.168.0.10:1689/org.opends.server.protocols.jmx.client-unknown. User name The full DN of the user with privileges to connect over JMX such as uid=kvaughan,ou=People,dc=example,dc=com. Password The bind password for the user.

LDIF File as backend The LDIF connection handler lets you make changes to directory data by placing LDIF in a file system directory that OpenDJ server regularly polls for changes. The LDIF, once consumed, is deleted. You configure LDIF file access by using the command-line tool dsconfig. Activate LDIF file access. $ dsconfig set-connection-handler-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "LDIF Connection Handler" --set enabled:true --trustAll --no-prompt The change takes effect immediately. Add the directory where you put LDIF to be processed. $ mkdir /path/to/opendj/config/auto-process-ldif This example uses the default value of the ldif-directory property for the LDIF connection handler.

For instructions on setting up the SNMP Connection Handler, see the section, SNMP-Based Monitoring.