LDAP bind - Java.lang.IndexOutOfBoundsException

Cold beer in Minneapolis for anyone who has any ideas Lawson has walked away from this one.

Did all the smoketest run ok? Turn off all the firewall/security? Exactly "when" during the LDAPBIND process you encountered the error?

Everything is perfect as far as Lawson and all of the smoketests go. Portal functions properly which tells me the web apps are good. The only problem is actually running the ldapbind process, after all parameters are filled in and the index error is produced.
I have:
Verified the corporate directory read user successfully
Verified the search base
Verified connectivity to AD from ADAM server using corp read user
Verified firewall settings and no issue there, can read from same server on same port with different app
Verified the existince of the attribute sAMAccountName in Active Directory (have also tried user and cn which exist also).
It appears to be an issue with the code in Lawson.
I have patched the environment to the latest patchset for 9.0.1.5 as of 2/16/10

Running out of ideas????

what is your max return value for the ldap? When you do an ldap query if you are trying to bind to more than your max value, you could get an index out of bounds error

I bumped the value up to 5000 from 1000 and there is no difference. Thanks for the heads up though, totally forgot to even check the value....

wasn't sure if that was it, but from the error it sounded like a possiblity... may seem like a silly question, but have you gotten the ldap bind to work in the past?

I seem to remember getting that error if there was a corrupt identity in the LDAP container somewhere. It took some time to figure it out, and understand how to resolve it. Try doing an ssoconfig export including all services and identities.

Nope, this is the first shot. Pretty vanilla environment and corporate AD. I run the bind and it creates the ssop_bind service etc.... Once the search users password is confirmed, it runs for a min and then kicks out the stack error. If I look at the ADAM prior to actually running the bind, the service ssop_bind exists in at least one place. So, it doesn't seem to be any kind of rights thing, I've actually even replaced the ldapbind object in $GENDIR/bin with one from another identical server that is bound and the error is the same. I cant read the object so, I don't know exactly what is called to actually run the bind. I checked the ldapbind.properties file and all appears to be correct. I have also reentered and sequenced my path and libpath values. This one is nuts. Note, this is a system that was formerly 32bit 9.0.0.6 and is now 64bit 9.0.1.5. The OS is the same, we just made the ancillary application changes and upgraded to 64/9015. I'm starting to wonder if something was not "upgraded" as a part of the evolution.

Does anyone know exactly what ldapbind invokes/calls/reads?

can you post the stack dump? and the line or two before the dump... to see what last happened or tried to happen?

what kind of account are you binding with is it a userProxy or
a windows domain account?

Note on background. You only need a userProxy if your application
must make a simple LDAP bind, if the application can make a secure
(SASL) bind then you do not need userProxies you can just add access
control for the AD accounts to the ADAM data

What, specifically, would I be looking for? I have encountered bind issues if the user in ADAM was a "ghost" and was incomplete causing bind to abort. I am looking at my svc and ID file now and dont see where there are any problems? Advice?

not sure, but Java errors are sometimes related to the last thing it tried to do and they dumps out a null pointer or indexoutofbounds error... so sometimes in debugging them if you refer to the last thing or two in the stack dump that was successful will indicate where the error actually is coming from. Not always, but sometimes.

Well, got it fixed..... Turned on SSO tracing (thanks Bart) and combed the logs..... The last entry processed by the bind was a privileged identity and then the operation seemed to reverse. There were no errors, just a list of what took place. On further investigation, the identity was referencing an ID that didn't exist and that was bombing out the bind. Thanks for all of the help on this folks!!