1. Introduction
Oracle Business
Intelligence Enterprise Edition (OBIEE) 11.1.1.9.0 fresh installation, though
comes with lot of new features compared to its predecessors, have also been
known to lead to a few issues which cause the instability of the environment
after installation. The document entails
the list of issues encountered immediately upon the installation of a fresh
OBIEE 11.1.1.9.0 server on Unix/Linux environments.
2. Issues of OBIEE 11.1.1.9.0 installation
The following
sections detail on the issues that one would encounter upon installing the
OBIEE 11.1.1.9.0 server on any Unix or Linux environments, especially with
enterprise install options.
2.1. Weblogic Server Startup failure
With the fresh install of OBIEE
11.1.1.9.0, upon the first restart of the services, the Admin Server [Weblogic]
doesn’t start by default. If you investigate the logs [or “nohup.out” if started
in background using nohup] you might see the following entries.
<Critical>
<Security> <BEA-090403> <Authentication for user denied>
<Critical>
<WebLogicServer> <BEA-000386> <Server subsystem failed. Reason:
weblogic.security.SecurityInitializationException: Authentication for user denied
weblogic.security.SecurityInitializationException:
Authentication for user denied
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.doBootAuthorization(CommonSecurityServiceManagerDelegateImpl.java:966)
at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(CommonSecurityServiceManagerDelegateImpl.java:1054)
at
weblogic.security.service.SecurityServiceManager.initialize(SecurityServiceManager.java:873)
at
weblogic.security.SecurityService.start(SecurityService.java:141)
at
weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
Truncated. see log file for complete
stacktrace
Caused
By: javax.security.auth.login.FailedLoginException:
[Security:090304]Authentication Failed: User
javax.security.auth.login.LoginException: [Security:090301]Password Not
Supplied
at
weblogic.security.providers.authentication.LDAPAtnLoginModuleImpl.login(LDAPAtnLoginModuleImpl.java:261)
at
com.bea.common.security.internal.service.LoginModuleWrapper$1.run(LoginModuleWrapper.java:110)
at
java.security.AccessController.doPrivileged(Native Method)
at
com.bea.common.security.internal.service.LoginModuleWrapper.login(LoginModuleWrapper.java:106)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Truncated. see log file for complete
stacktrace
>
<Notice>
<WebLogicServer> <BEA-000365> <Server state changed to
FAILED>
<Error>
<WebLogicServer> <BEA-000383> <A critical service failed. The
server will shut itself down>
<Notice>
<WebLogicServer> <BEA-000365> <Server state changed to
FORCE_SHUTTING_DOWN>
2.1.1. The cause
If you are wondering why the server which
was working fine after the installation, doesn’t work all of sudden, the reason
behind is the missing boot.properties file under <MIDDLEWARE_HOME>/user_projects/domains/BiB_domain/servers/AdminServer/security
2.1.2. Some background
This boot.properties is a file that gets
created while configuring your Weblogic server and contains the Weblogic admin
user credentials stored. Whenever the server is started, this file will be
looked up at the back end, the username and password will be retrieved and thus
the server is booted using the retrieved credentials. By default, OBIEE
11.1.1.9.0 installation [Enterprise install] doesn’t create this file for some
reason. Fortunately or unfortunately, the server, right after the installation
doesn’t need this file since we key in the username and password during the
setup [5th step to be exact]. Thus, the Weblogic server fails to
start only after the first restart.
2.1.3. The Solution
Simply create a file called boot.properties
under <MIDDLEWARE_HOME>/user_projects/domains/BiB_domain/servers/AdminServer/security
with the Weblogic admin username and password, as mentioned below.
Once created, restart the weblogic server,
this time the server will boot up without any errors.
Also, upon the Weblogic server’s successful
restart, you may also notice that your boot.properties file is encrypted for
security reasons [using AES algorithm].
2.2. User Login Failures with Microsoft AD configuration
Following the installation of the OBIEE 11.1.1.9.0, there have been a few issues upon configuring Active Directory as authentication provider. The issues are explained below.
Issue 1: When the Microsoft AD Authenticator
is configured as an authenticator provider, the AD users will be unable to
login to the environment whereas the default authenticator users will be able
to login.
Oracle has
released 3 patches [however, one of them is a combined of the other two] to
resolve this issue.
- 20188679
- 21382568
- 21895214 [bundled version of above 2]
Issue 2: With the application of the above
patches, the AD users will be able to login. Yet, it will result in a new issue
that the Users and roles are not being retrieved from AD. This consequently
prevents all the dashboards from opening.
2.2.1. Solution to Issue 1
Apply the Oracle BI EE Suite patch p21895214 to
the OBIEE 11.1.1.9.0 setup. Patch p21895214 consists of the following component
patches:
|
Patch/Bug
|
Abstract
|
|
20188679
|
AUTHENTICATION
FAILS AGAINST 3RD PARTY LDAP WHEN VIRTUALIZE=TRUE SET
|
|
21382568
|
GUID
LOOKUP ISSUE AFTER UPGRADING TO OBIEE 11.1.1.9.0
|
Stop OPMN Services
Stop
opmn services using the following steps.
- Navigate to /u01/obiee/FMW/instances/instance1/bin
- Execute ./opmnctl stopall
Extract all zip patch Files
- Navigate to /u01/obiee/Software
- Extract the patch p21895214_111190_Generic.zip to the PATCH_TOP directory
- Check and set the following environment variables
ORACLE_HOME=/u01/obiee/FMW/oracle_common
PATH=$PATH: /u01/obiee/FMW/oracle_common/OPatch:/u01/obiee/FMW/Oracle_BI1/bin:
- Navigate to patch folder.
cd
/u01/obiee/Software/PATCH_TOP/21895214
Note: Make sure that oracle/orainventory and its sub folders are having full
permission to user.
- Execute the command: opatch apply
- Hit ‘y’ if it prompts to continue.
- Once the patch is successfully applied, the status will be displayed as below.
Verify patches
- In the terminal, navigate to: <ORACLE_HOME>
- Run command: opatch lsinventory
- It lists out all patches applied.
You may now restart your OMPN services.
2.2.2. Solution to Issue 2
1.
Open EM using the URL: http://<hostname>:7001/em/
2.
Navigate to Weblogic Domain > bifoundation_domain > Security > Security Provider
Configuration
3.
Navigate to Identity Store Provider > Configure
4.
Remove the custom properties username.attr and
user.login.attr
5.
Restart the OBIEE services [OPMN, bi_server1 and
weblogic.
With the removal of username.attr
and user.login.attr custom properties, the user role retrieval error vanishes
as they are no more needed with the latest releases.
