Wednesday, February 20, 2013

WASX7017E and ADMC0008E seen when federating LDAP into an IBM BPM Advanced 8.0.1 environment

Can you say "Doh!" ? In my case, I can/did, as the problem was clearly between the chair and the keyboard.

I saw this exception earlier today: -

WASX7017E: Exception received while running file "add_ldap.py"; exception information: java.lang.NullPointerException: java.lang.NullPointerException

whilst trying to federate an LDAP ( IBM Bluepages, for the record ) into my IBM BPM 8.0.1 environment, using a Jython script.

I also saw: -

[20/02/13 13:26:11:100 GMT] 00000025 GenericSerial E   ADMC0008E: The system failed to marshall the object of type com.ibm.websphere.management.cmdframework.provider.CommandResultImpl: com.sun.jndi.ldap.LdapCtx

( in SystemOut.log )

This Technote: -


although for WebSphere Portal pointed me at the answer: -

Cause

Invalid LDAP objects

What I mean to say is that the Technote forced me to compare/contrast this most recent invocation of a previously working script with my notes.

Almost immediately I realised that all the parameters were identical APART from the LDAP bind user ID.

This was the snippet of Jython that was failing: -

AdminTask.addIdMgrLDAPServer('[-id '+repositoryID+' -host '+ldapHost1+' -port '+ldapPort1+' -bindDN '+bindDN+' -bindPassword '+bindPassword+' -referal ignore -sslEnabled false -ldapServerType IDS -sslConfiguration -certificateMapMode exactdn -certificateFilter]')

When I checked, the property bindDN was the only difference between the working and failing invocation.

Therefore, I was attempting to bind to LDAP with a DN that DOES NOT EXIST :-)

Sadly, none of the WAS logs showed the specific LDAP exception, which was a shame - I'd expect to have seen "No such DN" or equivalent.

I know I could have enabled WAS tracing using trace strings such as: -

com.ibm.ws.security.*=all:com.ibm.ws.wim.*=all:com.ibm.websphere.wim.*=all:com.ibm.ws.wsspi.wim.*=all

as per the Technote.

Still, all's that ends well.

No comments:

Post a Comment