Posts Tagged ‘Security’

Managing Security Authorizations

February 9th, 2011 2 comments

A very common question when it comes to SAP BusinessObjects is:  How should I manage my SAP BusinessObjects security authorizations?

Although that is an extremely broad topic, today I want to discuss the issue of leveraging an external corporate directory to manage user authorizations.

NOTE:  It's important to remember that only the
user/group membership gets delegated out.
The group/object rights assignments must still be
performed by the BI administrator.

In most large organizations, there is a security team which manages users ids and user groups.  These users and groups are typically stored in a Corporate Directory such as LDAP, Windows Active Directory, etc.

The userid and password from the Corporate Directory is the method through which users are able to authenticate themselves (via secLDAP, secWinAD, secSAP, etc.)  So the question naturally arises:  Should I manage all my authorizations through groups managed via external security solutions?

The answer for your organization will depend on the answers to the following questions:

  1. How much cooperation is there between the BI Administrator and the Corporate Directory Team?
  2. How quickly can new groups be added to the Corporate Directory?
  3. How many groups would you need to add to the Corporate Directory to manage all the BI security scenarios?
  4. Do I want to delegate the bulk of my BI security management to the Corporate Directory Team?

There are pros and cons to any software implementation and the right solution must be made according to the culture and policies that fit your organization.

Leveraging External Security Exclusively

In certain cases the Corporate Directory team may be able to create and manage all the groups BI Administrators will need for security within the Corporate Directory and they are able to assign the correct security when a user is provisioned.

The advantages include:

  • Single location for user/group membership
  • Delegated Model – less for the BI administrator to manage

The disadvantages include:

  • Delegating group creation and user group membership

This model has been successfully implemented at a large insurance company with 500+ BusinessObjects-related groups mapped to an external Active Directory server.

Leveraging A Mixed Model

At a high-level the mixed model leverages:

  1. External security management for course grain security
  2. Internal secEnterprise groups for fine grain security

I recommend course grain security to manage which users should have access to the BI environment (e.g. NY Users, Georgia Users, Reporting Users, etc.)  Once the user has been imported into the system, we can fine tune their access via fine grain security.

NOTE:  We refer to these as Data Access Roles because
the users in the Georgia Users group only get to see Georgia reports
and the corresponding Georgia data.

Administrators can use internal secEnterprise groups for managing fine grain security.  You can create roles such as:  WebI Viewer, WebI Developer, InfoView user, which can control the product specific rights allowed to the users of that role.

NOTE:  We refer to these as Entitlement Roles because
the users in the WebI Viewer group are allowed limited
application functionality.

The advantages include:

  • A clean delineation between the Corporate Directory and the BI Security
  • Balance between corporate control and system flexibility

The disadvantages include:

  • Security being managed in two places
  • The need for the BI Administrator to be notified of fine grain role changes so users can be remapped

It’s hard to say for sure whether the Mixed Model tends to work better in most organizations than the delegated model.  You need to determine which model will work best for your organization.  What I can say is that  both models allow for extremely flexible deployments amongst the multitude of different scenarios that I have come across.

Don’t Forget

Regardless of which model you use there is something you should know…

One organization which had communication problems with their LDAP server and as a result of a synchronization problem, most of their users were deleted from their BusinessObjects environment.  Users – Inboxes – Personal Folders.   Gone.

There is one extremely important rule when leveraging an external Corporate Directory.  Make sure that every external user in your BusinessObjects environment is mapped to at least one secEnterprise group.  This will guarantee the the mapped users id will never accidently be deleted from the system.  For Java SDK samples around user management, go here.

«Good BI»

BusinessObjects Security Quiz

February 7th, 2011 2 comments

Do you understand BusinessObjects security?

Granted Yes?
Denied No?
Not Specified Not Sure?

Well now is your chance to prove it.  Show us how good you really are.

My son always loves to test me with hypotheticals.

Dad can I have permission to see that R-rated movie?… No.

What if I take the dog for a walk?…  No.

… What if I mow the grass all summer?…  No.

… What if I get A’s for the rest of my life?…  No.

Fortunately getting granted access to InfoObjects within SAP BusinessObjects is a little more straight forward.

Quiz Show

To access the sample 24 scenario quiz click on the picture below:

Click here to start the Quiz


So how did you do?  Get them all right?  Yes?  Then it’s time to get certified!

I’ll admit that regardless of how many times I go through this quiz there are always one or two that trip me up.

You can also download an offline copy of the quiz here:

Have a great week!

«Good BI»

Real World Guide to Setting up Kerberos

May 14th, 2009 13 comments

[UPDATED 10/1/2010 – See Below]

I was recently involved with the configuration of Kerberos with a customer and as I was reading about it in the documentation, I realized that there were a number of areas that lacked the clarity I needed to understand what information SAP BusinessObjects needed to know about my environment.

The Service Account

Permissions are one of the first areas that might trip you up.  In my case I used the same user for the service account that you use for configuring the SIA and that has read access to Active Directory.  It will simplify things for you.  You should also make the service account a local admin on the Business Objects Enterprise Servers.  The service should be a non-dialog user.

Step 1 – Create the SPN

As a Domain Admin, Create the SPN for all of your CMS Servers.  You will need to create an SPN for the fully qualified domain name, as well as the short name.  In my case I have two machines which are running a CMS on each.  I will refer to these machines as cms1 and cms2.


SETSPN.exe -A BOBJCentralMS/cms1 serviceaccountname
SETSPN.exe -A BOBJCentralMS/cms1.mydomain.local serviceaccountname
SETSPN.exe -A BOBJCentralMS/cms2 serviceaccountname
SETSPN.exe -A BOBJCentralMS/cms2.mydomain.local serviceaccountname

(In the above example:  host – cms1 and cms2, domain – mydomain.local, username  – serviceaccountname)

Step 2 – Confirm the SPN

In the Windows Server Support tools you will find lfifde.exe.  You can use this to application to confirm that the SPN has been correctly associated with the username.


ldifde -d "dc=mydomain,dc=local" -r "servicePrincipalName=BOBJCentralMS*" -p subtree -l "dn,servicePrincipalName" –f C:ldifdeoutput.txt

When you run the command, you should see something like:

Connecting to "adc1.mydomain.local"
Logging in as current user using SSPI
Exporting directory to file C:ldifdeoutput.txt
Searching for entries...
Writing out entries..
1 entries exported

When you open C:ldifdeoutput.txt, you should see something like:

dn: CN=mydomain, serviceaccountname,OU=Service Accounts,OU=Accounts, DC=mydomain,DC=local
changetype: add
servicePrincipalName: BOBJCentralMS/cms1.mydomain.local
servicePrincipalName: BOBJCentralMS/cms1
servicePrincipalName: BOBJCentralMS/cms2.mydomain.local
servicePrincipalName: BOBJCentralMS/cms2

Important Note: Keep track of the way that serviceaccountname is spelled within the first line of C:ldifdeoutput.txt.  You will need to use it later and it IS case sensitive.

Step 3 – Create Files for Kerberos

On your CMS Servers (cms1 & cms2 in this example) create two files for Kerberos.  The documentation indicates that you should be able to control the locations of the files using your java options.  I was unable to get Kerberos to work unless they were in the default location of C:WINNT, therefore I made a C:WINNT directory for the files.

File 1: krb5.ini

default_realm = MYDOMAIN.LOCAL
dns_lookup_kdc = true
dns_lookup_realm = true
default_domain = MYDOMAIN.LOCAL

NOTE:  If you want to query a particular domain controller you should be able to specify it on the line kdc=, however if AD is set up correctly then your domain name should resolve to the nearest domain controller.  You may want to check the configuration by typing “nslookup mydomain.local” at a command prompt.

File 2: bscLogin.conf { required debug=true;

[UPDATE: 10/1/2010]
Notice that debug=true…this means that when you try to authenticate, you should get a message in the log.  If authentication is failing on you…look in the log to make sure that you are seeing an entry for the attempt.  If you do not see a login, then bscLogin.conf is not even getting loaded, and there is something misconfigured.  This is a great hint for troubleshooting later.

Step 4 –Rights to the Service Account

Next we need to grant the Service Account rights to act as part of the operating system.  These 7 steps walk you through the process.

  1. Click Start > Control Panel > Administrative Tools > Local Security Policy.
  2. Expand Local Policies, then click User Rights Assignment.
  3. Double-click Act as part of the operating system.
  4. Click Add.
  5. Enter the name of the service account you created, then click OK.
  6. Ensure that the Local Policy Setting check box is selected, and click OK.
  7. Repeat the above steps on each machine running a BusinessObjects Enterprise.

[UPDATE: 10/1/2010]

Step 4b – Missing STEP

  1. Set your java options to look in your C:winnt folder.
  2. Go to start->Tomcat->Tomcat configuration
  3. Go to the java options tab and set the following java options:
  4. Hit OK and restart Tomcat

Thanks everyone for your feedback and pointing out this missing step.


Step 5 – Testing Kerberos

We can now test Kerberos with the kinit.exe utility.   An example of this command for a service account called servact would be:

C:Program FilesBusiness Objectsjavasdkbinkinit.exe servact@TESTM03.COM Password

Syntax Example:

<InstallDirectory>Business Objectsjavasdkbinkinit.exe serviceaccountname@MYDOMAIN.LOCAL password

IMPORTANT NOTE: If you still have a problem, ensure that the case you entered for your domain and service principal name match exactly with what is set in Active Directory.  The easiest way to find the proper casing for the account is to look at the C:ldifdeoutput.txt file we created in Step 2 – Confirm the SPN.

Step 6 – Configuring Active Directory

We  can configure the Active Directory Plug-in within SAP BusinessObjects.

  1. Launch the CMC (http://yourserver:8080/CmcApp) and go to the Authentication section of the CMC (Central Management Console).
  2. Double-click on Windows AD
  3. Select “Enable” Windows AD
  4. Click the AD Administration Name.
    • For the user enter the NTLM name…for example: MYDOMAINserviceaccountname
    • For the password enter the password
    • For the Default AD Domain Enter the full domain name in all caps: MYDOMAIN.LOCAL
    • Click update.
  5. Add a Mapped AD Member Group by typing the group name in the box and clicking add…for example: MYDOMAINBOEUsers
  6. Under Authentication Options:
    1. Click Use Kerberos authentication and make sure the Cache Security Context is checked.
    2. For the Service Principal name enter the service account name with the casing exactly as it appears in the C:ldifdeoutput.txt created in step 2 followed by an @ sign followed by the domain in all caps.  EXAMPLE: serviceaccountname@MYDOMAIN.LOCAL
    3. Check the box that says Enable Single Sign on for selected authentication mode.
  7. Under AD Alias Options, configure the options here however are appropriate for your environment.
  8. Under Attribute Binding Options, we need to check both boxes
  9. Under AD Group Graph, configure as desired
  10. Under On-demand AD Update, configure as desired
  11. Click Update

Step 7 – Configuring Tomcat

Configure tomcat to use WinAD as the default Authentication mechanism for infoview:

  1. Open <Install Directory>Tomcat55webappsInfoViewAppWEB-INFweb.xml in your favorite text editor.
  2. Search for authentication.default and change the value to: secWinAD
  3. Use Central Configuration Manager (CCM) to restart Tomcat.


Please let me know if this guide was useful.  Setting up Kerberos with SAP BusinessObjects can be tricky and it’s only when I hear from you that I know whether or not these posts are hitting the mark.

«Good BI»

Row-level Security Trick with WebIntelligence

November 7th, 2007 8 comments

Can I Get Row-level Security with WebIntelligence and Still Avoid a Document Refresh?


As a follow-up to my post yesterday I wanted to step back and say that normally you do want to handle row-level security from within the semantic layer. The problem is that you can’t get the benefit of the speed of data that comes from historical instances without requiring each user to run the report for themselves.

I did discover that you can provide the same type of security within WebIntelligence. WebIntelligence also has a function which also returns the name of the current user. The function is CurrentUser.

1. The first thing I need to do is build the semantic layer to include my security table.

Universe View

2. Next, create a new variable which returns a 1 or 0 based on whether or not the user should see the data or not.

=If(CurrentUser()=”Administrator” Or CurrentUser() = [Username];1;0)

Define the Varliable

3. Create the report and apply the filter to the entire report or to the appropriate data block.

Report View

4. Here is what Ron’s sees, when he looks at an historical instance of the WebIntelligence report.

Ron's view of the same instance

Notice that the Data Summary on the left hand side shows me that there were 71 records but even so, the restricted user ron is only allowed to 3 of the 71.

The beauty of this is that when I look at this data via BusinessObjects LiveOffice, I will see exactly the same restrictions enforced.

REMEMBER: Normally if you need row-level security, then just apply it to the universe. IF, however, you need row-level security on historical instances without requiring them to be refreshed, then use this great trick.

Row-level Security Trick with Crystal Reports

November 6th, 2007 9 comments

Row-level Security on Scheduled Instances Without the Use of Business Views

When I realized that I could get row-level security on scheduled instances without using Business Views I thought, I have to share this with everyone. When you schedule a report, the engine retrieves all the data based on the credentials of the user running the report. If I now want to get row-level security, I must apply security within the report at “format time” or view time. In other words, I must apply the security to the formatting of the report.

The great thing about this is that it not only applies to viewing reports, but also to accessing those view reports through other tools such as Live Office.
Situation: Allow an administrative user to run a report for all users and then apply row-level security at view time but do not leverage Business Views.

1. Make sure you have some type of method for determining row level security. In my case I created a Customer_Security table and added some restrictions so that certain users were allowed to see the data for certain countries. In my case I’m using SQL Server together with some Xtreme Customer data. Here you can see some sample data and the contents of the Customer_Security table:

SQL Server Setup

2. Next, I need to create a Crystal Report which links the customer table to the customer security table and delivers back the expected results. When I created the report I used an outer join since no ever country in the customer table has an associated security setting for it.

Join Tables in Crystal Reports

3. Next I want to create a suppression formula on the row that contains data that restricted users can’t see. In this case I used the following suppression formula:

CurrentCEUserName = Uppercase({Customer_Security.Username}))

This TRUE if the user viewing the report is NOT the administrator or NOT a matching security value. This formula will cause the country records they do not have access to see to be hidden from view.

WARNING: In this example, I am not doing any special calculations, but if you do need to do summaries or groupings, I recommend that you set each value to a formula and within the formula you set values equal to blank (”) or 0 if the row should not be seen by the end user.

Show formula

4. Now I can publish this report to BusinessObjects Enterprise and schedule the report to run as administrator and then view the report as ron. When I do this, I will expect to see all the records when logged in as administrator and only England, France and Germany records when logged in as ron.

Let’s schedule the report:

Schedule the report in BOE

Crystal Reports applies formatting a view time, therefore it will evaluate the suppression formula for the individual running the report and apply it to the report instance. In this case the countries that ron is not allowed to see will be suppressed, even though they were retrieve with the original schedule instance.

Here is a view of what the administrator sees:

Administrator View (All Records)

Here is what the restricted user ron sees:

Ron's view of the same instance

We did not have to reschedule the report for ron, yet we were still able to achieve row level security from a scheduled instance! Do you know what happens now when I view this report from within Live Office? The suppression formulas are still applied at run-time and therefore the view security remains!

Here is what I will see from within Excel.

Live Office View

You can see here that I am accessing the Latest Instance and yet, even though the latest instance contains ALL RECORDS for the report, Live Office observes that suppression and resticts what the restricted user ron can see.

CONCLUSION: You can obtain row-level security from within Business Objects by using CEUserName and an external security table together with suppression formulas that are evaluated at run-time.