Okay this is something that isn’t immediately expressed in most integrations and not highlighted in the Oracle BI documentation but it happens every now and then – A client’s LDAP server is SSL protected and we need to leverage LDAP in our Oracle BI implementation. The long and the short of this method are found here, http://download.oracle.com/docs/cd/E21764_01/web.1111/e13707/atn.htm#BABDBHAA.
Here’s how to set up the configuration:
- Configure the LDAP Authentication provider. Make sure you select SSLEnabled on the Configuration > Provider Specific page.
- Obtain the root certificate authority (CA) certificate for the LDAP server.
- Create a trust keystore using the preceding certificate. For example, the following example shows using the keytool command to create the keystore ldapTrustKS with the root CA certificate rootca.pem.:
keytool -import -keystore ./ldapTrustKS -trustcacerts -alias oidtrust -file rootca.pem -storepass TrustKeystorePwd -noprompt
For more information about creating a trust keystore, see Chapter 11, “Configuring Identity and Trust.”
- Copy the keystore to a location from which WebLogic Server has access.
- Start the WebLogic Server Administration Console and navigate to the server-name > Configuration > Keystores page, where server-name is the WebLogic Server instance for which you are configuring this keystore.
- If necessary, in the Keystores field, click Change to select the Custom Identity and Custom Trust configuration rules.
- If the communication with the LDAP server uses 2-way SSL, configure the custom identity keystore, keystore type, and passphrase.
- In Custom Trust Keystore, enter the path and file name of the trust keystore created in step 2.
- In Custom Trust Keystore Type, enter jks.
- In Custom Trust Keystore Passphrase, enter the password used when creating the keystore.
- Reboot the WebLogic Server instance for changes to take effect.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
It’s 2015 and you can now establish totally respectable MS SQL DBA credibility just by mentioning you have been in the game since SQL Server version 9. You may even get the same gasps of shock from some colleagues that used to be reserved for the version 6 veterans.