Wednesday Jun 06, 2012

OBIEE 11.1.1.5 or above: Admin Server unavailability is not impacting OBIEE tasks

Applies To: 11.1.1.5, 11.1.1.6

Admin Server unavailability is not impacting OBIEE tasks. By setting virtualize tag to true (in EM) to manage multiple LDAP providers, it is enabling failover and HA on authentication and authorization inside OBIEE. Following are the test cases used for testing impact on OBIEE, if Admin Server is not available:

 

a. Test 1: Admin Server crashes and impact on OBIEE

Scenario: All OBIEE components are up and running.

b. Test 2: Admin Server had not been started and impact on OBIEE.

Scenario: OBIEE Server bi_server1 is started, but Admin Server isn’t

For more details on each of the above test, click here to download the Test Results

Links to Official documentations below:  

http://docs.oracle.com/cd/E23943_01/bi.1111/e10543/privileges.htm#BIESC6077

http://docs.oracle.com/cd/E23943_01/bi.1111/e10543/privileges.htm#BABHFFEI

http://docs.oracle.com/cd/E23943_01/bi.1111/e10543/authentication.htm#BIESC6075  


Wednesday Apr 18, 2012

OBIEE 11.1.1 - Web catalog upgrade from 10g to 11g corrupted some user permissions

Web catalog upgrade from 10G to 11.1.1.3 or 11.1.1.5 or 11.1.1.6 corrupted some user permissions, this may cause slow user login time and also slowness in accessing the dashboard.

Resolution:

  • Cleanup Web catalog via instanceconfig.xml using the steps documented in "Validating the Catalog" in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
  • Runcat cmd line commands to cleanup all permissions that appears to be Invalid.

Tip: It is recommended to run all above tasks each & every time content is delivered from a development environment into the production environment (e.g. weekly), as part of the OBIEE administrator's regular backup & maintenance of the catalog.

[Read More]

Wednesday Feb 29, 2012

OBIEE 11.1.1 - How to use OBIEE Impersonate parameter for quick checks

If you quickly need to check a user permission issue, you can use the Impersonate parameter on the url. However, you have to issue two requests to get a report, you cannot do this in a single url:

Impersonation is "atomic" with authentication. It's not a "request" level parameter. You have to authenticate in "impersonated mode":

http://server:7001/analytics/saw.dll?Logon&NQUser=YourAdministrator&NQPassword=Admin123&Impersonate=TheUserToImpersonate

Then

http://server:7001/analytics/saw.dll?Go&Path=%2fshared%2ftests%2ftest1&Options=rmf&Action=print

Also, you need to make sure that the user "YourAdministrator" has the right permissions in 11g: oracle.bi.server.impersonateUser and possibly oracle.bi.server.queryUserPopulation


Wednesday Feb 15, 2012

OBIEE 11.1.1 - Users are able to log in to the WebLogic Admin console, but not BI

Check if users are able to log in to WebLogic Admin console assuming you can still log in to the WebLogic Admin Console (and if you can start WebLogic, you should be able to login to the Admin Console using the credentials you used to start the server) you can then assign one of the LDAP users the WebLogic Global Admin Role and see if they are able to log in to the WebLogic Admin Console (http://biserver:7001/console). If they are able to log in to the WebLogic Admin console, but not BI, then the LDAP authenticator config is correct, but it may not be accessible to BI.

There are few things to check in this instance:
1) The Identity Store that contains your users may not be being exposed as an Identity Store to OPSS. The primary identity store must be set as the first one in the list of authenticators (note that this restriction is lifted from BI 11.1.1.5 using the virtualize=true configuration) – BI uses the User Role API from OPSS which will only pick up the first identity store from the list of authenticators when looking up users’ GUID, Profile Information, Roles etc. This is a prime cause of the scenario whereby a user can log into WebLogic Admin Console (hence demonstrating that the authentication part of logon is succeeding), but cannot log in to BI (because the identity store containing the user is not first in the list). Where more than one Authenticator is configured, in the general case the control flags should all be set to SUFFICIENT. This will have the effect of each one being tried in turn until authentication succeeds. If authentication is successful, no further authenticators will be tried; if none of the authenticators are able to authenticate the supplied credentials, the overall authentication process will fail.

N.B. on install, the DefaultAuthenticator is set to REQUIRED; if another authenticator is configured, the DefaultAuthenticator, if it is to be retained, must be set to SUFFICIENT or OPTIONAL instead. SUFFICIENT is the recommended setting, for the reasons outlined above.

2) Your users are authenticating correctly to LDAP, but there is a problem with the BI System User which prevents the BI Security Service from authenticating users. N.B. if you temporarily assign the WebLogic Global Admin role to a user to test this scenario, please remember to remove this as soon as you have completed testing or else you may find you’ve given one (or many, if you specify the role condition by group name match) of your users a lot more power than you intended them to have.

3) Clean up all the users/groups security in RPD that may already exist from upgraded 10g RPD (delete user from rpd if present) and perform GUID refresh again i.e. https://blogs.oracle.com/pa/entry/regenerating_user_guids


Tuesday Feb 14, 2012

OBIEE 11.1.1 - Migrating Security – Policy Store

Goto .../Oracle_BI1/common/bin/ and run ./wlst.sh :

wls:/offline> migrateSecurityStore(type="appPolicies", srcApp="obi", configFile="/scratch/aawan/SecMigration/jps-config.xml", src="sourceFileStore", dst="targetFileStore", overWrite="false")

Reference Note: For detailed syntax and examples, see "migrateSecurityStore" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. http://www.oracle.com/pls/fa102/to_URL?remark=ranked&urlname=http:%2F%2Fdocs.oracle.com%2Fcd%2FE25178_01%2Fweb.1111%2Fe13813%2Fcustom_infra_security.htm%23WLSTC1426

Before running the above migrateSecurityStore command you must specify details relating to your source policy store in your target's jps-config.xml file.

1. Backup your target's jps-config.xml file located at DOMAIN_HOME/config/fmwconfig/jps-config.xml.

2. Add source and target information to the target's jps-config.xml:

a. Add the following section (above the closing </serviceInstances> tag) to point to the source policy store:
<serviceInstance name="srcpolicystore.xml" provider="policystore.xml.provider" location="/MW_HOME/user_projects/domains/bifoundation_domain/config/fmwconfig/system-jazn-data.xml">
   <description>File Based Policy Store Service Instance</description></serviceInstance>

b.Update the policy store reference to point to the value specified in step a. Add the following entries above the closing </jpsContexts> tag:
<jpsContext name="targetFileStore">
     <serviceInstanceRef ref="policystore.xml"/>
</jpsContext>
<jpsContext name="sourceFileStore">
     <serviceInstanceRef ref="srcpolicystore.xml"/>
</jpsContext>

Output similar to the following displays and includes a WARNING that you can ignore:

WLS ManagedService is not up running. Fall back to use system properties for configuration.
oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstPolicy <init>
WARNING: No identity store associate with policy store found

Saturday Jan 28, 2012

OBIEE 11.1.1 - Important Security Considerations (SSL) if using external LoadBalancer

In OBIEE enterprise topology, make sure the external load balancer used should be able to terminate SSL requests at the load balancer and forward traffic to the back-end real servers using the equivalent non-SSL protocol (for example, HTTPS to HTTP).

For security purposes, and because the load balancer terminates SSL requests (Oracle HTTP Server routes the requests as non-SSL to WebLogic Server), after SSL is configured for the load balancer, turn on the WebLogic Plugin Enabled flag for the domain. To do this, follow these steps:

1. Log in to the Administration Console.
2. Click the domain name in the navigation tree on the left.
3. Click the Web Applications tab.
4. In the Change Center, click Lock & Edit.
5. Select WebLogic Plugin Enabled.
6. Click Save, then click Activate Changes.
7. Restart the Administration Server and Managed Server.

Tip: WebLogic Plugin Enabled: Specifies whether or not the proprietary WL-Proxy-Client-IP header should be honored. (This is needed only when WebLogic plugins are configured.)

In additon to above, make sure Oracle HTTP Server (OHS) to add the following SSL directives in each <location> section to the ORACLE_BASE/admin/instance_name/config/OHS/component_name/mod_wl_ohs.conf file:

WLProxySSL ON

WLProxySSLPassThrough ON

Tips: Set WLProxySSL parameter to ON to maintain SSL communication between the plug-in and WebLogic Server when the following conditions exist:

  • An HTTP client request specifies the HTTPS protocol
  • The request is passed through one or more proxy servers (including the WebLogic Server proxy plug-ins)
  • The connection between the plug-in and WebLogic Server uses the HTTP protocol

When WLProxySSL is set to ON, the location header returned to the client from WebLogic Server specifies the HTTPS protocol.


Friday Oct 21, 2011

OBIEE 11.1.1 - Regenerating User GUIDs in Cluster Environment

In OBIEE distributed environment in order to regenerate user GUIDs, perform the following steps on OBIEE Server 1 and OBIEE Server 2. Important Note that GUID regeneration must occur with only one node operating at a time.

1. Stop Oracle BI Server and Presentation Services on all nodes except where you are regenerating the user GUIDs. For example:
cd ORACLE_BASE/admin/instancen/bin
./opmnctl stopproc ias-component=coreapplication_obips1
./opmnctl stopproc ias-component=coreapplicaiton_obis1


2. Update the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS parameter in NQSConfig.INI file:

a. Open NQSConfig.INI for editing at:
ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn

b. Locate the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS parameter and set it to YES, as follows:
FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES;

c. Save and close the file.

3. Update the Catalog element in instanceconfig.xml:

a. Open instanceconfig.xml for editing at:
ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/coreapplication_obipsn

b. Locate the Catalog element and update it as follows:
<Catalog>
<UpgradeAndExit>false</UpgradeAndExit>
<UpdateAccountGUIDs>UpdateAndExit</UpdateAccountGUIDs>
</Catalog>

c. Save and close the file.

4. Restart the Oracle BI Server and Presentation Services using opmnctl:
cd ORACLE_BASE/admin/instancen/bin
./opmnctl stopproc ias-component=coreapplication_obips1
./opmnctl stopproc ias-component=coreapplication_obis1
./opmnctl startproc ias-component=coreapplication_obis1

After you confirm that the Oracle BI Server is running, then start Presentation Services:
./opmnctl startproc ias-component=coreapplication_obips1
Wait for coreapplication_obips1 to be in status first "Alive" then "Down" after a while.
Once coreapplication_obips1 had executed GUIDs update, it is exiting.

5. Set the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS parameter in NQSConfig.INI file back to NO. Important: You must perform this step to ensure that your system is secure.

6. Update the Catalog element in instanceconfig.xml to remove the UpdateAccount GUIDs entry.

7. Restart the Oracle Business Intelligence system components using opmnctl:

cd ORACLE_BASE/admin/instancen/bin
./opmnctl stopall
./opmnctl startall

Doc Reference: http://docs.oracle.com/cd/E23943_01/bi.1111/e10543/privileges.htm#BIESC721


About

A blog focused on Tips & Tricks about Oracle Business Intelligence (OBI), Oracle Exalytics and Oracle Enterprise Performance Management (EPM) products.
[Blog Admin: ahmed awan]

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today