Bi Security

Oracle BI Enterprise Edition 11g
Security - Troubleshooting
Common Configuration Errors
An Oracle White Paper
September 2011

Oracle BI Enterprise Edition 11g Security - Troubleshooting Common Configuration Errors Page 2
Contents
1. Introduction ............................................................................................................................................................ 3
Authentication defaults on install ............................................................................................................................ 3
Administrative web apps ........................................................................................................................................... 3
BI WebLogic domain and log locations .................................................................................................................. 3
BI logon: key users/accounts ................................................................................................................................... 4
BI logon process: overview ....................................................................................................................................... 5
2. Reasons Why a User May Not Be Able To Login ............................................................................................ 6
3. Single user cannot login to BI .............................................................................................................................. 7
User error ..................................................................................................................................................................... 7
Account locked out .................................................................................................................................................... 7
4. No users can login to BI Misconfigured Authenticators .............................................................................. 8
Have you specificed the correct authenticator for your Identity Store/LDAP server? ................................... 8
5. No users can login to BI is Oracle Web Services Manager working?......................................................... 9
Database issues OWSM cannot retrieve policies ............................................................................................... 9
OracleSystemUser Issues OWSM cannot retrieve policies ............................................................................. 10
6. No users can login to BI Is BI System User authentication working? ..................................................... 11
BI System User account does not exist/does not have correct roles/is out of sync with credential store 12
Problem with BI System User account in underlying identity store ................................................................. 13
Embedded WebLogic LDAP replication of BI System User credential change failed .................................. 13
7. No users can login to BI Is Identity Store correctly configured? .............................................................. 13
8. Users can login to BI with any (or no) password ............................................................................................ 14
9. Removed Default Authenticator and cannot boot WebLogic ...................................................................... 15
10. References ........................................................................................................................................................ 15

Oracle BI Enterprise Edition 11g Security -
Troubleshooting Common Configuration Errors
INTRODUCTION
This document is intended to cover some of the most common security issues customers have encountered while using
Oracle Business Intelligence 11g and have escalated via Oracle Support; it is not intended to be a comprehensive list of every
possible security scenario. The focus of this document is primarily on authentication failures.
This document is in three sections. The first section describes the basic concepts of authentication in Oracle BI 11g. An
understanding of the Oracle BI 11g Security guide (see link below) is a pre-requisite for using this document.
http://download.oracle.com/docs/cd/E14571_01/bi.1111/e10543/toc.htm
The second section of this document provides a checklist for diagnosing authentication failures. This is presented as a cause-
and-effect diagram.
The third section of this document provides more detail on many of the reasons that an authentication failure might occur.
1. BI AUTHENTICATION CONCEPTS
Authentication defaults on install
Immediately after install, BI is configured to authenticate against the WebLogic Embedded LDAP server, via the
DefaultAuthenticator. Some base user accounts are set up, including the WebLogic Admin User which will be set to the
account credentials you provided as the WebLogic administrative user during the install process.
Administrative web apps
Throughout this document there will be references to administrative tasks that need to be performed on WebLogic via the
WebLogic Admin Console and BI/the BI domain via the Oracle Enterprise Manager (EM). These web applications will be
accessible on the WebLogic Admin Server at the context roots /console and /em respectively. So, for example, if you have
installed your WebLogic Admin Server on http://biserver:7001/, the Admin Console will be at http://biserver:7001/console
and EM will be at http://biserver:7001/em.
You should log in to both using the username and password you specified for the Administrative user on install, unless you
have altered/removed that account and/or configured another account with the appropriate access (see below).
BI WebLogic domain and log locations
Throughout this document, you will need to know where on disk your BI WebLogic Domain is located and where the logs
are. The locations below assume you installed your domain to the default bifoundation_domain location and similarly used
the default location for your BI Instance. If you specified your own install locations, you should adjust the root paths
accordingly
WebLogic BI Domain Home: <BI Install dir>/user_projects/domains/bifoundation_domain/
WebLogic AdminServer logs: <BI Install dir>/user_projects/domains/bifoundation_domain/servers/AdminServer/logs/
WebLogic Managed Server logs: <BI Install dir>/user_projects/domains/bifoundation_domain/servers/bi_server1/logs/
BI Server logs: <BI Install dir>/instances/instance1/diagnostics/logs/OracleBIServerComponent/coreapplication_obis1/
BI logon: key users/accounts
Note that in the discussion that follows, actual account/role/group names are designated typographically by being in a fixed
width italic font and the concepts are in normal type. For example, there is a concept of a BI System User account (i.e. the
account which the BI System uses to authenticate itself) the concept is referred to as the BI System User. Whereas, by
default out of the box, this is set to an actual account created in WebLogic Embedded LDAP named BISystemUser
which is referred to as BISystemUser.
WebLogic Admin User: During the install process, you will have been prompted to provide a username and password for the
WebLogic Administrative user. This account is used to start the WebLogic Server and for administration of WebLogic and
BI via the WebLogic Admin Console and Oracle Enterprise Manager (EM) (see above). If you wish to change the WebLogic
Admin account or add other accounts as WebLogic Administrators, you must ensure any account you wish to use is in the
WebLogic Global role Admin (Note that this is a WebLogic role, not a BI Application Role).
You can add or remove users to/from this role via the WebLogic Admin Console:
Log into WebLogic Admin console
Select Security Realms from the left-hand menu, click on the link to your security realm in the main screen (e.g.
myrealm), then 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 on the link marked View
Role Conditions for the Admin Role.
Ensure the conditions specified will match your user, either directly, or by virtue of a group they belong to (e.g.
condition may be User=myadminaccount or Group=Administrators, for example)
If you have made any changes, click the Save button. Changes should be applied immediately
BI System User Account: The BI System User account is an account configured for internal authentication within the BI
System between different BI Components. It is NOT intended to be used as a normal user account to log in to and use the
application and it is recommended that if you do change from the default user created on install, you assign a special account
for this purpose, rather than using an account which is used by an actual user of the system.
On install, Oracle BI EE creates an internal account in the WebLogic LDAP store, BISystemUser, which is used for
service-to-service authentication. 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 wish to change the account used
for the BI System User, or if you wish to remove the Default Authenticator (meaning you will no longer be able to
authenticate against the WebLogic Embedded LDAP), please follow the instructions on changing the trusted system user
account in the Oracle BI Security guide at
http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10543/privileges.htm#CHDFHDBE
Note that the account used for the BI System User (defaults to BISystemUser as above) MUST be part of the
BISystem Application Role and the WebLogic Global Role named Admin. You must restart all services (i.e. WebLogic
Admin Server/Managed Server(s) and BI System Components manged via EM) after making any such changes.
A common cause of authentication failure when the customer is sure they are specifying the correct credentials can be that in
fact the authentication between BI Server and the BI Security Services required in order to authenticate any usesrs (see
below) is failing, either because the credentials specified in the Credential Store are out of sync with what is in the actual user
population or because the user has forgotten to restart the stack (which means that BI Server will be sending out of date
system.user credentials to the BI Security Service and hence its authentication will fail)
Oracle System User Account: Similarly, the OracleSystemUser account is created by default in the Embedded
WebLogic LDAP by the installer and is required for OWSM (Oracle Web Services manager). OWSM in turn is used by
WebLogic/OPSS to secure calls to BI Security Service, so if the Oracle System user account is incorrect, then the BI logon
process will fail (see below). The Oracle System User account must be named OracleSystemUser and must be in a
group named OracleSystemGroup which in turn must have the OracleSystemRole WebLogic Global Role
assigned to it.
BI logon process: overview
The logon process in Oracle BI (i.e. what happens when a user logs in to the system) currently consists, broadly, of two
phases: authentication and user profile look-up. In an SSO environment, authentication is performed outside the BI system
boundary and instead identity is asserted, but the user-profile lookup still occurs.
The authentication/identity assertion phase is handled by the Authenticators (and Asserters) configured in the WebLogic
Admin Console. The user profile lookup phase is handled by the User Role API which relies on having a single Identity Store
configured. By default, it will assume the first configured Authenticator is the Identity Store it should search for the users
GUID, email etc. What this means is that for BI logon to succeed, the first configured Authenticator must contain your user
population. Further information can be found in the BI documentation section on Configuring a New Authenticator for Oracle
WebLogic Server at:
http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10543/sso.htm#BIESC646

The actual flow of the logon process also bears a quick examination: when a user logs in via the analytics web app UI, the
request containing the user credentials will be sent to the BI Presentation Server which in turn passes the request on to the
BI Server. The BI Server is authoritative for user authentication. In the first instance the BI Server will attempt to
authenticate the user credentials via a web service call to the BI Security Web Service, which is deployed in the WebLogic
Managed Server and is protected by a WS-Security policy which requires the BI Server to itself authenticate itself to Oracle
Web Services Manager before the call can be received by the BI Security Service. The BI Server uses credentials stored in the
Credential Store (CSF) under the oracle.bi.system map (see detailed section on BI System User above) and uses
those to authenticate itself to the BI Security Service when attempting to authenticate the credentials specified by the user. If
there is a problem with the BI System User credentials, or the Oracle Web Services Manager, then the call from the BI Server
to the BI Security Service will fail and hence so will the overall logon process.
2. REASONS WHY A USER MAY NOT BE ABLE TO LOGIN
The diagram below should be used as a checklist when a user is unable to login to BI. Many of the reasons why a user
cannot login are described in more detail in the remainder of this document.


3. POSSIBLE REASONS FOR AUTHENTICATION FAILURE IN DETAIL
3.1. SINGLE USER CANNOT LOGIN TO BI
User error
The first and most obvious thing to check is whether the user cannot login to BI due to simple error e.g. have they got their
password wrong? If other users are able to login to BI, but one user cannot, check they are using the correct credentials. Or
see note on account lock out below.
Account locked out
Many LDAP systems used for authentication purposes will include a provision to lock an account where numerous incorrect
authentication attempts are made e.g. an account may be locked after 3 failed login attempts in order to defeat automated
attacks.
If a user has been trying repeatedly to login, it may be that they have got the credentials incorrect on sufficient attempts to
trigger this mechanism. Check the documentation for your chosen identity store to discover how to do this, for example the
documentation on how to unlock a locked user account if you are using WebLogic Embdedded LDAP is at:
http://download.oracle.com/docs/cd/E21764_01/apirefs.1111/e13952/taskhelp/security/UnlockUserAccounts.html

3.2. NO USERS CAN LOGIN TO BI MISCONFIGURED AUTHENTICATORS
By far the most common cause of authentication failure is that the Authenticator(s) configured in WebLogic have been
misconfigured.
Make sure you have read (and are familiar with) the steps and concepts identified in the Oracle BI 11g documentation on
using Alternative (i.e. alternative to the default Embedded WebLogic LDAP) Authentication Providers at
http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10543/privileges.htm
Have you specificed the correct authenticator for your Identity Store/LDAP server?
This may sound obvious but it is more common than you may think. WebLogic ships with a variety of server-specific
Authenticators in addition to the generic LDAP authenticator, and with good reason. Some LDAP server products have
quirks which mean they do not present as generic LDAP servers and hence the generic LDAP Authenticator may not work
when configured to query against them (for example, the generic LDAP server does not work with Active Directory, even
though AD does apparently fully implement LDAP and successfully presents itself as an LDAP server to many LDAP query
tools. Find out what LDAP server the customer is using and ensure they have the appropriate authenticator configured.
Is the authenticator for your LDAP server correctly configured?
If the config settings for the LDAP server used as the primary identity store is not correctly configured, then users will not be
correctly authenticated. Some common things to check include:
Account used for LDAP connection in the LDAP Authenticator provider-specific config, the user must specify the DN of
a principal which will be 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/group population from the trees specified in the User/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/Group Base DN, make sure that the tree specified actually contains your user/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 specifed in your Authenticator config
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 config. The Authenticators are pre-configured with sensible defaults but on
many sites these will not necessarily be the ones in use. You should make sure that (for example) the attribute specified in
User Name Attribute exists and is actually being used for the users names in the LDAP server on your site.
WebLogic Admin user moved to LDAP and cannot boot WebLogic if you have moved your weblogic admin user from
Embedded LDAP and/or removed the DefaultAuthenticator (i.e. you are relying on LDAP authentication of your weblogic
admin user), if you have misconfigured your Authenticator config, then you will no longer be able to start WebLogic.
Check if users are able to log in to WebLogic Admin console assuming you can still log in to the WebLogic Admin
Console (and if you can start WebLogic, you should be able to login to the Admin Console using the credentials you used to
start the server) you can then assign one of the LDAP users the WebLogic Global Admin Role and see if they are able to log
in to the WebLogic Admin Console (http://biserver:7001/console). If they are able to log in to the WebLogic Admin
console, but not BI, then the LDAP authenticator config is correct, but it may not be accessible to BI. There are two things
to check in this instance:
1) The Identity Store that contains your users may not be being exposed as an Identity Store to OPSS check the
authenticator ordering/control flags section below
2) Your users are authenticating correctly to LDAP, but there is a problem with the BI System User which prevents the
BI Security Service from authenticating users (see section below)
N.B. if you temporarily assign the WebLogic Global Admin role to a user to test this scenario, please remember to remove
this as soon as you have completed testing or else you may find youve 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!
Are the control flags for your authenticators set correctly and are they correctly ordered?
The primary identity store must be set as the first one in the list of authenticators (note that this restriction is lifted from BI
11.1.1.5 using the virtualize=true configuration) BI uses the User Role API from OPSS which will only pick up the first
identity store from the list of authenticators when looking up users GUID, Profile Information, Roles etc. This is a prime
cause of the scenario whereby a user can log into WebLogic Admin Console (hence demonstrating that the authentication
part of logon is succeeding), but cannot log in to BI (because the identity store containing the user is not first in the list).
Where more than one Authenticator is configured, in the general case the control flags should all be set to SUFFICIENT.
This will have the effect of each one being tried in turn until authentication succeeds. If authentication is successful, no
further authenticators will be tried; if none of the authenticators are able to authenticate the supplied credentials, the overall
authentication process will fail.
N.B. on install, the DefaultAuthenticator is set to REQUIRED; if another authenticator is configured, the
DefaultAuthenticator, if it is to be retained, must be set to SUFFICIENT or OPTIONAL instead. SUFFICIENT is the
recommended setting, for the reasons outlined above.
3.3. NO USERS CAN LOGIN TO BI IS ORACLE WEB SERVICES MANAGER WORKING?
As outlined above, Oracle Web Services Manager (OWSM) is used to secure the BI Security Service. Hence if OWSM itself is
not working, then nothing will be able to call the BI Security Service and so authentication will never succeed until this is
resolved.
There are two common causes of OWSM itself failing (as opposed to the call to the BI Security Service failing OWSM
authentication see next section on BI System User authentication for details on that case):
1) Database error issues connecting to the MDS-OWSM schema created on install
2) Issues with the OracleSystemUser account OWSM uses to access its resources
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 via a Connection Pool created on install, named mds-owsm. If there is a problem accessing the schema (e.g.
database not available, incorrect credentials, database account locked etc) then BI authentication will fail.
You will see an error message in the Managed Server diagnostic log like this:
[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 will see multiple errors related to a failure to establish/create the connection pool for the DataSource in the
AdminServer logs.
In order to correct this issue, you need to check the following things:
1) Is the database/schema you specified for the MDS-OWSM datasource available?
2) Did you specify the correct credentials?
3) Can you access the schema using standard database tools (e.g. SQL Plus, Jdeveloper DB tools etc) using those
credentials?
4) Is the mds-owsm Datasource configured correctly?
To test the MDS-OWSM Datasource:
1) Login to WLS Admin Console
2) From the menu on the left-hand side select Services->Data Sources
3) In the main screen, select mds-owsm
4) In the tabs along the top of the main screen select Monitoring->Testing

To configure the MDS-OWSM Datasource:
1) Login to WLS Admin Console
2) From the menu on the left-hand side select Services->Data Sources
3) In the main screen, select mds-owsm
4) In the tabs along the top of the main screen select Configuration->Connection Pool
5) Click "Save" after any changes you make
6) Restart WebLogic and BI component services
OracleSystemUser Issues OWSM cannot retrieve policies
By default, OWSM uses the OracleSystemUser account to retrieve policies etc. If the account is missing, cannot be
authenticated or does not have the correct WebLogic global role assignments, this will cause failures.
You will see a log message like the following 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 will 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 should 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. Further information is in the
BI Security guide, in tasks 3-6 in the section on using OID as an alternate identity/authentication provider (these steps still
apply for other LDAP servers):
http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10543/privileges.htm#BABCCAAB
Alternately, if the problem is that the OracleSystemUser account could not be authenticated or does not exist (e.g.
because you migrated to an LDAP identity store and removed DefaultAuthenticator without creating a new
OracleSystemUser account in your new identity store), you will 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 could be caused by several different issues:
1) You have removed the DefaultAuthenticator and not created an account named OracleSystemUser in the new
identity store you are using instead
2) You have misconfigured the Authenticator for your new Identity Store such that the OracleSystemUser
account cannot be found
3) The OracleSystemUser account has been locked/disabled in some way on your LDAP server.
Please check and if needed reconfigure the system for each of the above possible causes, restarting the system if need be, and
then retry.
3.4. NO USERS CAN LOGIN TO BI IS BI SYSTEM USER AUTHENTICATION WORKING?
As explained in the introductory notes, the BI system user account (named BISystemUser by default) is criticial to the
functioning of the BI Security Service and BI authentication as a whole it is used to authenticate the calls that the BI Server
makes to the BI Security Service when it is trying to check the credentials the user has supplied on login. If this call fails, then
BI cannot authenticate user logins against FMW security i.e. users in an identity store configured via WebLogic, the preferred
mechanism for 11g.
You will see an entry in the BI Server nqserver.log along the following lines:
[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.
And a corresponding entry in the Managed Server diganostic 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)
i.e. this is indicating that OWSM would not let the call from the BI Server to the BI Security Service succeed because it could
not authenticate the credentials supplied by BI Server (NOT the end user on login) as being valid. 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.
There are several possible causes for BI System User authentication to fail:
The customer has removed the DefaultAuthenticator because they are using an external LDAP store and have not
created the BI System User account in the new identity store
The customer has changed the account specified in the system.user key in the credential store but the new
account does not have the correct roles
The customer has changed the password of the account specified but has not updated the credential store with the
new credentials (or not restarted the system afterwards)
The account specified as the BI System User account has been locked/password expired etc i.e. an problem with the
account in the underlying identity store
(Only applies when using DefaultAuthenticator with Embedded WebLogic LDAP) The customer has changed the
password of the account specified and replication to the Managed Server has failed.
BI System User account does not exist/does not have correct roles/is out of sync with credential store
In the first three scenarios outlined above, you should simply follow the instructions set out in the BI Security Guide on
Configuring a new Trusted User (BISystemUser) at:
http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10543/privileges.htm#CHDFHDBE
Remember you need to ensure that the account specified has the correct BI Application Role (BISystem role) and
WebLogic Global Admin Role and that the system.user key in the credential store is updated with the new account
name/password.
Once you have completed these steps, you MUST restart all BI Components as well as the WebLogic Managed Server(s) and
AdminServer or the BI components will be out of sync with the BI Security Service and the problems will persist.
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. As the BI Server will automatically present the BI System User credentials when attempting to communicate with
the BI Security Service, if, for example, you have not restarted the services or have not re-synced the credential store after a
password change in the underlying identity store, this can very easily lead to the BI Server attempting multiple failed
authentication attempts, so locking 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
could 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.
Embedded WebLogic LDAP replication of BI System User credential change failed
This scenario only occurs when the system is still configured to use the Embeddded WebLogic LDAP server via the
DefaultAuthenticator and is very uncommon. However, we have observed some instances in the field of replication failure.
What happens is that the customer makes a change (e.g. to the BI System User password) in the WebLogic Admin console.
This change is made initially in the AdminServer and then replicated to the Managed Server(s). As the BI Security Service
authenticates against the replicated copy in the Managed Server(s), if replication fails, then although the customer has
apparently reset the password in LDAP, the change will not actually have taken affect. If this happens unnoticed and the
customer then goes on to change the credentials in the credential store to match the new password, the two will now be out
of sync. As stated above, this scenario is extremely rare; if it does happen you will see a log entry like that below in the
AdminServer 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 once the change was made.
3.5. NO USERS CAN LOGIN TO BI IS IDENTITY STORE CORRECTLY CONFIGURED?
Assuming the authenticator which acts as the primary configuration for the identity store is correctly set up (i.e. users are able
to login to WebLogic Admin console with the appropriate role assignment (see Section 4 above), there may still be issues
which would prevent BI from accessing the User/Role profile information it needs from the identity store post-
authentication, during the logon process (see the introductory notes for further information on this).
If you have added an external identity store as your primary user population, please 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 11.1.1.5 or later and virtualize=true is set).
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 provided
in the BI Security Guide topic on 3.2.4 Configuring User And Group Name Attributes In The Identity Store (at
http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10543/privileges.htm#BABEJGIE) to also tell the
OPSS APIs about the new attribute. For example, the OID Authentication provider defaults to expecting the
UserName attribute to be cn, but many organisations actually use the attribute uid instead. In this instance, you
would follow the instructions above to set both username.attr and user.login.attr to uid in the Identity Store
configuration in EM.
Similarly, if you have reset the GUID attribute in the authentication provider configuration you may need to tell the
OPSS User/Role API about it. If you see the following in the managed server console (may also be in bi_server1.out
in the Managed Server logs directory)
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'
then you need to tell the OPSS config about the custom GUID attribute, using the following procedure
1) In EM, select WebLogic domain in the menu on the left and right click on the name of the domain (e.g.
bifoundation_domain)
2) Select Security -> Security Provider Configuration
3) Under the Identity Store Provider section, click "Configure"
4) Click the green + (Add) to add a new property
5) Set property name to "PROPERTY_ATTRIBUTE_MAPPING" (without quotes) and value to "GUID=<GUID
attribute set in Authenticator>" (again without quotes) e.g. "GUID=customGUIDAttr"
6) Click OK to save property
7) Restart Admin Server, Managed Server(s) and BI Component services
Again, this is documented in the BI Security documentation in the topic 3.2.5 Configuring the GUID Attribute in the
Identity Store at http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10543/privileges.htm#CJAFAJHI
3.6. USERS CAN LOGIN TO BI WITH ANY (OR NO) PASSWORD
In Oracle BI 10g, authentication was managed via the RPD and users wising to authenticate against external database tables
could so via INIT block settings. That facility still exists in 11g, unfortunately it is possible to configure these blocks such that
the query issued does not check the password of the user. So, for example, the query
SELECT USER_ID FROM USERS WHERE USER_ID = ':USER'
would just check the user id and not the password was correct but not check the password. In a scenario where such an INIT
block exists and is set to act as an authentication block, this can lead to users being able to log in with any (or no) password.
It can also lead to some apparently odd/inconsistent behaviour. Consider the scenario where Users A and B both exist in
OID which is set as the primary identity store. But User B also exists in a database which is referenced by an INIT block as
described above. Both try to login using the wrong password. User A will simply fail. However, while User B will fail
Authentication against OID, because the BI Server knows there is an Authentication INIT block set, it will then attempt to
run that for each of them and in the case of User B, because their username is in the USER_ID column of the USERS table,
they will be allowed in as the INIT block query apparently succeeds, even though it does not in fact correctly check the users
password. Clearly this is not desirable and if you do discover an Authentication INIT block with this kind of behaviour you
should encourage the customer to remove or at least alter it.
3.7. REMOVED DEFAULT AUTHENTICATOR AND CANNOT BOOT WEBLOGIC
WebLogic requires the credentials of an administrative user i.e. a user who is in the WebLogic (not BI) Global Admin role
in order to start. On install, Oracle BI prompts for an admin user name and password which is then created in the
Embedded LDAP accessed via the DefaultAuthenticator. A common procedure when a customer wishes to move entirely to
external LDAP and no longer use the Embedded LDAP/DefaultAuthenticator is to 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 done this and you have not correctly configured the Authenticator config for the Identity Store that
now contains the user you now wish to boot weblogic with, then you will no longer be able to start WebLogic. Dont panic
you can revert back to the previous config settings before you removed the DefaultAuthenticator.
Find the domain home for your WebLogic BI Domain unless you specifically requested otherwise on install, this will under
<BI Install dir>/user_projects/domains/bifoundation_domain/. Under that directory is a config directory which contains
the overall domain config, including any authenticators. Each time you change the config settings, a backup of the main
config file, config.xml, is created, starting with backup_config.xml and then numbered versions (e.g. backup_config7.xml) for
each subsequent revision.
Make a copy of the current config.xml (in case you run into problems) and the most recent backup_config xml file. Then
replace the current config.xml file with the most recent backup_config xml file and restart WebLogic and all BI components.
When WebLogic has restarted, your DefaultAuthenticator will be restored.
4. REFERENCES
[1] Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)
http://download.oracle.com/docs/cd/E14571_01/bi.1111/e10543/toc.htm
[2] Securing Oracle WebLogic Server
http://download.oracle.com/docs/cd/E14571_01/web.1111/e13707/toc.htm

Oracle BI Enterprise Edition 11g Security - Troubleshooting Common Configuration Errors
June 2011
Authors: Paul Davis, Adam Bloom

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com

Copyright 2011, Oracle. All rights reserved.
This document is provided for information purposes only
and the contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to
any other warranties or conditions, whether expressed orally
or implied in law, including implied warranties and conditions of
merchantability or fitness for a particular purpose. We specifically
disclaim any liability with respect to this document and no
contractual obligations are formed either directly or indirectly
by this document. This document may not be reproduced or
transmitted in any form or by any means, electronic or mechanical,
for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.

Bi Security

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Bi Security

Загружено:

Авторское право:

Доступные форматы

Oracle BI Enterprise Edition 11g

Вам также может понравиться