My Blog

Welcome to OBIEE12c: Configuring External LDAP Authentication Part 1

by Paul Cannon on 1st February 2016 25 comments

When OBIEE 12c is first installed it’s configured to use the Weblogic internal user directory and this is fine if you only have a small number of users or just want to provide specific user-ids to your users. However, most installations of OBIEE we perform want it configured to use the standard company LDAP to allow users to login with common user-ids – such as their windows/network user-id. This also allows for the access to OBIEE to be controlled via the same central directory as other company applications and the same security department to administer it.

When implementing external LDAP authentication you can do so either in addition to the weblogic internal user directory or as a replacement for it. Usually it’s best to do it in addition to the internal user directory – this ensures the weblogic admin user-id is still available as well as any other admin users/groups you may want to control through weblogic rather than your LDAP. The Security Guide for Oracle Business Intelligence Enterprise Edition covers the extra steps if you want to replace the internal user directory. I’ll be keeping it in this blog.

Weblogic can have multiple security realms and usually it’s best to create a new realm for your LDAP authentication – this allows the easy switching of realms to simply turn your LDAP authentication on & off as required. However, the instructions for duplicating a realm are a bit long winded, so in this blog I’ll take the simple route of adding my new LDAP authentication to the factory-installed default “myrealm”.

Also in this Blog I’ll be using a Microsoft Active Directory LDAP – by far and away the most common I come across, so you may need to carefully check the settings, especially on the “Provider Specific” screen where the LDAP connection details are entered.

Before starting you should take a backup of the weblogic security configuration file. If anything goes wrong either during the LDAP configuration, or later on – perhaps your if LDAP gets replaced – then you may get locked out of Weblogic and be unable to repair any issues.  By restoring the configuration file you will be able to reset the Weblogic security back to its “factory” settings and at least be able to login again to resolve or simply re-implement LDAP authentication.

This file is called config.xml and resides under <obiee_home>/user_projects/domains/bi/config


Now login to the weblogic Admin Console using your admin (weblogic) user-id. In the “Domain Structure” window click on “Security Realms”, then when the “Summary of Security Realms” window appears click on myrealm.


This opens the myrealm settings screen. Click on ‘Lock & Edit’ on the top left corner to allow changes to be made.


Now click on the Providers tab. This shows the three components already in place, the most important of which is the ‘DefaultAuthenticator’ which provides authentication for users setup in the Weblogic user directory (such as the ‘weblogic’ user-id).


Our first step is to make a slight change to the DefaultAuthenticator provider. Click on DefaultAuthenticator. In the Settings screen change the Control Flag from REQUIRED to SUFFICIENT:


This says that if the authentication finds a user/password match in the internal user directory then that is sufficient to allow the user to login. If not, then weblogic will check against other providers instead. If you leave this as REQUIRED then users will only be able to login to OBIEE if they exist in the weblogic internal user directory – regardless of whether they exist in your external LDAP or not.

Click the Save button.  Then once the Settings have been updated return to the Providers screen, which you can do by clicking on the Providers link in the breadcrumb trail:


Back in the Providers tab click either of the ‘New’ buttons:


In the Create screen enter a name for your new Provider (I entered MSAD_Provider) and select the appropriate type from the drop down. ActiveDirectoryAuthenticator is correct for MSAD.  If you cannot find your LDAP type you may have to use a similar LDAP type or manually configure a new one – see the Security Guide for Oracle Business Intelligence Enterprise Edition for more details.


Click Ok to create your new provider and return to the provider list:


Now click on your new Provider to edit its details.

In the Common tab change the Control Flag from OPTIONAL to SUFFICIENT. Just as with the DefaultAuthenticator above, a user/password match against this provider is sufficient to let a user login. The OPTIONAL setting (which does sound like it be ok) is used when you are setting up multiple additional LDAP providers and a specific user could reside in more than one of them (rather than just one of them).


Now click on the Provider specific tab.

There are a lot of settings in this screen, some optional, some compulsory and some with default settings.  I’ll explain the ones I needed to use for Active Directory – you may need to consider some of the others for your LDAP.


Host. This is the host server of your LDAP, ideally the host name, the IP address if not.

Port . The Port your LDAP server listens on. For Active Directory this is usually 389 for a non-SSL connection or 636 for SSL. If using SSL check the ‘SSLEnabled’ check box below.

Principal. This is the full domain path of the user used to connect to the LDAP and perform the authentication check.  This path will be unique to your LDAP configuration, but as an example in my LDAP this is: CN=administrator,CN=Users,DC=obiee,DC=local,DC=com

Credential. This is the password to the Principal user in your LDAP. You need to enter this a second time in the confirm credential field below.

User Base DN. This is the domain path in the LDAP where the user entries can be found. The user search scope option a few fields down lets you choose if the search should just be at this level or include any and all sub-levels.  My example of this is: CN=Users,DC=obiee,DC=local,DC=com

All Users Filter.   The search filter to identify user entries in the domain path (i.e. to exclude any non-user LDAP entries, such as groups).  I’ve used (objectclass=user) – including the brackets!, but another example I’ve used before is (&(cn=*)(objectclass=user))

User From Name Filter.  A default search filter if the All Users Filter can’t find the user details. I’ve used the default value of (&(cn=%u)(objectclass=user))

User Name Attribute. The Attribute in the LDAP which holds the user name. cn is common, sAMAccountName is also common in Active Directory

Object User Class. This is usually ‘user’, could be ‘person’

Use Retrieved User Name as Principal. This should usually be left unchecked – i.e. do not use the users name as their principal (user-id).

Group Base DN. This is the domain path in the LDAP where the group entries can be found. The group  search scope option a few fields down lets you choose if the search should just be at this level or include any and all sub-levels.  This may be the same as the User Base DN, if that’s the same place groups are stotred. My example of this is: CN=Users,DC=obiee,DC=local,DC=com

All Groups Filter.   The search filter to identify group entries in the domain path (i.e. to exclude any non-group LDAP entries, such as users).  I’ve used (objectclass=group)

Group From Name Filter.  A default search filter if the All Groups Filter can’t find the group details. I’ve used the default value of &(cn=%g)(objectclass=group))

All of the other settings in this tab I’ve left as their default values – you may need to check each one to see if they are correct for your LDAP connection.

Then click the Save button at the top of the tab.  Weblogic will perform a basic connection test at this point and generate errors if it fails, such as:


In this case I’d entered the wrong password as the credential. This particular error is more common than you’d like…if you ever need to come back to this screen to change any details you are required to re-enter the password, however you are not told this and the password field is not blank, so it’s not obvious, you will just need to re-enter the password again in both the credential and confirm credential fields before saving.

If all is ok and the save happens without errors then click the Activate Changes button in the top left corner of the screen.

You should then see the following message in green:


Weblogic has permanently stored these changes, but a full stop and restart of weblogic is required. So logout and use the standard stop & start scripts you use for stopping/starting OBIEE.

Once it’s restarted log back into the Admin Console, go back to Security Realm & myrealm and this time click on the Users and Groups tab. You see a list of users from both the weblogic DefaultAuthenticator and your LDAP provider:


Then click on the Groups tab to see the same:


If you can’t see any users or groups from your LDAP return to Provider Specific screen and check through the details you’ve entered, especially the user and group Base DN and Filters. If you do need to make any changes you will need to stop and restart weblogic again.

The next step is to configure OBIEE to see users from your new LDAP provider in addition to the weblogic internal directory users.  To do this you need to login to the Enterprise Manager with your admin user account

Once logged in, from the Weblogic Domain drop-down menu select Security -> Security Provider Configuration:


From the Security Provider Configuration screen expand ‘Security Store Provider’, then expand Identity Store Provider and finally click ‘Configure’


In this screen we need to add a new Custom Property.


Click the +Add button.  Then enter a property name of ‘virtualize’ and a value of ‘true’.  These must be typed in lower case exactly as shown here. Click ok.


Then click OK again to save:


You should now be able to login to OBIEE using a user from either the weblogic internal directory or from your LDAP. Here my user ‘Paul’ is from my LDAP:


So that completes the first part – establishing your LDAP as an authentication provider. By default all users in the LDAP are now able to login to OBIEE and all users will just be basic consumers – able to view dashboards & reports but not create any new reports or other content besides basic report jobs and actions. In part 2 I’ll go through setting up security to give your users different levels of access to OBIEE based on your LDAP configuration.



Paul CannonWelcome to OBIEE12c: Configuring External LDAP Authentication Part 1

Related Posts

Take a look at these posts


Join the conversation
  • SF - 25th February 2016 reply


    Thanks for this tutorial,

    I import users perfectly but since the version has the new version 12.1
    users are unable to connect with their IDs in analytics ,

    Thank you to assist me

  • Sivakanth - 22nd March 2016 reply

    Does it work in the same way in clustered environment (horizontally scaled) ? Do we need to do any changes to config .xml? I encounter an error when i click on activate changes like : Deployer:149150]An IOException occurred while reading the input. : with response code ‘401’ : with response message ‘Unauthorized
    An error occurred during activation of changes, please see the log for details.

  • Maria - 14th April 2016 reply

    First, thanks for your post. It’s really good.
    I’ve tried to configure AD in OBI 12c following your steps. Every parameter is set ok but when I restart the services to apply the changes, the bi server is not able to start again. The LDAP database is also being used by an 11g instance that is running at the same time as the 12c. Do you know if this is a problem and if that may be the reason for the bi_server not starting?

    Paul Cannon - 13th June 2016 reply

    Hi Maria,

    no, you can have as many BI servers connecting to the same LDAP as you like – the LDAP can’t detect what’s being used and object to multiple different versions of any external software. You would need to look in the bi_server1 log files to see what the issue is.


  • Ajay - 1st June 2016 reply

    Getting the below Error in OBIEE 12c for SSO we had the Generic SSO option in which i

    State: 08004. Code: 10018. [NQODBC] [SQL_STATE: 08004] [nQSError: 10018] Access for the requested connection is refused.
    State: HY000. Code: 43113. [nQSError: 43113] Message returned from OBIS.
    State: HY000. Code: 13038. [nQSError: 13038] The user does not have impersonation privilege. (HY000)[[
    File:checkauthentication.cpp [Security:090938]Authentication failure: The specified user failed to log in. [Security:090302]Authentication Failed: User specified user denied

    Kindly help us here

  • Kumar - 9th June 2016 reply

    I tried configuring,AD users can able to login but when i tried logging as weblogic it is saying invalid username or password.Can you tell why it is causing that issue ?

    Paul Cannon - 13th June 2016 reply

    Hi Kumar,

    sounds like it’s not authenticating users in the weblogic directory – have you got the virtualize = true set right in the EM – it’s this setting that enables the weblogic directory to be used as well as the configured LDAP.


  • Kevin Taber - 22nd June 2016 reply

    In regards to licensing, does Oracle charge for every AD account that is sync’d to WebLogic? All of my users are in a single OU and I don’t want to have to restructure Active Directory. Ideally I’d like to filter access by group membership. Any examples of that?

  • Safer - 26th July 2016 reply


  • Paul Berrones - 15th November 2016 reply

    Excellent post, I configured according your steps and it works fine, but when I change the parameter User Name Attribute to sAMAccountName I can’t see any user in obiee. Where can I find log files of this configuration.

    Thanks for your answer

    Paul Cannon - 18th November 2016 reply

    Hi Paul, take a look at this blog, it lists all of the log file locations for OBIEE:

    Paul Berrones - 18th November 2016 reply

    Thanks Paul

    I atill trying to configure the integration and now this error appear
    [OBI-SEC-00501] Could not find user “test” in the Identity Store

    Bernd - 16th February 2017 reply

    Hi Paul,
    I have got the same error message [OBI-SEC-00501]. Could you solve the problem?

    anjali - 8th May 2017

    We have a similar this resolved?? Any solution

    marek - 8th August 2017 reply

    have you been able to solve the OBI-SEC-00501 anyhow?

  • edz - 29th November 2016 reply

    Hi Thanks for the post it helps me to verify things. But I have problem, I can see the users in the console but users are unable to connect with their IDs in analytics.

    Thanks for the help.

  • Patricia - 3rd January 2017 reply

    Hi Paul!
    We configure ldap server for BI, we did it through Manage Bi Publisher (, Chapter Using LDAP with BI Publisher. Then we tried to access to BI Publisher but it says:
    Unauthorized access; Does not have the necessary privilege or is not connected.
    We want to rollback this but now we don’t hve privileges on Managing BI Publisher, OBIEE option.
    ¿How can we access again?

    Paul Cannon - 6th January 2017 reply


    you should be able to user the BI Superuser – which you should have setup before configuring LDAP, however this will only work directly in BIP (i.e. with the /xmlpserver URL), not via OBIEE.


  • Sebastien - 3rd February 2017 reply

    Hi Paul, thanks a lot for your document it is very helpful. I have a question, with this configuration, do you know how to access by mobile (iphone and BI HD mobile from the appstore, or directly by safari browser) to the dashboard and Bi publisher report? Our problem is when we use a mobile device, the authentification from LDAP doesn’t recognize us. Thank you.

    Sebastien - 18th July 2017 reply

    any update?

  • Avik - 16th March 2017 reply

    Hi Paul, Amazing blog as usual from you. Need your inputs on a typical problem. I have set up LDAP authentication in my OBIEE server following the exact steps that you have mentioned. I can retrieve the users from weblogic -> myrealms -> users and groups successfully but the same users are not able to login to OBIEE analytics. Anything I am missing out on?


    Pius - 19th April 2017 reply

    Hi Avik
    We’ve got the same Problem, everything looks fine in the weblogic-console but we can’t find any accounts or groups in the EM. Have you found a solution for this or does someone else have an Input for me?
    Thanks and Regards

    Onur - 19th February 2018 reply


    Having the exact same issue here. Were you able to solve this?

    Thank You.

    Onur - 19th February 2018 reply


    Having the exact same issue here. Were you able to solve this? Any solutions yet?

    Thank You.

  • AM - 26th May 2017 reply

    In AD, many organisations do not delete the old/inactive users. They simply make them Disabled. But when LDAP is integrated with OBIEE, it brings in both Enabled and Disabled users. Is there a way to filter out Disabled users from coming in OBIEE ? I mean is there any Attribute and if yes, where should we use it and its syntax ?

Join the conversation