Skip Headers
Oracle® Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition
11g Release 1 (11.1.1)

Part Number E10543-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

C Troubleshooting Security in Oracle Business Intelligence

This appendix describes common problems that you might encounter when using and configuring Oracle Business Intelligence security, and explains how to solve them. It contains the following sections

C.1 Resolving User Login Authentication Failure Issues

This section helps you resolve some of the most common user login authentication failure issues encountered while using Oracle Business Intelligence Enterprise Edition 11g. It is not intended to be a comprehensive list of every possible scenario, and contains the following topics:

C.1.1 Authentication Concepts

This section describes authentication concepts helps you to resolve user login authentication failure issues, and contains the following topics:

C.1.1.1 Authentication Defaults on Install

Immediately after install, Oracle Business Intelligence is configured to authenticate users against the WebLogic embedded LDAP server through the DefaultAuthenticator. Default user accounts will have been set up, including the WebLogic Admin user which uses the account credentials entered as the WebLogic administrator user during the install.

C.1.1.2 Using Oracle WebLogic Server Administration Console and Fusion Middleware Control to Configure Oracle Business Intelligence

You configure Oracle Business Intelligence using Oracle WebLogic Server Administration Console and Fusion Middleware Control. For more information about using these applications, see Section 1.6, "Using Tools to Configure Security in Oracle Business Intelligence".

You must log in to Oracle WebLogic Server Administration Console and Fusion Middleware Control with the username and password that you specified for the Administrative user during the install process, unless you have altered or removed that account or configured another account with the appropriate access (see Section C.1.1.4, "Oracle Business Intelligence Key Login User Accounts").

C.1.1.3 WebLogic Domain and Log Locations

To diagnose and resolve user login authentication issues, you must know the locations of the WebLogic domain, and log files, as follows:

Note:

This section assumes that the install used the default locations. If you specified different install locations, you must modify the paths accordingly.

  • WebLogic domain where Oracle Business Intelligence is installed

    MW_HOME/user_projects/domains/bifoundation_domain/

  • WebLogic Administration Server logs

    MW_HOME/user_projects/domains/bifoundation_domain/servers/AdminServer/logs/

  • WebLogic Managed Server logs:

    MW_HOME/user_projects/domains/bifoundation_domain/servers/bi_server1/logs/

  • BI Server logs:

    MW_HOME/INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obisn/

C.1.1.4 Oracle Business Intelligence Key Login User Accounts

This section describes the key login user accounts, and contains the following sections:

C.1.1.4.1 WebLogic Admin User Account

The WebLogic admin user account enables you to start the WebLogic Server, and to administer WebLogic Server using the Oracle WebLogic Server Administration Console and Fusion Middleware Control. The WebLogic admin account must have the WebLogic global role called Admin (this is not an Oracle Business Intelligence application role), which also enables them to add new WebLogic administrator accounts.

To add or remove users to or from the global admin role using the Oracle WebLogic Server Administration Console:

  1. Log in to Oracle WebLogic Server Administration Console as a WebLogic administrator, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  2. Select Security Realms from the left pane and click myrealm.

    The default Security Realm is named myrealm.

  3. Select Roles and Policies from the tabs along the top.

  4. In the list of roles, click on the plus sign to expand Global Roles, then Roles, then click the View Role Conditions link for the Admin global role.

  5. Check to ensure that the specified conditions match your user, either directly, or through a group they belong to.

    For example, condition may be User=myadminaccount or Group=Administrators.

  6. If you have made any changes, click Save.

  7. In the Change Center, click Activate Changes.

C.1.1.4.2 BI System User Account

The BI System User account enables internal authentication between different Oracle BI components, and must not be used as a normal user account (for example, to log in with or to use the application). Oracle recommends that if you change from using the default user created on install, you must assign a special account for this purpose, and not use an account which is used by an actual user of the system.

An account named BISystemUser is created by default in the WebLogic embedded LDAP store during install, to be used as the BI System User account. The credentials of this account (the password is created at random) are stored in the credential store under the system.user key in the oracle.bi.system map. If you change the account used for the BI System user, or remove the Default Authenticator account, you cannot authenticate against the WebLogic embedded LDAP, and you must create a new BI System user account. For more information, see Section 3.7, "Configuring a New Trusted User (BISystemUser)".

Note:

The BI System User account (BISystemUser by default) must be associated with the BISystem application role and the WebLogic global role named Admin. If you make any changes to the BI System User account, you must restart the Administration Server, Managed Servers, and Oracle Business Intelligence system components.

User authentication commonly fails between the BI Server and the BI Security Services, when either of the following are true:

  • User credentials (in the credential store) are not synchronized with the user population.

  • Oracle Business Intelligence has not been restarted.

    In this situation, the BI Server sends out of date system.user credentials to the BI Security Service.

C.1.1.4.3 Oracle System User Account

The OracleSystemUser account is created by default in the WebLogic embedded LDAP store during Oracle BI EE install and is required for Oracle Web Services Manager (OWSM). OWSM is used by WebLogic Server or OPSS to secure calls to the Oracle Business Intelligence Security Service. If the Oracle System User account is incorrect, then the Oracle Business Intelligence login process fails (for more information, see Section C.1.1.5). The Oracle System User account must be named OracleSystemUser, and must be in a group named OracleSystemGroup. The group OracleSystemGroup must have the global role named OracleSystemRole assigned to it.

C.1.1.5 Oracle Business Intelligence Login Overview

When a user logs in to Oracle Business Intelligence without Single Sign-On, authentication and user profile look-up occurs. In a Single Sign-On (SSO) environment, authentication is performed outside the Oracle Business Intelligence system, and identity is asserted instead, but user profile look-up still occurs.

Authentication and identity assertion is performed by authentication providers and asserters respectively, and is configured using Oracle WebLogic Server Administration Console. The user profile lookup uses a User Role API which relies on having a single identity store configured. The first configured authentication provider is used by default as the identity store, for example to search for user GUIDs, or email. Successful login to Oracle Business Intelligence requires that the first configured authentication provider contains your user population. For more information, see Section 3.4, "Configuring Alternative Authentication Providers".

The login process flow begins by entering user credentials in the login screen these are sent to Presentation Services, and then to the BI Server. The BI Server attempts to authenticate the user credentials by calling the BI Security Web Service (deployed in the WebLogic Managed Server, and protected by a Web Service Security policy). The call requires the BI Server to authenticate itself to Oracle Web Services Manager, before it can be received by the BI Security Service. The BI Server uses credentials stored in the system.user key under the oracle.bi.system map (for more information, see Section C.1.1.4.3, "Oracle System User Account"), to authenticate itself to the BI Security Service when attempting to authenticate the credentials specified by the user. If the BI System User credentials are incorrect, or the Oracle Web Services Manager does not authenticate them, then the BI Server cannot call the BI Security Service and the login process fails.

C.1.2 Using the Oracle BI Security Diagnostics Helper to Automatically Identify Security Issues

You use the Oracle BI Security Diagnostics Helper to help identify security issues. Oracle recommends that you use the Oracle BI Security Diagnostics Helper when speaking to a representative from Oracle Support. For more information, see:

https://support.oracle.com

This topic includes information on how to setup, deploy, and run the Oracle BI Security Diagnostics Helper to identify problems with your Oracle BI system, and contains the following sections:

C.1.2.1 What Is the Oracle BI Security Diagnostics Helper?

The Oracle BI Security Diagnostics Helper is a JEE application that helps diagnose possible configuration issues which may prevent your users from being able to log in to your Oracle BI system.

In order to use Oracle BI Security Diagnostics Helper for the first time, you have to run a setup script before you deploy and run the application.

Once deployed you can start diagnosing possible security issues by accessing the Oracle BI Security Diagnostics Helper URL in a Web browser.

All of the instructions for setting up and using Oracle BI Security Diagnostics Helper are detailed in the following sections.

C.1.2.2 Setting Up the Oracle BI Security Diagnostics Helper Using a Script - First-Time Use Only

You must run a script before using the Oracle BI Security Diagnostics Helper for the first time use to ensure the Oracle BI Security Diagnostics Helper is setup correctly. The script grants the correct permissions to run the diagnostic checks. If you have already run the setup script you do not need to run it again.

To setup the Oracle BI Security Diagnostics Helper - for first-time use only:

You must run the script named addDiagnosticsCodeGrant.py for first time use only, to ensure that the Oracle BI Security Diagnostics Helper is setup correctly.

  1. Open a command prompt and change to the scripts directory.

    In UNIX, the scripts directory is located in:

    MW_HOME/ORACLE_HOME/bifoundation/admin/scripts

    In Windows, the scripts directory is located in:

    MW_HOME\ORACLE_HOME\bifoundation\admin\scripts

    For example, in UNIX:

    mw_home/Oracle_BI1/bifoundation/admin/scripts

  2. Run the setup script.

    In UNIX use the following command syntax:

    MW_HOME/ORACLE_HOME/common/bin/wlst.sh addDiagnosticsCodeGrant.py t3://<WebLogic_host_name>:<WebLogic_port_number>
    

    For example, in UNIX enter the following command:

    mw_home/Oracle_BI1/common/bin/wlst.sh addDiagnosticsCodeGrant.py t3://localhost:7001
    

    In Windows use the following syntax:

    mw_home/Oracle_BI1/common/bin/wlst.cmd addDiagnosticsCodeGrant.py t3://<WebLogic_host_name>:<WebLogic_port_number>
    

    For example, in Windows enter the following command:

    mw_home\Oracle_BI1\common\bin\wlst.cmd addDiagnosticsCodeGrant.py t3://localhost:7001
    

    The script reports 'Added code grants to bidiagnostics' when it runs successfully. It may also display some warnings and error messages which you can ignore if the script ran successfully.

  3. When prompted, enter the WebLogic administrator user name and password.

  4. Restart the WebLogic Servers.

    For more information, see Section C.1.2.6, "Restarting the WebLogic Servers".

C.1.2.3 Deploying the Oracle BI Security Diagnostics Helper

You must deploy the Oracle BI Security Diagnostics Helper as it is not automatically deployed into the WebLogic Server during install.

To deploy the Oracle BI Security Diagnostics Helper:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  2. Click Deployments.

  3. Click Install.

  4. Select the bidiagnostics.ear file

    In UNIX, the bidiagnostics.ear file is located in:

    MW_HOME/ORACLE_HOME/bifoundation/jee

    For example:

    mw_home/OracleBI1/bifoundation/jee/bidiagnostics.ear

  5. Click Next to display the Install Application Assistant page.

  6. Select Install this deployment as an application (already selected)

  7. Click Next to display the Select deployment targets page.

  8. In the Servers area select AdminServer.

  9. Click Next, then Finish

  10. Click, Activate Changes.

    The Oracle BI Diagnostic Helper changes into a 'prepared' State, and can be started.

    The following message should appear: "All changes have been activated. No restarts are necessary".

C.1.2.4 Running the Oracle BI Security Diagnostics Helper

After deploying the Oracle BI Diagnostics Helper it does not automatically start, you have to run it.

To run the Oracle BI Security diagnostics helper:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  2. Click Deployments.

  3. Select the bidiagnostics checkbox.

  4. Click Start and choose one of the following options:

    - Servicing all requests.

    - Servicing only administration requests.

    The Oracle BI Security Diagnostics Helper is now setup and running.

    When started - bidiagnostics State is set to 'Active'

C.1.2.5 Using the Oracle BI Diagnostics Helper

The Oracle BI Security Diagnostics Helper performs a series of security tests outlined in the following topics:

Note:

To start the security tests enter a URL similar to the following, into a Web browser, for example:

http://mycomputer:7001/bidiagnostics/security/diagnostics.jsp
Use this URL for this release.
http://mycomputer:7001/bidiagnostics/security
Use this URL for later releases.
C.1.2.5.1 OWSM Tests

The OWSM tests perform the following:

  • Checks whether MDS-OWSM data source is present and reports where it is, if found.

    For example, the check might return the following message if the MDS-OWSM data source is found:

    Found data source under JNDI path jdbc/mds/owsm.

  • Checks the connection to MDS-OWSM.

    This check notes that it has successfully connected to the schema, or returns an error message if the check fails.

  • Checks that the OracleSystemUser exists.

    This check notes that the user exists, or returns an error message if the check fails.

  • Checks that the OracleSystemUser is in the OracleSystemGroup.

    This check notes whether the check succeeds, or returns an error message if the check fails.

C.1.2.5.2 BI System User Tests

The BI System User tests perform the following:

  • Checks that the system.user key exists in credential store.

    This check notes that the system.user key exists, or returns an error message if the check fails.

  • Authenticates the system.user account.

  • Checks the system.user permissions.

    This check that the system.user permissions exist, or returns an error message if the check fails

C.1.2.5.3 User Credential Authentication Tests

The user credential authentication tests perform the following (when you complete all fields and click Test Authentication):

  • Checks the identity store using the authentication providers.

  • Checks Oracle BI Security Service authentication.

  • Checks Oracle BI Web Service authentication.

C.1.2.6 Restarting the WebLogic Servers

To restart the WebLogic Servers:

  1. Log in to Oracle WebLogic Server Administration Console.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  2. In the Domain Structure area, click Environment, Servers.

  3. In the Summary of Servers page, display the Control tab.

  4. Select bi_server1, and click Shutdown (select 'When work completes', or 'Force shutdown now', as required.

    If you are using a cluster, you will select multiple BI Servers, for example, bi_server1, bi_server2.

    Wait until all BI Servers are shut down before proceeding to the next step.

  5. Select AdminServer, and click Shutdown (select 'When work completes', or 'Force shutdown now', as required.

  6. Open a command prompt and change directories to where the startWebLogic script is located.

    For example, in UNIX:

    user_projects/domains/bifoundation_domain/bin

  7. Start WebLogic Server.

    In UNIX, enter the following command:

    ./startWebLogic.sh
    

    Enter the username and password when prompted.

    Wait for WebLogic Server to start before proceeding to the next step.

  8. Log in to Oracle WebLogic Server Administration Console.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  9. In the Domain Structure area, click Environment, Servers.

  10. In the Summary of Servers page, display the Control tab.

  11. Select bi_server1, and click Start.

    If you are using a cluster, you will select multiple BI Servers, for example, bi_server1, bi_server2.

C.1.3 Identifying Causes of User Login Authentication Failure

This section helps you to identify causes of authentication failure when logging in to Oracle Business Intelligence.

Figure C-1 and Figure C-2 are cause and effect diagrams that you can use to identify possible causes of user login authentication failure. Once you have identified the likely cause of user login identification failure, refer to Section C.1.4, "Resolving User Login Authentication Failures" for information about how to resolve the issues.

Figure C-1 Causes of User Login Failure - Part 1

This figure is described in the surrounding text.

Figure C-1 helps you identify causes of log in failure. If you are unable to identify the cause of log in failure using Figure C-1, then use Figure C-2 instead.

The description for Figure C-1 is as follows:

  • Authenticator misconfigured.

    • Ensure that the correct Oracle Business Intelligence certified authenticator is configured for the identity store.

    • Ensure that users are visible in the Oracle WebLogic Server Administration Console.

    • Ensure that groups are visible in the Oracle WebLogic Server Administration Console.

    • Ensure that a user with appropriate permissions can log in to Oracle WebLogic Server Administration Console.

    • Ensure that the ordering and control flags on authenticators are correct.

  • Authenticator misconfigured (second-level issues).

    • Ensure that WebLogic Server has been re-started after any configuration changes.

    • Ensure that the WebLogic Admin user is correctly moved to LDAP, if WebLogic Server does not start.

    • Ensure that the attributes specified (including user GUID) match what is in your LDAP store.

    • Ensure that 'from Name Filter' queries are correct.

    • Ensure that user and group Base DN settings are correct.

    • Ensure that the account used for LDAP connection has sufficient privileges.

  • Only one user affected.

    • Ensure that correct credentials are used.

    • Ensure that the user account is not locked or expired.

  • Communication failure.

    • Ensure that the identity store is available.

    • Ensure that all BI System processes are running.

    • Ensure that all JEE applications are running.

Figure C-2 Causes of User Login Failure - Part 2

This figure is described in the surrounding text.

Figure C-2 helps you identify alternative causes of log in failure if you cannot identify them using Figure C-1. However, if you still cannot identify the causes of login failure after using Figure C-2, contact Oracle Support at:

https://support.oracle.com

The description for Figure C-2 is as follows:

  • BI System User authentication failure.

    • Ensure that the BISystem user account exists and has correct roles.

    • Ensure that the BISystem user is synchronized with credential store.

    • Ensure that the BISystem user account is in the identity store.

    • Ensure that WebLogic embeddedLDAP replication of BI System User credential change has not failed.

  • Identity store provider (OPSS) misconfigured.

    • Ensure that if using a SQL authenticator, the adapters are configured correctly.

    • Ensure that if the attributes specified for username or GUID are set to something other than the default value for the WebLogic authenticator, the OPSS configuration matches.

    • Ensure that in Oracle Business Intelligence Release 11.1.1.5 (or higher):

      • Virtualization is set to true.

      • Control flags are set as in Oracle Business Intelligence Release 11.1.1.3 (see following bullet).

    • Ensure that in Oracle Business Intelligence Release 11.1.1.3 the authentication provider (which refers to the user population with the BI System User), is the first control flag in the list of providers.

    • Ensure that the WebLogic Server is re-started after any configuration changes.

    • Ensure that in Oracle Business Intelligence Release 11.1.1.5 (or higher), if virtualization is set to true and the identity store requires SSL, virtualization must be configured correctly. For more information, see Section 5.4.6, "Configuring SSL when Using Multiple Authenticators".

  • Oracle Web Services Manager errors.

    • Ensure the database connects to the MDS-OWSM schema created on install.

    • Ensure the OracleSystemUser account that OWSM uses to access its resources is working.

C.1.4 Resolving User Login Authentication Failures

This section explains user login authentication failures, describes how to resolve them, and contains the following topics:

C.1.4.1 Single User Cannot Log In to Oracle Business Intelligence

This section contains the following topics:

C.1.4.1.1 Is Login Failure the Result of User Error?

The first check is whether the user cannot log in to Oracle Business Intelligence due to a simple error for example, did the user enter the wrong password? If other users can log in to Oracle Business Intelligence, but one user cannot, check their credentials. Alternatively, see Section C.1.4.1.2.

C.1.4.1.2 Is Your Account Locked?

Many LDAP authenticators lock user account when login attempts exceeds a specified threshold. For example, an account may be locked after 3 failed login attempts to defeat automated attacks.

If a user tries repeatedly to log in, their credentials might have been incorrectly entered enough times to trigger this mechanism. Refer to the documentation for your chosen identity store to discover how to unlock user accounts. For example, to unlock a locked user account when using WebLogic embdedded LDAP, see "Unlock user accounts" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

C.1.4.2 Users Cannot Log In to Oracle Business Intelligence Due to Misconfigured Authenticators

The most common cause of authentication failure is misconfiguration of authenticators in WebLogic Server as follows:

Note:

Make sure you have read, and are familiar with the steps and concepts identified in Chapter 3, "Using Alternative Authentication Providers".

C.1.4.2.1 Have you Specificed the Correct Authenticator for Your Identity Store/LDAP Server?

WebLogic Server uses a variety of server-specific authenticators in addition to the embedded LDAP authenticator. This is because some LDAP server products have differences which mean they do not appear to be generic LDAP servers and therefore the embedded LDAP authenticator may not work when configured to query against them. For example, the generic LDAP server does not work with Active Directory (AD), even though AD does apparently fully implement LDAP and successfully presents itself as an LDAP server to many LDAP query tools. Find out which LDAP server you are using and ensure you configure the appropriate authenticator.

C.1.4.2.2 Is the Authenticator for Your LDAP Server Configured Correctly?

If the configuration settings for the LDAP server used as the primary identity store are not correctly configured, then users cannot be correctly authenticated. Some common things to check include:

  • Account used for LDAP connection.

    In the LDAP Authenticator provider-specific configuration, you must specify the DN of a principal that is used to connect to the LDAP server. This account must exist and have sufficient privileges to be able to run queries to retrieve the user or group population from the trees specified in the User or Group Base DNs. In a restricted LDAP environment, this may require elevated privileges beyond those granted to ordinary user accounts.

  • Ensure user and group Base DNs are correct.

    Both groups and users are searched for within the tree specified by the user or group Base DN, make sure that the 'tree' specified actually contains your user or group population.

  • Ensure 'from Name Filter' queries are correct.

    Groups and users are found within the trees specified in the base DN by using the query specified in 'User from name filter' and 'Group from Name filter', with %u used as a placeholder for the user id passed in during queries on a specific user (including during authentication) and %g used similarly as the placeholder for the group name passed in when looking up a specific group. Check that the queries specified are syntactically and logically correct for your directory and test that you can run them (and get the expected results) from an LDAP browser, using the credentials specified in your authenticator configuration.

  • Ensure the attributes specified match what is in your LDAP store.

    The attributes/objectclasses for users, groups and GUIDs are all specified in the Authenticator configuration. The authenticators are pre-configured with "sensible" defaults but on many sites these are not necessarily the ones in use. You should make sure (for example) that the value specified in User Name Attribute exists and is actually being used for the user's names in the LDAP server on your site.

  • WebLogic Admin user moved to LDAP and cannot boot WebLogic.

    If you move the WebLogic Admin user from embedded LDAP and/or removed the DefaultAuthenticator (that is, you rely on LDAP authentication of the WebLogic admin user), and have misconfigured your authenticator configuration, then WebLogic Server does not start.

  • Check if users are able to log in to Oracle WebLogic Server Administration Console.

    Assuming you can still log in to the Oracle WebLogic Server Administration Console (and if you can start WebLogic, you should be able to log in to the Oracle WebLogic Server Administration 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 Oracle WebLogic Server Administration Console (http://<biserver>:7001/console). If they are able to log in to the Oracle WebLogic Server Administration Console, but not Oracle Business Intelligence, then the LDAP authenticator configuration is correct, but it may not be accessible to Oracle Business Intelligence. There are two things to check in this instance:

Note:

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!

C.1.4.2.3 Are the Control Flags for Your Authenticators Set Correctly and Ordered Correctly?

The primary identity store must be set as the first one in the list of authenticators (note that this restriction is lifted from Oracle Business Intelligence Release 11.1.1.5 (or higher) when virtualization is set to true). Oracle Business Intelligence uses the user role API from OPSS which only picks up the first identity store from the list of authenticators for example, when looking up user GUIDs, profile information, roles. This is a prime cause of the scenario whereby a user can log in to Oracle WebLogic Server Administration Console (hence demonstrating that the authentication part of logging in is succeeding), but cannot log in to Oracle Business Intelligence (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 enables each one to be tried in turn until authentication succeeds. If authentication is successful, no further authenticators are tried. If none of the authenticators can authenticate the supplied credentials, the overall authentication process fails.

Note:

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

C.1.4.3 Users Cannot Log In to Oracle Business Intelligence When Oracle Web Services Manager is not Working

Oracle Web Services Manager (OWSM) secures the BI Security Service, so if OWSM is not working, then nothing can call the BI Security Service, and authentication cannot succeed until this issue is resolved.

Common causes of OWSM failure are:

For information about BI System User authentication failure, see Section C.1.4.4, "Users Cannot Log In to Oracle Business Intelligence - Is BI System User Authentication Working?".

C.1.4.3.1 Database Issues - OWSM Cannot Retrieve Policies

OWSM stores its metadata, including its policy definitions, in an OWSM subsection of the MDS schema. It accesses this metadata using a connection pool created on install, named mds-owsm. If there is a problem accessing the schema (for example, if the database is not available, there are incorrect credentials, or the database account is locked), then Oracle Business Intelligence authentication fails.

You see an error message like the following one in the Managed Server diagnostic log:

[2011-06-28T14:59:27.903+01:00] [bi_server1] [ERROR] [] [oracle.wsm.policymanager.bean.util.PolicySetBuilder] [tid: RTD_Worker_2] [userId: <anonymous>] [ecid: de7dd0dc53f3d0ed:11d7f503:130d6771345:-8000-0000000000000003,0] [APP: OracleRTD#11.1.1] The policy referenced by URI "oracle/wss_username_token_client_policy" could not be retrieved as connection to Policy Manager cannot be established at "t3://biserver:7001,biserver:9704" due to invalid configuration or inactive state.

In addition, you see multiple errors related to a failure to establish or create the connection pool for the data source in the Administration Server logs.

To correct this issue, you must check the following:

  • Is the database schema you specified for the MDS-OWSM data source available?

  • Did you specify the correct credentials?

  • Can you access the schema using standard database tools (for example, SQL Plus, Jdeveloper DB tools) using those credentials?

  • Is the mds-owsm data source configured correctly?

To test the MDS-OWSM data source:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. Click Services in the left hand pane and click Data Sources.

  3. Display the Configuration page and click mds-owsm.

  4. Select the Monitoring tab and display the Testing page.

  5. Select a server and click Test Data Source.

To configure the MDS-OWSM data source:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

  2. Click Services in the left hand pane and click Data Sources.

  3. Display the Configuration page and click mds-owsm.

  4. Select the Configuration tab and display the Connection Pool page.

  5. Configure appropriate changes.

  6. Click Save to save your changes.

  7. In the Change Center, click Activate Changes.

  8. Restart WebLogic Server and Oracle Business Intelligence components.

C.1.4.3.2 OracleSystemUser Issues - OWSM Cannot Retrieve Policies

By default, OWSM uses the OracleSystemUser account to retrieve policies. If the account is missing, and cannot be authenticated or does not have the correct WebLogic global role assignments, this causes failures.

You see a log message like the following one in the Managed server diagnostic logs:

[2011-06-28T14:59:27.903+01:00] [bi_server1] [ERROR] [] [oracle.wsm.policymanager.bean.util.PolicySetBuilder] [tid: RTD_Worker_2] [userId: <anonymous>] [ecid: de7dd0dc53f3d0ed:11d7f503:130d6771345:-8000-0000000000000003,0] [APP: OracleRTD#11.1.1] The policy referenced by URI "oracle/wss_username_token_client_policy" could not be retrieved as connection to Policy Manager cannot be established at "t3://biserver:7001,biserver:9704" due to invalid configuration or inactive state.[[

After this entry, if the problem is that OWSM is not in the OracleSystemRole WebLogic global role, you see the following log entry:

java.rmi.AccessException: [EJB:010160]Security Violation: User: 'OracleSystemUser' has insufficient permission to access EJB: type=<ejb>, application=wsm-pm, module=wsm-pmserver-wls.jar, ejb=DocumentManager, method=retrieveDocuments, methodInterface=Remote, signature={java.lang.String,java.util.Map}.

You must ensure that the OracleSystemUser is a member of the OracleSystemGroup group in your identity store and that the group has the WebLogic global role OracleSystemRole assigned to it. For more information, see Steps 3-6 in Section 3.4.7.1, "Configuring Oracle Internet Directory LDAP Authentication as the Only Authenticator" (these steps still apply for other LDAP servers):

Alternately, if the problem is that the OracleSystemUser account cannot not be authenticated or does not exist (for example, because you migrated to an LDAP identity store and removed DefaultAuthenticator without creating a new OracleSystemUser account in your new identity store), you see a log entry like this:

Caused by: javax.security.auth.login.FailedLoginException: [Security:090304]Authentication Failed: User OracleSystemUser javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User OracleSystemUser denied

at weblogic.security.providers.authentication.LDAPAtnLoginModuleImpl.login(LDAPAtnLoginModuleImpl.java:261)

This error message can be caused by several different issues:

  • You have removed the DefaultAuthenticator and not created an account named OracleSystemUser in the new identity store you are using instead.

  • You have misconfigured the authenticator for your new identity store such that the OracleSystemUser account cannot be found.

  • The OracleSystemUser account has been locked or disabled in some way on your LDAP server.

Check the system for each of the possible causes, reconfigure and restart the system if needed, before retrying.

C.1.4.4 Users Cannot Log In to Oracle Business Intelligence - Is BI System User Authentication Working?

The BI System User account (named BISystemUser by default) is critical to the functioning of the BI Security Service and Oracle Business Intelligence authentication as a whole. The BI System User account authenticates the calls that the BI Server makes to the BI Security Service when it is trying to check the credentials the user has supplied when logging in. If this call fails, then Oracle Business Intelligence cannot authenticate user logins against Fusion Middleware security (that is, users in an identity store configured through WebLogic), the preferred mechanism. BI System User authentication can fail with the following error message in the BI Server nqserver.log:

[2011-06-28T11:30:36.000+00:00] [OracleBIServerComponent] [ERROR:1] [] [] [ecid: c594c519d241c3b9:-2173cea0:130d2098159:-8000-00000000000019ba] [tid: 4734ba0] Error Message From BI Security Service: FailedAuthentication : The security token cannot be authenticated.

[2011-06-28T11:30:36.000+00:00] [OracleBIServerComponent] [ERROR:1] [] [] [ecid: c594c519d241c3b9:-2173cea0:130d2098159:-8000-00000000000019ba] [tid: 4734ba0] [nQSError: 43126] Authentication failed: invalid user/password.

You also see a corresponding entry in the Managed Server diagnostic log like this:

[2011-06-27T11:06:46.698-07:00] [bi_server1] [NOTIFICATION] [] [oracle.bi.security] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: BISystemUser] [ecid: 004dfIJ^08LATOB[2011-06-28T04:27:48.011-07:00] [bi_server1] [ERROR] [WSM-00008] [oracle.wsm.resources.security] [tid: [ACTIVE].ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: c594c519d241c3b9:-2173cea0:130d2098159:-8000-00000000000019a1,0:1:1:8:1] [WSM_POLICY_NAME: oracle/wss_username_token_service_policy] [APP: bimiddleware#11.1.1] Web service authentication failed.[[

javax.security.auth.login.LoginException: [Security:090303]Authentication Failed: User BISystemUser weblogic.security.providers.authentication.LDAPAtnDelegateException: [Security:090295]caught unexpected exception

at oracle.security.jps.internal.jaas.module.authentication.JpsUserAuthenticationLoginModule.login(JpsUserAuthenticationLoginModule.java:71)

This message indicates that OWSM does not allow the call from the BI Server to the BI Security Service to succeed because it cannot authenticate the credentials supplied by the BI Server (not the end user on login) as being valid. The BI Server retrieves the credentials it uses for this call from the credential store by looking in the oracle.bi.system map for the system.user key. These are the credentials that are being authenticated by OWSM.

The following list shows the possible reasons behind failures with the BISystemUser account:

C.1.4.4.1 The BI System User Account Does Not Exist, Does Not Have Correct Roles, or is Not Synchronized with the Credential Store

You can resolve these BISystemUser account issues by following the instructions in Section 3.7, "Configuring a New Trusted User (BISystemUser)".

The account specified must have the BISystem application role and the WebLogic Global Admin role, and the system.user key in the credential store must be updated with the new account name and password.

Once you complete these steps restart all Oracle Business Intelligence components and the WebLogic Managed Servers and Administration Server to synchronize the Oracle Business Intelligence components with the BI Security Service otherwise the problems may persist.

C.1.4.4.2 Problem With BI System User Account in Underlying Identity Store

It is not uncommon for some LDAP servers to be configured to lock a user account after multiple failed authentication attempts. The BI Server automatically presents the BI System User credentials when attempting to communicate with the BI Security Service. If you change your password without re synchronizing the credential store or restarting the services, the BI Server may make multiple failed authentication attempts, and lock the account by accident.

Equally, some servers are configured to require that credentials expire and be reset after a given period of time, which again lead to the BI System User failing authentication.

Check the policies on your LDAP server and make sure that the account has not become locked by mistake or expired.

C.1.4.4.3 Embedded WebLogic LDAP Replication of BI System User Credential Change Failed

This scenario occurs rarely and only when the system uses the WebLogic embedded LDAP server through the DefaultAuthenticator. To understand this scenario you need to understand a BI System User password change (using Oracle WebLogic Server Administration Console) is made initially in the Administration Server and then replicated in the Managed Servers. The BI Security Service authenticates against the replicated copy in the Managed Servers. However, if replication in the Managed Servers failure goes unnoticed, and you change the credentials in the credential store to synchronize with the new password, the two will not match. When this situation occurs, a log entry similar to the following is created in the Administration Server log:

####<2011/06/09 17:18:17 GMT> <Error> <EmbeddedLDAP> <bisrv01> <AdminServer> <VDE Replication Thread> <<anonymous>> <> <3425d20f6361741a:-2e8537d2:130736e27a9:-8000-000000000000000f> <1307607517792> <BEA-000000> <Agreement 'bi_server1': Error Transmitting Change#1698- Invalid name: cn=",ou=groups,ou=myrealm,dc=bifoundation_domain>

If you appear to have this problem but you do not see such an entry, the most likely explanation is that there is a genuine mismatch between the credentials stored in the credential store and those in the identity store. Double check that the change was applied correctly in both places and that all services were restarted after the change was made.

C.1.4.5 Users Cannot Log In to Oracle Business Intelligence - Is the External Identity Store Configured Correctly?

If you have configured an external identity store as your primary user population, check the following aspects of the provider configuration:

  • The authentication provider which refers to the primary user population must be set first in the order of providers (unless Release 11.1.1.5 (or higher) and virtualization is set to true).

  • If the DefaultAuthenticator is still enabled, ensure that both it and the authentication provider referring to the primary user population are set to 'SUFFICIENT'.

  • If you set the username attribute to something other than the default, you need to follow the instructions in Section 3.5, "Configuring User and Group Name Attributes In the Identity Store". For example, the OID authentication provider defaults to expecting the UserName attribute to be "cn", but many organizations actually use the attribute "uid" instead. In this instance, follow the instructions to set both username.attr and user.login.attr to uid in the identity store configuration in Fusion Middleware Control.

  • If you have reset the GUID attribute in the authentication provider configuration and see the following error message in the Managed Server console (it may also be found in the bi_server1.out file in the Managed Server logs directory), then you need to follow the instructions in Section 3.6, "Configuring the GUID Attribute In the Identity Store":

    java.security.PrivilegedActionException: oracle.bi.security.service.SecurityServiceException: SecurityService::authenticateUserWithLanguage - 'ldapuser' was authenticated but has an invalid GUID. Caused by: oracle.bi.security.service.SecurityServiceException: SecurityService::authenticateUserWithLanguage - 'ldapuser' was authenticated but has an invalid GUID. Caused by: oracle.bi.security.service.InvalidUserGUIDException: User 'ldapuser' has an invalid GUID value: 'null'

C.1.4.6 Users Can Log In With Any or No Password

In Oracle Business Intelligence Release 10g, authentication is managed through the Metadata Repository, and users wanting to authenticate against external database tables can do so using initialization block settings. The facility still exists in Oracle Business Intelligence 11g, and unfortunately it is possible to configure these blocks such that the query issued does not check the password of the user. For example, the query:

SELECT USER_ID FROM USERS WHERE USER_ID = ':USER'

only checks the user id and not whether the password is correct. In a scenario where such an initialization block is configured, it can lead to users being able to log in with any (or no) password.

This scenarios also leads to some apparently inconsistent behavior. For example, if user A and B exist in the primary identity store (Oracle Internet Directory), but user B also exists in a database which is referenced by the initialization block described in this section. When user A and user B try to log in using the wrong password they both fail authentication against OID. However, the BI Server will also attempt to run the initialization block for each user. User A fails, but user B logs in successfully because its user name is in the USER_ID column of the USERS table, and the initialization block query succeeds, despite not checking the user's password. This kind of scenario must be avoided, so if you find an authentication initialization block that behaves in this way you must remove, or alter it.

C.1.4.7 Have Removed Default Authenticator and Cannot Start WebLogic Server

WebLogic Server must be started using administrative user credentials which are associated with the WebLogic (not Oracle Business Intelligence) Global Admin role. When you install Oracle Business Intelligence the installer prompts for administrative user name and password, which are created in the embedded LDAP, and accessed through the DefaultAuthenticator. When you want to move from using the embedded LDAP to using an external LDAP identity store, you create a new WebLogic administrative user in the external store, ensure it has the WebLogic Global Admin role, and remove the DefaultAuthenticator.

However, if you have performed these steps and have not correctly configured the authenticator configuration for the identity store that now contains the user that you want to use to start the WebLogic Server with, then you cannot start the server. The work around is to revert to the configuration settings that existed before you removed the DefaultAuthenticator.

The domain home for your WebLogic BI Domain (unless you specifically requested otherwise on install), is located in:

<MW_HOME>/user_projects/domains/bifoundation_domain/

This directory contains a configuration directory with the configuration file for the overall domain, including any authenticators. When you update the configuration settings, a backup of the main configuration file, config.xml, is created, starting with backup_config.xml and then numbered versions (for example, backup_config7.xml) for each subsequent revision.

Make sure you copy the current config.xml and the most recent backup_config xml file in case you run into problems. To restore your configuration, replace the current config.xml file with the most recent backup_config xml file, and restart WebLogic Server and all Oracle Business Intelligence components. When WebLogic Server restarts, the DefaultAuthenticator will be restored.

C.2 Resolving Inconsistencies with the Identity Store

A number of inconsistencies can develop between a repository, the Oracle BI Presentation Catalog, and an identity store. The following sections describe the usual ways this can occur and how to resolve the inconsistencies.

C.2.1 User Is Deleted from the Identity Store

Behavior

If a user is deleted from the identity store then that user can no longer log in to Oracle Business Intelligence. However, references to the deleted user remain in the repository until an administrator removes them.

Cause

References to the deleted user still remain in the repository but that user cannot log in to Oracle Business Intelligence. This behavior ensures that if a user was deleted by accident and re-created in the identity store, then the user's access control rules do not need to be entered again.

Action

An administrator can run the Consistency Checker in the Oracle BI Administration Tool in online mode to identify inconsistencies.

C.2.2 User Is Renamed in the Identity Store

Behavior

A user is renamed in the identity store and then cannot log in to the repository with the new name.

Cause

This can occur if a reference to the user under the original name still exists in the repository.

Action

An administrator must either restart the BI Server or run the Consistency Checker in the Oracle BI Administration Tool to update the repository with a reference to the user under the new name. Once this has been resolved Oracle BI Presentation Services updates the Oracle BI Presentation Catalog to refer to the new user name the next time this user logs in.

C.2.3 User Name Is Reused in the Identity Store

Behavior

If a user name is added that is identical to one previously used in the identity store, the new user with the same name cannot log in.

Cause

This can occur if references to the user name exist in the repository.

Action

An administrator must remove existing references to the user name contained in the repository by either running Consistency Checker in the Oracle BI Administration Tool or by changing the existing user references to use the new user's GUID. When the new user logs in with the reused name, a new home directory is created for the new user in the Oracle BI Presentation Catalog.

C.3 Resolving Inconsistencies with the Policy Store

A number of inconsistencies can develop between the Oracle BI Presentation Catalog and the policy store. The following sections describe the usual ways this can occur and how to resolve the inconsistencies.

C.3.1 Application Role Was Deleted from the Policy Store

Behavior

After an application role is deleted from the policy store the role name continues to appear in the Oracle BI Administration Tool when working in offline mode. But the role name no longer appears in Presentation Services and users are no longer granted the permissions associated with the deleted role.

Cause

References to the deleted role name persist in the repository enabling the role name to appear in the Administration Tool when working in offline mode.

Action

An administrator runs the Consistency Checker in the Oracle BI Administration Tool in online mode to remove references in the repository to the deleted application role name.

C.3.2 Application Role Is Renamed in the Policy Store

Behavior

After an application role is renamed in the policy store the new name does not appear in the Administration Tool in offline mode. But the new name immediately appears in lists in Presentation Services and the Administration Tool. Users continue to see the permissions the role grants them

Cause

References to the original role name persist in the repository enabling the role name to appear in the Administration Tool when working in offline mode.

Action

An administrator either restarts the BI Server or runs the Consistency Checker in the Administration Tool to update the repository with the new role name.

C.3.3 Application Role Name Is Reused in the Policy Store

Behavior

An application role is added to the policy store reusing a name used for a previous application role. Users cannot access Oracle Business Intelligence resources according to the permissions granted by the original role and are not granted permissions afforded by the new role.

Cause

The name conflict must be resolved between the original role and new role with the same name.

Action

An administrator resolves the naming conflict by either deleting references to the original role from the repository or by updating the repository references to use the new GUID.

C.3.4 Application Role Reference Is Added to a Repository in Offline Mode

Behavior

An application role has a blank GUID. This can occur after an application role reference is added to the repository in offline mode.

Cause

The Administration Tool in offline mode does not have access to the policy store and cannot fill in the GUID when a reference to the application role is added to the repository.

Action

After start up, the BI Server fills in any blank GUIDs for application role references with the actual GUID.

C.4 Resolving SSL Communication Problems

Behavior

Communication error. A process (the client) cannot communicate with another process (the server).

Action

When there is an SSL communication problem the client typically displays a communication error. The error can state only "client refused" with no further information. Check the server log file for the corresponding failure error message which typically provides more information about the issue.

Behavior

The following error message is displayed after the commit operation is performed using the BIDomain MBean (oracle.biee.admin:type=BIDomain, group=Service).

SEVERE: Element Type: DOMAIN, Element Id: null, Operation Result: VALIDATION_FAILED, Detail Message: SSL must be enabled on AdminServer before enabling on BI system; not set on server: AdminServer

Action

This message indicates that SSL has not been enabled on the Oracle WebLogic Server Managed Servers, which is a prerequisite step. For more information, see Section 5.3.3, "Manually Configuring WebLogic to Use the HTTPS Protocol" and Section 5.3.4.3, "Committing the SSL Configuration Changes".

C.5 Resolving Issues with BI System User Credentials

You might not be able to log in when using a valid user name and password. For example, an error message like the one in Example C-1 is displayed when BISystemUser credentials are not synchronized.

Example C-1 Example bifoundation_domain.log Output When BISystemUser Credentials Are Not Synchronized

####<DATE> <Error> <oracle.wsm.resources.enforcement> <Machine_Name> <bi_server1> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1273244079442> <WSM-07607> <Failure in execution of assertion {http://schemas.oracle.com/ws/2006/01/securitypolicy}wss-username-token executor class oracle.wsm.security.policy.scenario.executor.WssUsernameTokenScenarioExecutor.>
####<DATE> <Error> <oracle.wsm.resources.enforcement> <Machine_Name> <bi_server1> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1273244079442> <WSM-07602> <Failure in WS-Policy Execution due to exception.>
####<07-might-2010 15:54:39 o'clock BST> <Error> <oracle.wsm.resources.enforcement> <ukp79330> <bi_server1> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1273244079442> <WSM-07501> <Failure in Oracle WSM Agent processRequest, category=security, function=agent.function.service, application=bimiddleware#11.1.1.2.0, composite=null, modelObj=SecurityService, policy=oracle/wss_username_token_service_policy, policyVersion=null, assertionName={http://schemas.oracle.com/ws/2006/01/securitypolicy}wss-username-token.>
####<DATE> <Error> <oracle.wsm.agent.handler.wls.WSMAgentHook> <Machine_Name> <bi_server1> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1273244079442> <BEA-000000> <WSMAgentHook: An Exception is thrown: FailedAuthentication : The security token cannot be authenticated.>
####<DATE> <Error> <oracle.wsm.resources.security> <Machine_Name> <bi_server1> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1273244091113> <WSM-00008> <Web service authentication failed.>
####<DATE> <Error> <oracle.wsm.resources.security> <Machine_Name> <bi_server1> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1273244091113> <WSM-00006> <Error in receiving the request: oracle.wsm.security.SecurityException: WSM-00008 : Web service authentication failed

C.6 Resolving Custom SSO Environment Issues

You might encounter issues when setting up custom SSO environments. For example, when setting up SSO with Windows Native Authentication and Active Directory, or with SiteMinder.

For more information, see article IDs 1287479.1 and 1274953.1 on My Oracle Support at:

https://support.oracle.com

C.7 Resolving RSS Feed Authentication When Using SSO

When attempting to read an Oracle BI RSS feed, trouble authenticating an RSS reader using SSO may stem from the way Oracle SSO is intercepting requests from that particular RSS reader. In this case Oracle cannot control the feed reader application. There are two scenarios, however, where SSO may be supportable:

You must validate deployment strategies for your environment.