All,
I'm trying to configure LDAP with Websphere. I'm doing settings in "Security" area when I click on 'Test settings' I'm getting connection exception (SECJ7340E). The Ip/host are all fine but I'm not able to connect to the server. Have you come across such a situation?? Do you know the solution to this?
I'm using WAS 7.0.
LDAP troubleshooting is not hard.
What LDAP server are you connecting too? Does it have any logging? Can you get an error message from the LDAP server admins? (I.e. If they see a bad bind DN, bad password error etc, then you have a much easier troubleshooting job to do).
I am sure you have the right IP. Now what port should you be connecting too? Clear text is 389, LDAP over SSL is 636, but they might have changed those values for some reason.
Does your LDAP server allow clear text connections at all?
Do you have SSL configured correctly? Generally this means that whatever system you are using, its trusted root keystore should include the public key of the CA that signed the server cert used by the LDAP server. (I.e. Versign, Thwate) Possibly it is using a self signed certificate, in which case you should get an export of the CA that minted its public key to import into your keystore.
Webshpere is Java based, so I imagine it is using the the Java Keystore facility. Use the keytool executable in the Java bin directory to add the trusted root to the keystore WebSphere is using. (That detail I leave to you).
What Bind DN are you using? Is it a real correct LDAP DN to connect with?
Use an LDAP browser like ApacheDS and see what it takes to connect to the LDAP server to validate the settings.
Related
I'm adding Google reCaptcha v3 to my J2EE application that runs under WebSphere 6.1. (I know, its no longer supported. A software upgrade is on the plan, just not immediately.)
I've followed the steps below to add the www.google.com:443 cert to WebSphere's NodeDefaultTrustStore, and after restarting WebSphere, the SSL cert is accepted no problem. My servlet code that does the reCaptcha verify logic works fine and all is well.
However, the following day, the certificate I imported is no longer accepted. When I import it again, I see that the Fingerprint (SHA digest) is different than the previous day. It looks like Google changes their SSL cert on a daily basis. Is this true? If so, how do I get around this problem in WebSphere?
CWPKI0428I: The signer might need to be added to the local trust store.
You can use the Retrieve from port option in the administrative console to retrieve the certificate and resolve the problem.
If you determine that the request is trusted, complete the following steps:
Log into the administrative console.
Expand Security and click SSL certificate and key management.
Under Configuration settings, click Manage endpoint security configurations.
Select the appropriate outbound configuration to get to the (cell):ServerNode01Cell:(node):ServerNode01 management scope.
Under Related Items, click Key stores and certificates and click the NodeDefaultTrustStore key store.
Under Additional Properties, click Signer certificates and Retrieve From Port.
In the Host field, enter www.google.com in the host name field, enter 443 in the Port field, and www.google.com_cert in the Alias field.
Click Retrieve Signer Information.
Verify that the certificate information is for a certificate that you can trust.
Click Apply and Save.
"Retrieve from port" adds the leaf certificate. To do something more reliable, trust the issuer. The current issuer for is GlobalSign root CA R2 which you can grab from https://pki.goog/ (GS Root R2)
Unfortunately it is hard to automate grabbing the root CA in tools like "retrieve from port" because many SSL toolkits do not send the root CA over the wire during the handshake -- because the client should already have it.
Here's an approach for WebSphere Liberty that might work for 6.1, I haven't tried it.
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html
Use the openssl method but take the -second- certificate in the list (which doesn't expire until 2021).
I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).
We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).
Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.
The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating
An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636
Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...
I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?
Thanks in advance for any-and-all assistance.
WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well
This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.
Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere
Check WebSphere's Keystores to ensure that the AD's key is contained. Follow #M.Tamboli's advice and restart WebSphere.
Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.
I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.
We are running WebSphere Application Server v8.5 on AIX 7, which we configured to use ldap security. Everything is working fine, but project went halt for some time and our WAS was down. Now we see that ldap cerficates were expired, hence we are unable to connect to dmgr & admin console. Can somebody help to resolve it?
We know how to configure ldap on WAS, but dont no how to change expired ldap cerficate with new cerficates. (We received new non-expiry certificates from ldap team but dont no how to configure it on WAS).
You need to disable security, restart dmgr, replace certificates and reenable security.
To disable security:
stop/kill the dmgr
run the following from the dmgr\bin folder:
wsadmin -conntype NONE
At the wsadmin prompt, type securityoff and then type exit.
Restart your dmgr.
UPDATE
Do you have Federated or Standalone Ldap configured? You should have in LDAP configuration link to SSL configuration. There you will need to add your new certificate to the Signers store (this is very simplified description as I'm not sure which repository you are using).
I am working on an application where we need to create user with passwords within Open LDAP. The problem is i don't have a relevant certificate which i can add to the truststore. I will get this certificate in some time but i can't wait for that.
I know that in Active Directory if i want to do such a thing i must have a 128 bit SSL connection between client and server and i have to use unicodePwd attribute but i am guessing that for open ldap i don't need any ssl connection and the password would be saved in the attribute userPassword so i can add the user with password over port 389. Are my assumptions correct?
Can anybody please point me to setup openldap on windows environment as well as this will just be used for my own tests. Thanks
I am guessing that for open ldap i don't need any ssl connection and the password would be saved in the attribute userPassword so i can add the user with password over port 389. Are my assumptions correct?
Yes, you can do it, but it isn't advisable, as you will be transmitting passwords in plaintext. You should really go the extra yard and set it up for SSL as well, on port 636, or with the STARTTLS option on port 389 if port conservation is an issue.
Can anybody please point me to setup openldap on windows environment as well as this will just be used for my own tests.
It's all documented at http://openldap.org. Windows-specific instructions will depend partly on which Windows port of OpenLDAP you're using. I'm aware of at least three.
I have an application which can access a LDAP server with non-SSL connection. Now, the LDAP server has been configured to support only SSL.
So, now what are the new components or changes in the existing components which I have to do.
If your application really doesn't support SSL (btw it would've made things easier if you'd told us what program you're trying to use), you can try an SSL wrapper, such as stunnel that can be configured to connect to the SSL-protected LDAP service whenever your program connects to the "entrance" of the tunnel. This way, your program doesn't have to support SSL, but your connection to the LDAP server is still secured by SSL (if the SSL wrapper runs on the same host as your program).
You should only have to change ldap: to ldaps: in the client.