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.