Error when submitting GRC request

[Former Member]

Hello IDM Gurus, <br>

We were running into an issue when trying to set up our IDM - GRC integration; when submitting a request to GRC via the AC Validation task the "Submit AC Request" task always encounters an error, but in spite of which the request still gets created on the GRC end; weirdly enough, 2 requests get created each time:<br>

putNextEntry failed storingcn=TESTUSER,ou=submitrequest,o=grc

Exception from Add operation:javax.naming.CommunicationException: [LDAP: error code 2 - (GRC Submit Request:2:oracle.jdbc.driver.OracleDriver)]; remaining name 'cn=TESTUSER,ou=submitrequest,o=grc'

<br>

On the GRC end we noticed that we are getting the following error:<br>

2011-12-05 20:21:32,046 [SAPEngine_Application_Thread[impl:3]_30] ERROR com.sap.security.api.NoSuchUserAccountException: Cannot find user when logonid is null!
com.virsa.ae.service.umi.UMIException: com.sap.security.api.NoSuchUserAccountException: Cannot find user when logonid is null!
	at com.virsa.ae.service.umi.ume.UMESearchUser.getUserById(UMESearchUser.java:304)
	at com.virsa.ae.search.bo.SearchUserBO.getUserById(SearchUserBO.java:198)
	at com.virsa.ae.ejbutil.submitrequest.RequestSubmissionBean.submitRequest(RequestSubmissionBean.java:564)
	at com.virsa.ae.ejb.submitrequest.SubmitRequestEJBBean.getSubmitRequest(SubmitRequestEJBBean.java:45)
	at com.virsa.ae.ejb.submitrequest.SubmitRequestEJBObjectImpl0_0.getSubmitRequest(SubmitRequestEJBObjectImpl0_0.java:119)

2011-12-05 20:21:32,064 [SAPEngine_Application_Thread[impl:3]_30] ERROR com.virsa.ae.core.BOException:  Error in Searching Users... 
com.virsa.ae.core.BOException:  Error in Searching Users... 
	at com.virsa.ae.search.bo.SearchUserBO.getUserById(SearchUserBO.java:201)
	at com.virsa.ae.ejbutil.submitrequest.RequestSubmissionBean.submitRequest(RequestSubmissionBean.java:564)
	at com.virsa.ae.ejb.submitrequest.SubmitRequestEJBBean.getSubmitRequest(SubmitRequestEJBBean.java:45)
	at com.virsa.ae.ejb.submitrequest.SubmitRequestEJBObjectImpl0_0.getSubmitRequest(SubmitRequestEJBObjectImpl0_0.java:119)

As a result of this error GRC AC Submit request never completes successfully and so the polling task never starts, instead immediately the pending values are skipped and removed from the user in question.<br>

<br>

What are we supposed to set the User data source as within CUP? Is there something else we should be doing to fix this?<br>

<br>

Would greatly appreciate your help with trying to fix this!<br>

<br>

Thanks a lot in advance!<br>

<br>

Best regards,

Sandeep

Edited by: Sandeep Jayendran on Dec 6, 2011 11:22 AM

[former_member2987 · Accepted solution]

Sandeep,

Check your VDS configuration. There's something going on in the DN mapping is my guess based on the LDAP error code 2. You might also want to check the VDS Log as well.

Matt

[Former Member · Accepted solution]

Sandeep, also have a look at the Assignment Grouping you have defined on your repository that influences the number of CUP requests that are created.

[Former Member · Accepted solution]

Hi Matt / Michael,

Thanks for your quick responses! Sorry for the delay in responding; I was travelling.

Matt,

as for the VDS settings, we never really changed anything from the default mappings, so I would be curious as to why an LDAP error might be generated with just the default settings; as for the logs, for some strange reason no logs are getting generated; operational / audit, nothing; hmmmm, that's a different issue I guess; any ideas why?

Michael,

Will have a look at the assignment grouping for the CUP requests and get back to you; as for now I don't believe we have changed the default settings with the assignment grouping either.

We were trying to just post requests as part of an internal PoC and then continue from there on with development; so we haven't really fiddled around with any of the default settings.

Thanks and Best regards,

Sandeep

Edited by: Sandeep Jayendran on Dec 12, 2011 1:04 PM

[former_member2987 · Accepted solution]

Sandeep,

Look at the error, it's having a bad LDAP lookup and a malformed CN. That's what's my guess and that can only come from VDS. It is possible that you're getting poor data in which is causing the error however.

No logging? What version of VDS are you using? There was an older version of VDS that did not have logging as a default option, it was supposed to go through NetWeaver somehow. Let me know...

Matt

[Former Member · Accepted solution]

Thanks Matt!

True; the error could only possibly stem from VDS.

I'm using VDS Version 7.10.SP05.Patch0-134596 - Rev: 134596

I changed the operational log level to ALL so I'm surprised that I'm still not seeing any logging.

Cheers,

Sandeep

P.S. The odd thing as I mentioned in my original post was that the requests are still getting created in CUP; two in fact, for each request submission; so is it possible for there to be a VDS error even though it seems like data is still reaching CUP through VDS?

Edited by: Sandeep Jayendran on Dec 12, 2011 6:37 PM

[Former Member · Accepted solution]

Hi Michael,

just wanted to clarify though; isn't it true that Assignment Grouping is only valid for distributed provisioning scenarios? and NOT central provisioning?

Cheers,

Sandeep

[Former Member · Accepted solution]

We had the same issue in 7.2 though.. check if you have sqljdbc.jar file mentioned in the server options in VDS...

Let me know if it works out..

Cheers !!

Zaheer

[former_member2987 · Accepted solution]

Sandeep,

Check out this article...

http://sgciam.wordpress.com/2009/03/17/vds-logging/

Bring back some memories?

M

[Former Member · Accepted solution]

Hi Matt / Zaheer,

Thanks a lot for your replies!

Zaheer, We are actually using oracle, so I have now ensured that the ojdbc jar file is added to the classpath within VDS.

Matt, Thanks for the article! I managed to get the operation and audit log generated to external trace files.

I was now going through the operation logs and see that the webservice actually returns an operation result of SUCCESS also quoting that "Finished add operation"; which is why the request does in fact get created in CUP but a couple of log entries later after the webservice returns the request number I encounter the following error within VDS:

Exception in GRC WS API call:oracle.jdbc.driver.OracleDriver

For some strange reason, even though I have added the ojdbc driver to the classpath the same error still seems to be occurring. What could possibly be the root issue? what about the web services are not configured properly? What else is left to be configured within VDS? Where else should I add the ojdbc driver?

I would greatly appreciate any suggestions / thoughts / ideas.

Cheers!

Sandeep

Edited by: Sandeep Jayendran on Dec 13, 2011 7:25 PM

[Former Member · Accepted solution]

Hello Gents,

I ran another test and had a look at the VDS Operation log to get more detail around the error; here's an excerpt from the operation log:

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
End element SOAP-ENV:Envelope

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
org.apache.axis.i18n.resource::handleGetObject(empty00)

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
NSPop (empty)

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
org.apache.axis.i18n.resource::handleGetObject(setMsgForm)

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Setting current message form to: FORM_OPTIMIZED (currentMessage is now org.apache.axis.utils.ByteArray)

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Exit: SOAPPart::saveChanges(): org.apache.axis.utils.ByteArray@7ecd78

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Operations result is:SUCCESS

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Additional message = msgcode=000;msgdescription=Request Created;msgtype=SUCCESS;requestno=92

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Requst number: 92

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Exception in GRC WS API call:oracle.jdbc.driver.OracleDriver

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
*** Fetch result code ***

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Info  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Operation result: 2

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Warning  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Exception: (GRC Submit Request:2:oracle.jdbc.driver.OracleDriver)

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Returning: opResult:2,info: ((GRC Submit Request:2:oracle.jdbc.driver.OracleDriver))

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Finished add operation

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
Sending operation result

Time: Tue Dec 13 18:01:43 GMT 2011  Level: All  Thread: Thread[3,3,LDAP 
Sessions:main_listener_4389] Logger: Plain Message:
Sending response to socket: 63621

Time: Tue Dec 13 18:01:43 GMT 2011  Level: Debug  Thread: Thread[3,3,LDAP Sessions:main_listener_4389] Logger: Plain Message:
LDAP Session continues ...

It's the strangest thing, because it seems to send the request across successfully which is how the request is getting created in CUP but after it succeeds it encounters the exception with the GRC WebService call from the API; any ideas why this is happening? how can we possibly fix this?

Would greatly appreciate any insight / advice on this!

Cheers!

Sandeep

[Former Member · Accepted solution]

Hello Gents,

We finally got this fixed; the issue happened to be that the folder containing the OJDBC driver didn't have sufficient permissions for access by VDS; it finally worked and came back to IDM successfully and the privilege was automatically approved, thereby successfully testing what we needed.

Thanks a lot for all your help!

Best regards,

Sandeep