Bi Security

Oracle BI Enterprise Edition 11g Security - Troubleshooting Common Configuration Errors
An Oracle White Paper September 2011
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 Page 2
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 causeand-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/ <BI Install dir>/user_projects/domains/bifoundation_domain/servers/AdminServer/logs/ <BI Install dir>/user_projects/domains/bifoundation_domain/servers/bi_server1/logs/
WebLogic AdminServer logs:
WebLogic Managed Server 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: wls.jar,
[EJB:010160]Security
Violation:
User:
'OracleSystemUser'
has
insufficient permission to access EJB: type=<ejb>, application=wsm-pm, module=wsm-pmserverejb=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] 43126] Authentication failed: invalid user/password. [nQSError:
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] [WSM00008] [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 postauthentication, 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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bi Security

Uploaded by

Copyright:

Available Formats

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

<BI Install dir>/user_projects/domains/bifoundation_domain/ <BI Install dir>/user_projects/domains/bifoundation_domain/servers/AdminServer/logs/ <BI Install dir>/user_projects/domains/bifoundation_domain/servers/bi_server1/logs/

WebLogic AdminServer logs:

WebLogic Managed Server logs: BI Server logs:

<BI Install dir>/instances/instance1/diagnostics/logs/OracleBIServerComponent/coreapplication_obis1/

BI logon: key users/accounts

3.2. NO USERS CAN LOGIN TO BI MISCONFIGURED AUTHENTICATORS

SELECT USER_ID FROM USERS WHERE USER_ID = ':USER'

You might also like