OBIEE 11.1.1 - Users are able to log in to the WebLogic Admin console, but not BI

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 few 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. The primary identity store must be set as the first one in the list of authenticators (note that this restriction is lifted from BI 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.

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. 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 you’ve given one (or many, if you specify the role condition by group name match) of your users a lot more power than you intended them to have.

3) Clean up all the users/groups security in RPD that may already exist from upgraded 10g RPD (delete user from rpd if present) and perform GUID refresh again i.e.


This could also occur when user GUIDs in rpd are out of sync with the weblogic console. This is the case if you have migrated your RPD from one instance to another. In this case I would recommend performing a GUID refresh which will help you login again.

Posted by Ram Chaitanya on February 15, 2012 at 10:50 PM PST #

Don't forget that the BI Server can also prevent a user signing in to BI. Check the session variable initialisation blocks and ensure that these are configured appropriately. I had an issue the other day with a customer who had deployed one of the packaged Edge BI Applications and hadn't changed the Connection Pools as shipped with the OOTB RPD to point to their own databases. Hence all the Session Variable initilisation failed and at least one of them must have been checked as "required for authentication".

Posted by Chris Hathaway on February 17, 2012 at 01:10 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed