Thursday 20 August 2015

Uncovering the Issues of OBIEE 11.1.1.9.0

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
          Apply OPatch
    • 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.

Wednesday 19 August 2015

Authentication for user denied - Weblogic server startup failure - OBIEE 11.1.1.9.0



The Problem

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. When 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>

This error is not restricted to OBIEE11.1.1.9.0 though, it might also show up in other versions and here is the cause.

The culprit

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/bifoundation_domain/servers/AdminServer/security

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.

In other versions, it could be because of the boot.properties file was accidentally corrupted or deleted.

So what can be done?

Simply create a file called boot.properties under <MIDDLEWARE_HOME>/user_projects/domains/bifoundation_domain/servers/AdminServer/security with the Weblogic admin username and password, as shown below.


 
Once created, try restarting your Weblogic server and there, for your surprise, these simple 2 liners will do the magic for you.


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].