Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Content Management (Extended ECM)
API, SDK, REST and Web Services
Internal Users not in LDAP through LAPI?
Tamer_Morsi
I'm hoping someone can help me out with this.We're in the process of moving over to LDAP authentication for our system, but are encountering an issue when it comes to logging in users that aren't in the LDAP directory. (Namely, it's not letting it happen.) Short of having to set up a second server just for that user to connect, does anyone have an idea how to do this?
Find more posts tagged with
Comments
Louis_Routhier
Could you provide the part of your code where you define your session?
Tamer_Morsi
It's pretty generic, but I'll enclose a sample.The code in question is called each time our external apps are called - it's passed a username and password, and returns the session, but seems to be failing at the point where it is trying to access the personal workspace (which to me implies it cannot log in).
Louis_Routhier
In your error catching, maybe you should try to print lls..getStatusMessage() and lls.getErrMsg() to get more detailed information.Also, have you tried to do something else than request PersonalWS?
Tamer_Morsi
I've tried the getStatusMessage() and similar methods - I get back status of 0 and blank messages. (Which, iirc, means "okay", strangely enough.)I've tried a few things, from switching to the EnterpriseWS to calling LAPI_USERS.getCurrentUserID and get the same error each time. With improved error catching, I'm getting everyone's favorite error on any of the operations I'm trying to conduct that requires a valid session:com.opentext.api.LLIllegalOperationException: get(name) not implemented for this datatypeAny thoughts?
Louis_Routhier
If you set your log level to 1, do you get trace files in your log directory?
Tamer_Morsi
I do get trace files, yes.I'm getting the following error message at the top: Thread: 1549A198 Depth: 4 Status: Value cannot be coerced to Local type R0: 2431The fourth method that I'm seeing in the trace is the AccessEnterpriseWS call where I'm seeing it bomb out. I've verified the passed-in password is correct, so I'm confused as to why this isn't working...
Louis_Routhier
Could you post your trace file? Please remove sensitive information first.
Tamer_Morsi
I figured the sensitive-info-removal went without saying.
Louis_Routhier
The problem seems to come from the CustomAdmin user record (ID=968474). If you look closely at the stack, the value for the USERDATA field is 2431 but according to 9.5.0.1 code, it is expecting an Assoc.Could you validate the value by doing a select directly on the database and maybe compare with other users (both synchronized and local if you're using any directory service).From what I see in my own DB, this field is used to stored synchronisation information but is null for local users.