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: /user_projects/domains/bifoundation_domain/

WebLogic AdminServer logs: /user_projects/domains/bifoundation_domain/servers/AdminServer/logs/

WebLogic Managed Server logs: /user_projects/domains/bifoundation_domain/servers/bi_server1/logs/

BI Server logs: /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: ]


[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: ]

[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=, 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: ] [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:

####


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=" (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

/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

Documents

Transcript of Bi Security