Thanks for looking into this! much appreciated…From what I understand we use INVOKER and not DEFINER. for INVOKER we’re supposed to use the custom one that SP had us create with the .sql files (SP_FND_USER_PKG)
Hello! I’m a DBA working with Mike on this issue, did something change recently with the invoker vs. definer rights? I re-ran all the grants and packages in the Required Permissions link but we are still getting an error during provisioning with Sailpoint wanting to use the seeded Oracle packages/synonyms for FND_USER_PKG instead of SP_FND_USER_PKG.
We had this working a few months ago but had to stall this project due to others taking priority.
Just wondering if something had changed on the sailpoint side in the last few months. We are using Oracle 19c (19.25.0.0) and EBS 12.2.12.
Thanks everyone who’s looked at this so far!
Hello! I just confirmed that all of our INVOKER settings were good using the validation excel sheets from the provided link, but can confirm that that did not fix our issue. We even created a new test account to be sure (name is ***** for privacy) we had everything correct with the DDL below. We are still getting the following error:
["[ ConnectorException ] \n [ Error details ] Error occurred during Create operation. Please check the logs. Error: ORA-06550: line 1, column 7:\nPLS-00904: insufficient privilege to access object APPS.FND_USER_PKG\nORA-06550: line 1, column 7:\nPL/SQL: Statement ignored\n\n[https://docs.oracle.com/error-help/db/ora-06550/“,”[](https://docs.oracle.com/error-help/db/ora-06550/“,”[) ConnectorException ] \n [ Error details ] Error occurred during Create operation. Please check the logs. Error: ORA-06550: line 1, column 7:\nPLS-00904: insufficient privilege to access object APPS.FND_USER_PKG\nORA-06550: line 1, column 7:\nPL/SQL: Statement ignored
New test user DDL:
CREATE USER “" PROFILE “DEFAULT” IDENTIFIED BY "" DEFAULT TABLESPACE “SYSTEM” TEMPORARY TABLESPACE “TEMP” ACCOUNT UNLOCK
GRANT CREATE PUBLIC SYNONYM TO ""
GRANT CREATE SESSION TO ""
GRANT CREATE SYNONYM TO ""
GRANT SELECT ANY TABLE TO ""
GRANT SELECT ON “APPLSYS”.“FND_APPLICATION” TO ""
GRANT SELECT ON “APPLSYS”.“FND_APPLICATION#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_APPLICATION_TL” TO ""
GRANT SELECT ON “APPLSYS”.“FND_APPLICATION_TL#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUPS” TO ""
GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUPS#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUP_UNITS” TO ""
GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUP_UNITS#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_FORM_FUNCTIONS” TO ""
GRANT SELECT ON “APPLSYS”.“FND_FORM_FUNCTIONS#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_MENUS” TO ""
GRANT SELECT ON “APPLSYS”.“FND_MENUS#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_MENU_ENTRIES” TO ""
GRANT SELECT ON “APPLSYS”.“FND_MENU_ENTRIES#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_PRODUCT_GROUPS” TO ""
GRANT SELECT ON “APPLSYS”.“FND_PRODUCT_GROUPS#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_REQUEST_GROUP_UNITS” TO ""
GRANT SELECT ON “APPLSYS”.“FND_REQUEST_GROUP_UNITS#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_RESPONSIBILITY” TO ""
GRANT SELECT ON “APPLSYS”.“FND_RESPONSIBILITY#” TO ""
GRANT SELECT ON “APPLSYS”.“FND_USER” TO ""
GRANT SELECT ON “APPLSYS”.“FND_USER#” TO ""
GRANT SELECT ON “APPLSYS”.“WF_LOCAL_ROLES” TO ""
GRANT SELECT ON “APPLSYS”.“WF_LOCAL_ROLES#” TO ""
GRANT SELECT ON “APPLSYS”.“WF_LOCAL_USER_ROLES” TO ""
GRANT SELECT ON “APPLSYS”.“WF_LOCAL_USER_ROLES#” TO ""
GRANT SELECT ON “APPLSYS”.“WF_ROLE_HIERARCHIES” TO ""
GRANT SELECT ON “APPLSYS”.“WF_ROLE_HIERARCHIES#” TO ""
GRANT SELECT ON “APPS”.“AR_CUSTOMERS” TO ""
GRANT SELECT ON “APPS”.“FND_APPLICATION_VL” TO ""
GRANT SELECT ON “APPS”.“FND_FORM_FUNCTIONS_VL” TO ""
GRANT SELECT ON “APPS”.“FND_MENUS_VL” TO ""
GRANT SELECT ON “APPS”.“FND_MENU_ENTRIES_VL” TO ""
GRANT SELECT ON “APPS”.“FND_RESPONSIBILITY_VL” TO ""
GRANT SELECT ON “APPS”.“FND_USER_RESP_GROUPS_ALL” TO ""
GRANT SELECT ON “APPS”.“FND_USER_RESP_GROUPS_DIRECT” TO ""
GRANT EXECUTE ON “APPS”.“SP_FND_GLOBAL” TO ""
GRANT EXECUTE ON “APPS”.“SP_FND_RESPONSIBILITY_PKG” TO ""
GRANT EXECUTE ON “APPS”.“SP_FND_USER_PKG” TO ""
GRANT EXECUTE ON “APPS”.“SP_FND_USER_RESP_GROUPS_API” TO ""
GRANT EXECUTE ON “APPS”.“SP_FND_WEB_SEC” TO ""
GRANT EXECUTE ON “APPS”.“SP_WF_LOCAL_SYNCH” TO ""
GRANT SELECT ON “APPS”.“WF_ALL_ROLES_VL” TO ""
GRANT SELECT ON “APPS”.“WF_ROLES” TO ""
GRANT SELECT ON “HR”.“PER_ALL_PEOPLE_F” TO ""
GRANT SELECT ON “HR”.“PER_ALL_PEOPLE_F#” TO ""
GRANT SELECT ON “HR”.“PER_PERIODS_OF_PLACEMENT” TO ""
GRANT SELECT ON “HR”.“PER_PERIODS_OF_PLACEMENT#” TO ""
GRANT SELECT ON “HR”.“PER_PERIODS_OF_SERVICE” TO ""
GRANT SELECT ON “HR”.“PER_PERIODS_OF_SERVICE#” TO ""
GRANT SELECT ON “SYS”.“DBA_USERS” TO ""
GRANT SELECT ON “SYS”.“DUAL” TO "***”
Thoughts on this? We are still confused on why it’s trying to use DEFINER (seeded) rights instead of INVOKER (SP_% custom package) rights. Thanks!
Hi RaeAnne,
We are also seeing the issue and the start date for that is 27th February for us. What I saw is that Sailpoint has changed the way connector used to function. When the connector tries to create the account it was altering the session and making connection using APPS user. We had raised a ticket with Sailpoint and they had enabled a flag last November to disable creating of the APPS session and recently have pushed a change to the Connector where they have given a connector attribute to disable this feature at source level. The attribute is “disableInitializeSession” but this seems to be not working. We have again raised a Sailpoint ticket and i would recommend you also do the same as it has nothing to do with permission. if you enable the logs at db level you will understand how sailpoint is trying to alter session using apps user.
Is that attribute set at the source Oracle DB level? Or is it set somewhere within the SP website? We noticed that the Required Permissions website was updated recently with that Troubleshooting error on Feb 27 and again on March 12. I was not sure where to set that in the Oracle DB. We’ll look into creating a SP ticket also.
Thanks!
Hi RaeAnne,
It is set inside the connectorAttributes in Sailpoint. When you get your source in IdentityNow using REST API you can see that attribute set. This is nothing to do with Oracle DB. Tell your Sailpoint developer her should help you get the required details from the source.
Thank you for enabling access and providing the successful provisioning. It is already bearing fruit!Our engineers identified the error and managed to reproduce it in our labs. They have created a bug report in high priority.I will continue keeping you informed of any progress.
