OBIEE Security Enforcement – LDAP Authentication

Authentication in OBIEE

Some authentication methods used by Oracle BI server are

1. Database

2. LDAP

3. Oracle BI server (repository users) – I do not recommend this method for medium to large implementations. It will be difficult to manage.

I will discuss on setting up LDAP in this article.

Setting up LDAP or Windows ADSI in OBIEE

Microsoft ADSI (Active Directory Service Interface) is Microsoft version of LDAP server. Most of the steps to setup of either Microsoft ADSI or LDAP server are similar. In either case, you would need help from your network security group/admin to configure LDAP. They should provide you with the following information regarding the LDAP server

1. LDAP server host name

2. LDAP Server port number

3. Base DN

4. Bind DN

5. Bind Password

6. LDAP version

7. Domain identifier, if any

8. User name attribute type (in most cases this is default)

Registering an LDAP server in OBIEE

In Oracle BI repository, go to manage security.

Create a new LDAP server in OBIEE Security Manager

With the help from your network security group/administration, fill out the following information

Next in the Advanced tab, based on the kind of LDAP server you have and its configuration, make the necessary changes.

For Microsoft ADSI (Active Directory Service Interface), choose ADSI and for all others leave it unchecked.

Most of the times, Username attribute would be automatically generated. For Microsoft ADSI It is sAMAccountName; for most of the LDAP servers it is uid or cn. Check with your network security group/administrator on what is the username attribute for your LDAP server. Make a note of the user name attribute you will need it later.

Now we need to create an Authentication initialization block. In administration tool, under Manage go to Variables.

Under Action, go to New -> Session -> Initialization Block

Configure the session initialization block. Give it a name and click on Edit Data Source. In the pop up window, choose LDAP from the drop down box and then click on Browse. You can also configure a LDAP server here by clicking on “New”. In the browse pop up window choose the LDAP server you would like to use.

Next we need to create variables. User and Email are the common variables normally in play.

Upon clicking on OK, a warning pops up on the usage of User session variable (User session variable has a special purpose. Are you sure you want to use this name). Click yes.

Next enter the LDAP variable for username. sAMAccountName in the case of ADSI as configured in the LDAP.

Next following similar steps create a variable for Email. In addition, depending on you need, you can bring additional variables from the LDAP server.

Now bounce your services.

"Bullet Proof" SSO

The following pieces are a subset of info presented at Oracle OpenWorld's OBI SSO Unconference by Kevin McGinley and myself. The content framework was provided by John Andrzejek of BI Consulting Group.

The full presentation can be found via http://www.biconsultinggroup.com/OOW

Many organizations have enabled SSO (Single Sign-On) with OBI EE; however, not all have taken the appropriate steps to make it "Bullet Proof", aka next to impossible to hack. Until now!

Below is a typical OBI EE login path when SSO is not enabled. This method works well in an intranet environment where personal data is not available to be queried by OBI EE.



Many organizations have taken the step to enable SSO for OBI EE so their users do not have to enter/remember yet another username/password combination. SSO is more secure than the basic OBI EE login but is still susceptable to hackers tricking OBI EE into authorization.

In order to ensure a more robust/secure method of SSO with OBI EE, the following approach should be taken so that a hacker cannot trick OBI EE into thinking the user has been authenticated. This is handle by Step 4 (see pic below) whereby the user clicks on a link in their portal to go to OBIEE and the portal writes a Record to a database table and then the BI Server checks this record to make sure the user has been authenticated.

If the user was not properly authenticated by the Portal then OBI will deny the user access to OBI EE.