LDAPBIND Testing

I'm trying to test LDAPBIND to a test AD in preparation for an AD upgrade. Has anyone seen the following errors in security_authen.log:

Error encountered while getting users DN. Please see logs for details.

LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580

Could Not Bind With privileged identity.

Failed to get DN for user.

LDAP data code 52e is "invalid credentials" but I can log into the test LDAP with both the LDAPBIND account and the user account I am testing with. What other log is it referring to for details? Are there any other accounts required in AD other than the LDAPBIND account and the user account I am testing with? I would appreciate any input. Thanks.

Find more posts tagged with

Comments

Legacy Contributor

From personal experience, I have found that LDAPBIND is very touchy. If run casually or "just to see what it does" it can go out of whack and totally blow out authentication. For you, it may not be set up right and is probably not binding when running in "automatic" mode (my terminology, meaning, how it usually runs without manual login). My suggestion, which should be confirmed by a Lawson Security Administration expert which I am not, is to run the LDAPBIND process properly, to re-bind to your authentication source(s). I looked for that error in our logs, and found it, but only for dates preceeding the final 10x installation, which was when a correct LDAPBIND was performed.

Legacy Contributor

Thanks for your response. We have run LDAPBIND several times and are running it properly as far as I know. It appears to be successful. I'm not sure what you mean by running it casually. Is there a non-casual method?

Legacy Contributor

Hi, One thing to remember (which might be a life saver for you): Each time you run an ldapbind, a backup file of services/identities is created. This allows you to reload that file in case of ldapbind failure. So, if you've done the ldapbind 3 times, there would be 3 date/time files. Lenny

Legacy Contributor

Yes, there is non-casual way. Do it right. You know what it does, at every prompt, and you know what to enter, at every prompt. No mistakes at all.

The casual way, my first encounter with LDAPBIND, was very painful. I ran it "just to see what it would do", on a backup to the test system. It didn't go well. First one, then two, then three systems went down. Yes, that last system was, you guessed it, Production. Lawson Security was munged so badly that it took a lot of intervention and some downright voodoo to rebuild it. So after that, I've always run LDAPBIND absolutely correctly: Every answer to every prompt is written down before-hand, reviewed, analyzed, and made certain of, so that there won't be a single mistaken keystroke. If it sounds like I have PTSD over this, yeah, it's kinda like that.

Legacy Contributor

When we upgraded our AD we didn't perform another LDAPBIND. We dumped the SSOP service changed the AD server that it was pointing to in the provider enty reloaded it and then stoped and started the environment and websphere. You would use ssoconfig -c to accomplish this. See this article: KB 1200499

Copyright © 2025 Infor. All rights reserved.