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
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:
Section C.1.1, "Authentication Concepts"
This section describes the basic concepts of authentication in Oracle Business Intelligence Enterprise Edition. You must understand the concepts used throughout this guide as a prerequisite for using this section.
Section C.1.2, "Identifying Causes of User Login Authentication Failure"
This section provides a cause-and-effect diagram to use as a checklist for identifying authentication failure causes.
Section C.1.3, "Resolving User Login Authentication Failures"
This section provides reasons and solutions for login authentication failure.
This section describes authentication concepts, helps you to resolve login issues, and contains the following topics:
Section C.1.1.4, "Oracle Business Intelligence Key Login User Accounts"
Section C.1.1.5, "Oracle Business Intelligence Login Overview"
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 a WebLogic Server administrator that uses the credentials entered during installation.
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 administrator 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").
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
ORACLE_HOME/user_projects/domains/bi/
WebLogic Administration Server logs
ORACLE_HOME/user_projects/domains/bi/servers/AdminServer/logs/
WebLogic Managed Server logs:
ORACLE_HOME/user_projects/domains/bi/servers/bi_server1/logs/
BI Server logs:
ORACLE_HOME/user_projects/domains/bi/servers/obis1/logs/
This section describes the key login user accounts, and contains the following sections:
The WebLogic Server administrator 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 Server administrator account must have the WebLogic Server global role called Admin (this is not an Oracle Business Intelligence application role), which also enables them to add new WebLogic Server administrator accounts.
To add or remove users to or from the global admin role using the Oracle WebLogic Server Administration Console:
Log in to Oracle WebLogic Server Administration Console as a WebLogic Server administrator, and click Lock & Edit in the Change Center.
For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".
Select Security Realms from the left pane and click myrealm.
The default Security Realm is named myrealm.
Select Roles and Policies from the tabs along the top.
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.
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.
If you have made any changes, click Save.
In the Change Center, click Activate Changes.
When a user logs in to Oracle Business Intelligence without Single Sign-On, authentication and user profile lookup 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 lookup 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 is looked up within the Identity Store to retrieve various attributes, such as email, display name, description, language etc. 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 Oracle Business Intelligence to Use Alternative Authentication Providers".
The login process flow begins with the user credentials entered in the login screen, being 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.
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.3, "Resolving User Login Authentication Failures" for information about how to resolve the issues.
Figure C-1 helps you identify causes of login failure. If you cannot identify the cause of login 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 Server administrator user is correctly moved to LDAP, if WebLogic Server does not start.
Ensure that the attributes specified 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 helps you identify alternative causes of login 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:
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 attribute specified for username is 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.14.2, "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.
This section explains user login authentication failures, describes how to resolve them, and contains the following topics:
Section C.1.3.1, "Single User Cannot Log in to Oracle Business Intelligence"
Section C.1.3.7, "Have Removed Default Authenticator and Cannot Start WebLogic Server"
This section contains the following topics:
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 that user's credentials. Alternatively, see Section C.1.3.1.2.
Many LDAP authenticators lock a user account when attempts to log in exceed a specified threshold. For example, an account may be locked after more than three failed login attempts to defeat a potential automated attack.
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 Server embedded LDAP, see "Unlock user accounts" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.
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".WebLogic Server uses a variety of server-specific authenticators in addition to the embedded LDAP authenticator. However, the embedded LDAP authenticator might not be able to query against some LDAP server products because they do not appear to be generic LDAP servers. 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. Configure the appropriate authenticator based on the LDAP server that the system uses.
If the configuration settings for the LDAP server used as the primary identity store are incorrectly 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.
Search for groups and users in the tree specified by the user or group Base DN, and ensure that the tree specified actually contains your user or group population.
Ensure 'from Name Filter' queries are correct.
Search for groups and users in the trees specified in the base DN by using the query specified in 'User from name filter' and 'Group from Name filter'. %u is a placeholder for the user id used for querying a specific user (including during authentication), and %g is a placeholder for the group name used for querying a specific group. Check that queries are syntactically and logically correct for your directory, and that you can run them (and return expected results) from an LDAP browser, using the credentials specified in the authenticator configuration.
Ensure the attributes specified match what is in your LDAP store.
The attributes and object classes for users and groups, are specified in the Authenticator configuration. You should not necessarily use an authenticator's pre-configured default values. For example, you should ensure that the value specified in User Name Attribute exists, and is being used for the users' names in the LDAP server on your site.
WebLogic Server administrator user moved to LDAP and cannot boot WebLogic Server.
If you move the WebLogic Server administrator user from the embedded LDAP server to another LDAP server, and also remove the DefaultAuthenticator from the embedded LDAP Server, you are relying only on LDAP to authenticate the administrator user. If you have misconfigured the LDAP authenticator, WebLogic Server does not start.
Ensure users can log in to Oracle WebLogic Server Administration Console.
If you can log in to Oracle WebLogic Server Administration Console using the credentials you used to start WebLogic Server, you can check whether other LDAP users can log in to Oracle WebLogic Server Administration Console as follows:
Grant the WebLogic Server global Admin role to an LDAP user, and if they can log in to the Oracle WebLogic Server Administration Console (using the URL http://<biserver>:9501/console), the LDAP authenticator configuration is correct.
Note:
If you temporarily grant the WebLogic Server global Admin role to a user to test this scenario, you must remove the grant when testing is complete to ensure the user does not have privileges to which they are not entitled.If the LDAP user cannot log in to Oracle Business Intelligence:
Check that the identity store containing your users is exposed as an identity store to OPSS - check the authenticator ordering and control flags section (see Section C.1.3.2.3, "Are the Control Flags for Your Authenticators Set Correctly and Ordered Correctly?").
Check whether the BI System user is preventing the BI Security Service from authenticating users, if users are authenticating correctly to LDAP (see Section C.1.3.4, "Users Cannot Log in to Oracle Business Intelligence - Is BI System User Authentication Working?").
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 Application Programming Interface (API) from OPSS which only picks up the first identity store from the list of authenticators for example, when looking up users, profile information, roles. This situation enables a user to log in to Oracle WebLogic Server Administration Console (showing that authentication has succeeded), but prevents the user logging 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 you configure another authenticator, the DefaultAuthenticator must be set to SUFFICIENT or OPTIONAL, if it is being retained. SUFFICIENT is the recommended setting.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:
Section C.1.3.3.1, "Database Issues - OWSM Cannot Retrieve Policies"
Issues connecting to the MDS-OWSM schema created on install.
Section C.1.3.3.2, "OracleSystemUser Issues - OWSM Cannot Retrieve Policies"
Issues with the OracleSystemUser account that OWSM uses to access it's resources.
For information about BI System User authentication failure, see Section C.1.3.4, "Users Cannot Log in to Oracle Business Intelligence - Is BI System User Authentication Working?".
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:
Log in to Oracle WebLogic Server Administration Console.
Click Services in the left hand pane and click Data Sources.
Display the Configuration page and click mds-owsm.
Select the Monitoring tab and display the Testing page.
Select a server and click Test Data Source.
To configure the MDS-OWSM data source:
Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.
Click Services in the left hand pane and click Data Sources.
Display the Configuration page and click mds-owsm.
Select the Configuration tab and display the Connection Pool page.
Configure appropriate changes.
Click Save to save your changes.
In the Change Center, click Activate Changes.
Restart WebLogic Server and Oracle Business Intelligence components.
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 Server 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 Server 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 Server global role OracleSystemRole assigned to it. For more information, see Steps 3-6 in Section 3.4.9.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 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.
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:
You removed the DefaultAuthenticator because you are using an external LDAP store and did not create the BI System User account in the new identity store.
You changed the account specified in the system.user key in the credential store but the new account does not have the correct roles.
You changed the password of the account specified but have not updated the credential store with the new credentials (or not restarted the system afterwards).
Section C.1.3.4.2, "Problem With BI System User Account in Underlying Identity Store"
The account specified as the BI System User account has been locked or the password expired (there is a problem with the account in the underlying identity store).
You have changed the password of the account specified and replication to the Managed Server has failed (this only applies when you use the DefaultAuthenticator with WebLogic Server embedded LDAP).
You can resolve these BISystemUser account issues by following the instructions in Section 3.5, "Resetting the BI System User Credential".
The account specified must have the BISystem application role and the WebLogic Server 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.
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.
This scenario occurs rarely and only when the system uses the WebLogic Server embedded LDAP 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.
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 you are using 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.4.3, "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.
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 12c 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 scenario 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.
WebLogic Server must be started using administrator user credentials which are associated with the WebLogic Server (not Oracle Business Intelligence) global Admin role. When you install Oracle Business Intelligence the installer prompts for administrator 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 Server administrator user in the external store, ensure it has the WebLogic Server 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:
ORACLE_HOME/user_projects/domains/bi/
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.
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.
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.
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.
An administrator can run the Consistency Checker in the Oracle BI Administration Tool in online mode to identify inconsistencies.
A user is renamed in the identity store and then cannot log in to the repository with the new name.
This can occur if a reference to the user under the original name still exists in the repository.
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.
If a group that is associated with a user name does not exist in the identity store, you might see the following error in the nqserver.log:
[2012-10-04T12:00:00.000+00:00] [OracleBIServerComponent] [ERROR:1] [] []
[ecid: <ecidID>] [tid: d10] SecurityService::assertUserWithLanguage
[OBI-SEC-00018] Identity found <GUID> but could not be asserted
Look for the ECID in the bi_server1-diagnostic.log (or adminserver-diagnostic.log if using a simple install), you might see a warning something like the following:
[2012-10-04T12:00:00.314+02:00] [bi_server1] [WARNING] []
[oracle.jps.authentication] [tid: [ACTIVE].ExecuteThread: '2' for queue
:
'weblogic.kernel.Default (self-tuning)'] [userId: OBISystemUser] [ecid:
<ecidID>] [WEBSERVICE_PORT.name: SecurityServicePort] [APP
:
bimiddleware#11.1.1] [J2EE_MODULE.name: bimiddleware/security]
[WEBSERVICE.name: SecurityService] [J2EE_APP.name: bimiddleware_11.1.1]
javax.security.auth.login.FailedLoginException:
[Security:090305]Authentication Failed Getting Groups for User <UserID>
weblogic.management.utils.NotFoundException: [Security:090255]User or Group
<Groupname>[[
oracle.security.jps.internal.api.jaas.AssertionException
:
javax.security.auth.login.FailedLoginException:
[Security:090305]Authentication Failed Getting Groups for User <UserID>
weblogic.management.utils.NotFoundException: [Security:090255]User or Group
<Groupname>
...
at
oracle.bi.security.subject.SubjectAsserter.assertUser(SubjectAsserter.java:85)
at
oracle.bi.security.service.URServiceBean.assertUserWithLanguage(URServiceBean.java:97)
at
oracle.bi.security.service.SecurityServiceBean.getGrantedRolesForUser(SecurityServiceBean.java:270)
at
oracle.bi.security.service.SecurityWebService$1GetGrantedRolesForUserAction.run(SecurityWebService.java:391)
at
oracle.bi.security.service.SecurityWebService$1GetGrantedRolesForUserAction.run(SecurityWebService.java:381)
at java.security.AccessController.doPrivileged(Native Method)
at
oracle.bi.security.service.SecurityWebService.getGrantedRolesForUser(SecurityWebService.java:397)
...
Caused by: javax.security.auth.login.FailedLoginException:
[Security:090305]Authentication Failed Getting Groups for User <UserID>
weblogic.management.utils.NotFoundException: [Security:090255]User or Group
<Groupname>
This can occur if a group associated with a user name does not exist in the identity store.
Check the LDAP groups assigned to this user do actually exist and are readable by the principal used by WebLogic to access the LDAP.
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.
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.
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.
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.
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.
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.
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.
Communication error. A process (the client) cannot communicate with another process (the server).
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.
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
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.2.2.5, "Disable HTTP".
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:
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:
Using a browser-based RSS reader like Wizz RSS for Firefox, and using Firefox to log in to SSO before accessing the feed.
Using Windows integrated authentication with an RSS reader that uses Internet Explorer.
Firefox can support Windows authentication so you can use it in this case.
You must validate deployment strategies for your environment.