The proxy act as capability of Oracle BI is still well and alive in 11g.
I came across this error recently when configuring this functionality, “Actual user’s GUID is not empty but Acting as user’s GUID is empty.”
The GUIDs have a lot to do with the way the proxy user is able to log into Presentation Services as the target user. Refreshing GUIDs can also play a role in affect the correct configuration with Proxy As.
This error however, is due to the fact that the implementation was using two different Identity Providers which apparently breaks the functionality of the Proxy As feature.
For example, I want to log into OBI Dashboards as the ‘weblogic‘ user which is housed under the default Identity Provider of the WLS LDAP system. I want to set up my proxy as table so that the ‘weblogic’ user can proxy as a target user that resides in an MS Active Directory LDAP Identity Provider that I’ve configured in WLS or that I am using via the backwards compatible 10g security method stemming from the RPD (I tested this using only the latter method). So, I’d set up my proxy table to show the combination of weblogic user to MSAD user with full privileges. The outcome of this is that when I log in with the ‘weblogic’ user, I am able to see my MSAD user in the Act As dropdown list. That is accurate because that is just a database retrieve. However, if I select the MSAD user from the list to act as that user, I will be sent to the login screen of Presentation Services and the proxy as login will fail. The error message above will be logged and can then be seed from the Diagnostics tab within the Fusion Control console.
So, ultimately you can only proxy Act As with a users stemming from the same Identity Provider.
In my opinion that is how is should work anyway. Just know that the limitation exists.
Let me know if you’ve figured out a work around or if I missed something.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
It’s 2015 and you can now establish totally respectable MS SQL DBA credibility just by mentioning you have been in the game since SQL Server version 9. You may even get the same gasps of shock from some colleagues that used to be reserved for the version 6 veterans.