WELCOME TO OBIEE12C SET-UP USAGE

TRACKING PART 1
by Paul Cannon on 14th January 2016 No comments

Usage tracking in OBIEE 12c works in exactly the same way as 11g, tracking all
reports being run and queries fired to the database. Its also required if you want to
use the Summary Advisor to improve query performance.
Its configuration also isnt much different to 11g and Ill be running through these
steps here.
In this blog Ill run through the basic configuration to enable usage tracking. In Part 2
Ill look at setting up the tables in the RPD for reporting.
Usage Tracking writes tracking data to three tables in the xxx_BIPLATFORM schema
created by the RCU (repository creation utility) when OBIEE was installed
S_NQ_ACCT, S_NQ_DB_ACCT and S_NQ_INITBLOCK. These have already been
created and are ready to use. If you want to store your usage stats in a different
database to the OBIEE repository, then re-run the RCU and create a new
xxx_BIPLATFORM schema on the database of your choice.
Usage tracking writes records to the database via a connection pool in the RPD. So
before we can configure usage tracking we need to create this connection pool. We
do this by editing the RPD and importing the usage tracking tables.
So open the RPD (online if possible, otherwise youll need to download it, edit it and
upload it afterwards).
From the menu select File -> Import Metadata

In the Import Metadata screen change the connection type to OCI 10g/11g (not sure
why Oracle havent updated this to 12c too, but it works fine on 12c). Then enter the
connection details the data source name required a TNS entry either the TNS
name (as in my screenshot) or the full TNS String, something like
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=linuxvm)(PORT=1521))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME = ora12c)))
For the record the Admin tool uses the tnsnames.ora file from its own installation
directory on the client pc in my case its
C:\Oracle\Middleware\obiee12c\network\admin\tnsnames.ora
Then click next. If it fails to connect to your database you will get an error and a
chance to recheck your details.

In the in screen leave the default settings of Relational Sources, Tables, Keys and
Foreign Keys selected, just click next.

Youll then get the select objects screen:

Expand the xxx_BIPLATFORM schema then scroll down and select S_NQ_ACCT,
S_NQ_DB_ACCT and S_NQ_INITBLOCK and click the > button between the two
windows.

Youll then get the new connection pool window. All of the details are filled out for
you, but Id recommend changing the name from Connection Pool to something like
Usage Tracking Pool

Click Ok to perform the table import. Youll then see the three imported tables in a
new folder in the repository view:

Click the Finish button to save.

Youll then see the new database connection, with its connection pool and the three
tables in the physical layer of the RPD:

At this point I usually rename the database name to something more meaningful
(right click on it and select rename):

Now take a note of the database name Usage Tracking Database and the
connection pool name Usage Tracking Pool, these well need below.
Finally save the RPD using the disk icon in the menu bar

And click ok to check in the changes before saving. When asked, there is no need to
check global consistency.
To enable usage tracking in OBIEE you need to turn it on and specify the database
location details. This is done by editing the NQSConfig.INI file. This will be located in
the following directory:

<obiee_home>/user_projects/domains/bi/config/fmwconfig/biconfig/OBIS
** note the /bi/ directory may be different if you have multiple domains on your server
**
Before editing the NQSConfig.INI file its best to take a backup copy first
First locate the [USAGE_TRACKING] section and change the ENABLE setting to
YES. Ignore the message about the setting being managed by the enterprise
manager.

A few lines further down check the DIRECT_INSERT setting is set to YES it should
be by default. For the record DIRECT_INSERT = YES tells OBIEE to write the usage
stats to a database table, a setting of NO will direct the stats to a file the settings
immediately above this let you specify a file if youd prefer that (never yet come
across anyone who does!)

The next setting is PHYSICAL_TABLE_NAME. This will currently set to the value of:
<Database>.<Catalog>.<Schema>.<Table>;
And need replacing with the full path to the S_NQ_ACCT table as it was imported
into the RPD above:

In this case we only have a database, schema and table the catalog is an optional
extra layer you can have in physical layer, typically when a set of data is sourced
from multiple schemas.
So in my example the full physical table name is:
Usage Tracking Database.DEV_BIPLATFORM.S_NQ_ACCT;
Next just below is the CONNECTION_POOL. Again this is set to a default value of
<Database>.<Connection Pool>; and needs replacing with the actual name, which
in my case is
Usage Tracking Database .Usage Tracking Pool;
Next are two settings which are hashed out by default and are therefore optional. If
you want to use them remove the hash and set this as:
INIT_BLOCK_TABLE_NAME points to the name of the S_NQ_INITBLOCK table, in
my case:
Usage Tracking Database.DEV_BIPLATFORM.S_NQ_INITBLOCK;
And INIT_BLOCK_CONNECTION_POOL which is the connection pool for writing
stats to the S_NQ_INITBLOCK table this can be the same as the main
CONNECTION_POOL setting.
So my settings in this file are:

Save and close the file.

Now you need to perform a full stop and restart of OBIEE, using your normal
stop/start scripts.
You must be very careful with the above settings any typos will result in the BI
Server failing to start and the following error in the obis1-diagnostic.log file:
[nQSError: 47031] Usage Tracking table name and connection pool have
mismatching database components

Once OBIEE has restarted, login and view a few dashboards or reports, then look at
the S_NQ_ACCT table in the database to confirm tracking stats are being recorded:

You should also find that the S_NQ_DB_ACCT table has records too these are the
individual field references in each query. If you have any initblocks in your RPD, then
the S_NQ_INITBLOCK table will have entries as well.
So Usage Tracking is now enabled and all activity by your users will be stored in the
database. What we dont have is any reports. In the second part of this blog Ill look
at creating the subject area and setting up some usage tracking reports.

WELCOME TO OBIEE12C: CONFIGURING

EXTERNAL LDAP AUTHENTICATION PART 1
by Paul Cannon on 1st February 2016 9 comments

When OBIEE 12c is first installed its 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 its 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. Ill be keeping it in this blog.
Weblogic can have multiple security realms and usually its 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 Ill take the simple route
of adding my new LDAP authentication to the factory-installed default myrealm.
Also in this Blog Ill 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. Ill 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). Ive used (objectclass=user)
including the brackets!, but another example Ive used before is (&(cn=*)
(objectclass=user))
User From Name Filter. A default search filter if the All Users Filter cant find the
user details. Ive 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 thats 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). Ive used
(objectclass=group)
Group From Name Filter. A default search filter if the All Groups Filter cant find the
group details. Ive used the default value of &(cn=%g)(objectclass=group))
All of the other settings in this tab Ive 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 Id entered the wrong password as the credential. This particular error is
more common than youd likeif 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 its 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 its 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 cant see any users or groups from your LDAP return to Provider Specific
screen and check through the details youve 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 Ill go through setting up security to give your users different levels of access to
OBIEE based on your LDAP configuration:

WELCOME TO OBIEE12C: CONFIGURING

EXTERNAL LDAP AUTHENTICATION PART 2
by Paul Cannon on 3rd February 2016 9 comments

In part 1 of this blog I covered configuring the Weblogic instance that comes with
OBIEE to allow user authentication against an external LDAP, such as Active
Directory:
http://www.redstk.com/welcome-to-obiee12c-configuring-external-ldapauthentication-part-1/
In this second part well look at assigning permissions to users in the LDAP to control
their access to OBIEE.
By default, all users in the external LDAP will be 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
This is simply because weve setup the authentication but not assigned any security
permissions to go with it and the default security in OBIEE is any authenticated user
is a basic consumer.
To assign security permissions we need to use the Groups from the LDAP and
assign then to Application Roles in OBIEE. OBIEE has three application roles by
default, although you can add more, these being Administrators (who can do
everything), Authors (who can create reports etc) and Consumers (basic read-only
users)
So you need to create groups in your LDAP for each of the Application Roles in
OBIEE, add the appropriate users to their groups in the LDAP then assign the
Groups to the Application Roles in the Enterprise Manager.
Note: You are able to assign individual users to application roles in OBIEE thereby
avoiding the need for groups, but this doesnt seem to work assigning an individual
user to the Administrators role does not give then Administrator privileges the
manual implies this can be done, although it says its not recommended I wonder if
theyve disabled this but not removed the option!
So in my LDAP I have set-up three Groups and assigned various users to them:

Back in the Enterprise Manager click on the Target Navigation icon

Expand Business Intelligence and click on biinstance

When the biinstance window appears click in the Business Intelligence Instance
drop-down menu and select Security -> Application Roles:

In this screen first check that the obi application is selected, then you will see the
available application roles:

In this screen you can create new Application Roles to suite your security
requirements, however for now Im going to continue with the default three roles.
With the BI Service Administrator role highlighted you can see it has one member
Weblogic. So to this Im going to add by BI_Admin group from the LDAP. Click the
Edit icon above the list.

Then click the +Add icon above the members list at the bottom.

In the Add Principal screen change the Type drop-down menu to Group, enter the
first few characters of the Group name in the Principal Name starts with field and
click the grey arrow after the display name field.
This returns a list of all Groups matching those characters. Click on the required one
and click OK to add it to the Role:

Click OK to save the role and return to the Application Roles screen where you will
see this Group in the members list.
Now repeat this for the other Application Roles, adding in the appropriate groups.
When you get to the BI Consumer role youll see this has an extra role already
assigned authenticated-role. This is a special role that allows anyone who has a
valid user-id/password in any of the LDAP providers to be able to login to OBIEE with
basic user permissions.

If you dont want this i.e. you want to restrict access to just users in a specific BI
User group (such as BI_Users in my LDAP), then you need to delete this role from
the BI Consumers Application role.

All of these group/role changes are effective immediately, so you can ask your users
to try login and check they have the correct permissions.
My user Paul is in the BI_Admin group, so has the Administration link and can
create all types of content:

Simon is a BI Author, so can create all types on content, but does not have the
Administration link:

Sarah is a basic user who can see dashboards & reports but can only create jobs
and actions:

Pete is a user in the LDAP, but does not belong to any of my BI Groups and therefore
gets the access prohibited message when he tries to login:

So there it is, OBIEE configured to use an external LDAP for authentication. The
next logical step now is to enable Single Sign On, but thats another blog for another
day!

Enjoy!