Oracle E-Business setting "disableInitializeSession": false causing errors

[mikenawara]

Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.

Please consider addressing the following when creating your topic:

• What have you tried? Provisioning\disabling accounts work just fine when “disableInitializeSession”: is set to true but shows as “anonymous” for audits. After testing out the Additional settings Audit Username for Oracle EBS source and setting this to false per SailPoint’s recommendations it is now failing.

• What errors did you face (share screenshots)?

• Share the details of your efforts (code / search query, workflow json etc.)?
• 
• What is the result you are getting and what were you expecting? We are getting errors so no provisoning\deporvisioning or entitlement changes are happening. What we expect is for all of this to happen and for the additional feature for assigning a service account for auditing to show as the account making the changes.

[raeannehinkens]

I’m a DBA assisting Mike with this issue. We noticed that Sailpoint’s documentation does not say to assign any EBS responsibilities to the FND_USER account (ex. SRVC.SAILPOINT below). How does this account then get permissions to modify EBS users instead of the ANONYMOUS user that it does without the Audit User Name setting in Sailpoint? We tried to assign System Administrator to the EBS account, but that did not fix the FND_USER_PKG error above. Sailpoint Document Link: Additional Settings

We think there might be some missing setups to this account since it should not be trying to use the APPS.FND_USER_PKG (seeded from oracle), it should be trying to use the custom Sailpoint synonym’s that we created (SP_FND_USER_PKG).

Also for reference, here is the database account that we’ve been using to provision users: SRVC_SPOINT. This is the user that exists in the dba_users table in our Oracle Database (different than the EBS user above).

Wondering if this is a bug, thanks!

[raeannehinkens]

Hello, after further testing, it appears that the documentation could be incorrect or should be updated in the grants section for INVOKER vs DEFINER rights. We have to use INVOKER rights based on our EBS configuration using R12.2.12. Every error we get when trying to use the Audit User Name to replace the ANONYMOUS user in LAST_UPDATED_BY the FND_USER table during provisioning comes from the database account trying to use Seeded permissions instead of Custom permissions.

The Required Permissions document https://documentation.sailpoint.com/connectors/oracle/ebusiness_suite/help/integrating_oracle_ebs/required_permissions.html has us check permissions here:

And our Permissions in the database are INVOKER, so we had to create synonyms for the seeded packages created by SRVC_SPOINT user.

Here is our DDL for the SRVC_SPOINT database user:

CREATE USER “SRVC_SPOINT” IDENTIFIED BY “PASSWORD” TEMPORARY TABLESPACE “TEMP”;

ALTER USER “SRVC_SPOINT” ENABLE EDITIONS FOR VIEW, SYNONYM, PROCEDURE, FUNCTION, PACKAGE,TRIGGER, TYPE, LIBRARY;

GRANT CREATE SESSION TO “SRVC_SPOINT”;

GRANT SELECT ANY TABLE TO “SRVC_SPOINT”;

GRANT CREATE SYNONYM TO “SRVC_SPOINT”;

GRANT CREATE PUBLIC SYNONYM TO “SRVC_SPOINT”;

GRANT SELECT ON “SYS”.“DUAL” TO “SRVC_SPOINT”;

GRANT SELECT ON “SYS”.“DBA_USERS” TO “SRVC_SPOINT”;

GRANT SELECT ON “AR”.“HZ_PARTIES” TO “SRVC_SPOINT”;

GRANT SELECT ON “AR”.“HZ_CUST_ACCOUNTS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_LOCAL_ROLES” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_LOCAL_ROLES_TL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_APPLICATION” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_RESPONSIBILITY_TL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_RESPONSIBILITY” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_APPLICATION_TL” TO “SRVC_SPOINT”;

GRANT SELECT ON “SYS”.“DBA_USERS” TO “SRVC_SPOINT”;

GRANT SELECT ON “HR”.“PER_ALL_PEOPLE_F” TO “SRVC_SPOINT”;

GRANT SELECT ON “HR”.“PER_PERIODS_OF_SERVICE” TO “SRVC_SPOINT”;

GRANT SELECT ON “HR”.“PER_PERIODS_OF_PLACEMENT” TO “SRVC_SPOINT”;

GRANT SELECT ON “HR”.“PER_ALL_PEOPLE_F#” TO “SRVC_SPOINT”;

GRANT SELECT ON “HR”.“PER_PERIODS_OF_PLACEMENT#” TO “SRVC_SPOINT”;

GRANT SELECT ON “HR”.“PER_PERIODS_OF_SERVICE#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_PRODUCT_GROUPS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUPS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUP_UNITS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_USER” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_LOCAL_ROLES” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_LOCAL_USER_ROLES” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_ROLE_HIERARCHIES” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_APPLICATION” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_RESPONSIBILITY” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_REQUEST_GROUP_UNITS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_REQUEST_GROUPS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_MENU_ENTRIES” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_MENUS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_APPLICATION_TL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_FORM_FUNCTIONS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_APPLICATION#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_APPLICATION_TL#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUPS#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_DATA_GROUP_UNITS#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_FORM_FUNCTIONS#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_MENUS#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_MENU_ENTRIES#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_PRODUCT_GROUPS#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_REQUEST_GROUPS#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_REQUEST_GROUP_UNITS#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_RESPONSIBILITY#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND_USER#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_LOCAL_ROLES#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_LOCAL_USER_ROLES#” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF_ROLE_HIERARCHIES#” TO “SRVC_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP_FND_GLOBAL” TO “SRVC_SPOINT”; --this is the grant that it should be using, not APPS.FND_GLOBAL

GRANT EXECUTE ON “APPS”.“SP_FND_RESPONSIBILITY_PKG” TO “SRVC_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP_FND_USER_PKG” TO “SRVC_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP_FND_USER_RESP_GROUPS_API” TO “SRVC_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP_FND_WEB_SEC” TO “SRVC_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP_WF_LOCAL_SYNCH” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“AR_CUSTOMERS” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“FND_APPLICATION_VL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“FND_FORM_FUNCTIONS_VL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“FND_MENUS_VL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“FND_MENU_ENTRIES_VL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“FND_RESPONSIBILITY_VL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“FND_USER_RESP_GROUPS_ALL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“FND_USER_RESP_GROUPS_DIRECT” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“WF_ALL_ROLES_VL” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“WF_ROLES” TO “SRVC_SPOINT”;

GRANT SELECT ON “APPS”.“WF_USER_ROLES” TO “SRVC_SPOINT”;

We get the following error when logged in as SRVC_SPOINT user in SQL Developer when trying to run the test PL/SQL given, since the documentation says to use the SP_FND_GLOBAL synonym:

USER is “SRVC_SPOINT”

FND_GLOBAL.APPS_INITIALIZE(

*

ERROR at line 2:

ORA-06550: line 2, column 3:

PLS-00904: insufficient privilege to access object APPS.FND_GLOBAL

ORA-06550: line 2, column 3:

PL/SQL: Statement ignored

https://docs.oracle.com/error-help/db/ora-06550/

More Details :

https://docs.oracle.com/error-help/db/ora-06550/

https://docs.oracle.com/error-help/db/pls-00904/

For reference, here is the EBS user (fnd_user) that we created and also granted System Administrator to (which would not be allowed per auditing in our PROD EBS environment): https://documentation.sailpoint.com/connectors/oracle/ebusiness_suite/help/integrating_oracle_ebs/additional_settings.html

Can someone please confirm if using the Audit User Name option in Sailpoint works with INVOKER rights in Oracle EBS R12.2.12 and Oracle DB 19c?

Thanks!

[raeannehinkens]

anyone else had thoughts on this? support seems to think it’s permissions, but everything exactly lines up with the INVOKER permissions on the document linked above. thanks!

[raeannehinkens]

still no luck on this, not sure if anyone has successfully gotten this to work