Security For BO

Security for Business Objects
BusinessObjects 6.5
Windows and UNIX

2 Security for Business Objects
Copyright Copyright © 2004 Business Objects. All rights reserved.

If you find any problems with this documentation, please report them to Business Objects in
writing at documentation@businessobjects.com.
Trademarks Business Objects, the Business Objects logo, Crystal Reports, and Crystal Enterprise are
trademarks or registered trademarks of Business Objects SA or its affiliated companies in the
United States and other countries. All other names mentioned herein may be trademarks of their
respective owners.
Use restrictions This software and documentation is commercial computer software under Federal Acquisition
regulations, and is provided only under the Restricted Rights of the Federal Acquisition
Regulations applicable to commercial computer software provided at private expense. The use,
duplication, or disclosure by the U.S. Government is subject to restrictions set forth in
subdivision (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at 252.227-
7013.
Patents Business Objects owns the following U.S. patents, which may cover products that are offered
and sold by Business Objects: 5,555,403, 6,247,008 B1, 6,578,027 B2, 6,490,593 and
6,289,352.
Security for Business Objects 3
Contents
Information resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Useful addresses at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 1 Overview of Security in Business Objects 13

How this guide is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Part I Planning a Secure Environment
Chapter 2 Common Network and System Security Options 21

Securing web browsers and web servers . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 3 Choosing Appropriate Authentication and Authorization 37

Sessions and login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authentication modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authentication sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 4 LDAP and External User Management Choices 51

What is LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
LDAP directories and queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
LDAP and Business Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
External user management systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 5 Optional Third-Party Security Management Systems 59

Netegrity SiteMinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Contents
Part II Implementing a Secure Environment
Chapter 6 Preparing Your Environment 65

Setting up firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Implementing a deported application server . . . . . . . . . . . . . . . . . . . . . . . . 70
Setting up a reverse proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Configuring security on Windows 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Installing and configuring the BusinessObjects 6.5 suite . . . . . . . . . . . . . . 78
Activating SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Setting up the Business Objects repository then creating users and groups 88
Chapter 7 Configuring LDAP and External User Management 91

Mapping LDAP users to Business Objects . . . . . . . . . . . . . . . . . . . . . . . . . 93
Customizing LDAP queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
LDAP restrictions for specific Business Objects applications . . . . . . . . . . . 98
Configuring Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Configuring Sun Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Chapter 8 Configuring Third-Party Security Management Systems 105

Configuring SiteMinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Chapter 9 Using the Security Configuration Tool 119

Launching the Security Configuration Tool . . . . . . . . . . . . . . . . . . . . . . . . 122
Setting the authentication mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Setting the authentication source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Configuring LDAP connection parameters . . . . . . . . . . . . . . . . . . . . . . . . 132
Contents
Maximizing Your Information
Resources
preface
Overview
Information, services, and solutions
The Business Objects solution is supported by thousands of pages of
documentation, available from the products, on the Internet, on CD, and by
extensive online help systems and multimedia.
Packed with in-depth technical information, business examples, and advice on
troubleshooting and best practices, this comprehensive documentation set
provides concrete solutions to your business problems.
Business Objects also offers a complete range of support and services to help
maximize the return on your business intelligence investment. See in the
following sections how Business Objects can help you plan for and successfully
meet your specific technical support, education, and consulting requirements.
Maximizing Your Information Resources

Information resources
Whatever your Business Objects profile, we can help you quickly access the
documentation and other information you need.
Where do I start?
Below are a few suggested starting points; there is a summary of useful web
addresses on page 10.
Documentation Roadmap
The Documentation Roadmap references all Business Objects guides and
multimedia, and lets you see at a glance what information is available, from
where, and in what format.
View or download the Business Objects Documentation Roadmap at
www.businessobjects.com/services/documentation.htm
Documentation from the products

You can access electronic documentation at any time from the product you are
using. Online help, multimedia, and guides in Adobe PDF format are available
from the product Help menus.
Documentation on the web

The full electronic documentation set is available to customers with a valid
maintenance agreement on the Online Customer Support (OCS) website at
www.businessobjects.com/services/support.htm
Buy printed documentation

You can order printed documentation through your local sales office, or from the
online Business Objects Documentation Supply Store at
www.businessobjects.com/services/documentation.htm
Search the Documentation CD

Search across the entire documentation set on the Business Objects
Documentation CD shipped with our products. This CD brings together the full set
of documentation, plus tips, tricks, multimedia tutorials, and demo materials.
Order the Documentation CD online, from the Business Objects Documentation
Supply Store, or from your local sales office.
Information resources
Multimedia
Are you new to Business Objects? Are you upgrading from a previous release or
expanding, for example, from our desktop to our web solution? Would you like to
see a demonstration that shows how to use some of our more complicated or
advanced features? Access our multimedia Quick Tours or Getting Started
tutorials from the product, the Online Customer Support (OCS) website, or the
Documentation CD.
How can I get the most recent documentation?

You can get our most up-to-date documentation via the web. Regularly check the
sites listed below for the latest documentation, samples, and tips.
Tips & Tricks

Open to everyone, this is a regularly updated source of creative solutions to any
number of business questions. You can even contribute by sending us your own
tips.
www.businessobjects.com/forms/tipsandtricks_login.asp
Product documentation
We regularly update and expand our documentation and multimedia offerings.
With a valid maintenance agreement, you can get the latest documentation – in
seven languages – on the Online Customer Support (OCS) website.
Developer Suite Online

Developer Suite Online provides documentation, samples, and tips to those
customers with a valid maintenance agreement and a Developer Suite license
via the Online Customer Support (OCS) website.
Send us your feedback

Do you have a suggestion on how we can improve our documentation? Is there
something you particularly like or have found useful? Drop us a line, and we will
do our best to ensure that your suggestion is included in the next release of our
documentation: documentation@businessobjects.com
NOTE
If your issue concerns a Business Objects product and not the documentation,
please contact our Customer Support experts. For information about Customer
Support visit: www.businessobjects.com/services/support.htm

Services
A global network of Business Objects technology experts provides customer
support, education, and consulting to ensure maximum benefit to your business.
How we can support you?

Business Objects offers customer support plans to best suit the size and
requirements of your deployment. We operate three global customer support
centers:
• Americas: San Jose, California and Atlanta, Georgia
• Europe: Maidenhead, United Kingdom
• Asia: Tokyo, Japan and Sydney, Australia
Online Customer Support

Our Customer Support website is open to all direct customers with a current
maintenance agreement, and provides the most up-to-date Business Objects
product and technical information. You can log, update, and track cases from this
site using the Business Objects Knowledge Base.
Having an issue with the product?

Have you exhausted the troubleshooting resources at your disposal and still not
found a solution to a specific issue?
For support in deploying Business Objects products, contact Worldwide
Customer Support at: www.businessobjects.com/services/support.htm
Looking for the best deployment solution for your company?

Business Objects consultants can accompany you from the initial analysis stage
to the delivery of your deployment project. Expertise is available in relational and
multidimensional databases, in connectivities, database design tools,
customized embedding technology, and more.
For more information, contact your local sales office, or contact us at:
www.businessobjects.com/services/consulting.htm
Looking for training options?

From traditional classroom learning to targeted e-learning seminars, we can offer
a training package to suit your learning needs and preferred learning style. Find
more information on the Business Objects Education website:
www.businessobjects.com/services/education.htm
Services
Useful addresses at a glance
Address Content
Business Objects Documentation Overview of Business Objects documentation. Links
to Online Customer Support, Documentation Supply
www.businessobjects.com/services/ Store, Documentation Roadmap, Tips & Tricks,
documentation.htm Documentation mailbox.
Business Objects Documentation Feedback or questions about documentation.

mailbox
documentation@businessobjects.com
Product documentation The latest Business Objects product
documentation, to download or view online.
www.businessobjects.com/services/
support.htm
Business Objects product information Information about the full range of Business
Objects products.
www.businessobjects.com
Developer Suite Online Available to customers with a valid maintenance
agreement and a Developer Suite license via the
Online Customer Support (OCS) website. Provides
www.techsupport.businessobjects.com
all the documentation, latest samples, kits and tips.
Knowledge Base (KB) Technical articles, documents, case resolutions.
Also, use the Knowledge Exchange to learn what
www.techsupport.businessobjects.com challenges other users – both customers and
employees – face and what strategies they find to
address complex issues. From the Knowledge
Base, click the Knowledge Exchange link.
Tips & Tricks Practical business-focused examples.
www.businessobjects.com/forms/
tipsandtricks_login.asp

Address Content
Online Customer Support
www.techsupport.businessobjects.com Starting point for answering questions, resolving

issues.
www.businessobjects.com/services Information about registering with Worldwide

Customer Support.
Business Objects Education Services The range of Business Objects training options and
modules.
education.htm
Business Objects Consulting Services Information on how Business Objects can help
maximize your business intelligence investment.
consulting.htm
Useful addresses at a glance

About this guide

This guide explains how security works in BusinessObjects 6.5, and how to
configure your Business Objects system so that it operates within a secure
environment.
Audience
This guide is intended for administrators and others responsible for security in a
Business Objects system.
Conventions used in this guide

The conventions used in this guide are described in the table below.
Convention Indicates
This font Code, SQL syntax, computer programs. For
example: @Select(Country\Country Id).
This font is also used for all paths, directories,
scripts, commands and files for UNIX.
Some code Placed at the end of a line of code, the symbol ( )
more code indicates that the next line should be entered
continuously with no carriage return.
$DIRECTORYPATHNAME The path to a directory in the Business Objects
installation/configuration directory structure. For
example:
• $INSTALLDIR refers to the Business Objects
installation directory.
• $LOCDATADIR refers to a subdirectory of the
BusinessObjects installation directory called
locData.

Overview of Security in Business
Objects
chapter
Overview
This guide explains how security works in BusinessObjects 6.5, and how to
configure your Business Objects system so that it operates within a secure
environment.
Business Objects architecture addresses the many security concerns that affect
today’s businesses and organizations. The current release supports features
such as distributed security, SSO (single sign-on), and third-party authentication
for protection against unauthorized access.
NOTE
This guide replaces the security-related information in the version 6.5 Installation
and Configuration Guide.
How security fits into your implementation of BusinessObjects 6.5

Setting security is an integral part of the installation and configuration of the
BusinessObjects 6.5 suite. The core installation and configuration procedures
are covered in the Installation and Configuration Guide.
Before installing BusinessObjects 6.5

In general, you implement operating system, network, and system security
mechanisms, as well as external security management systems (such as
Netegrity SiteMinder) before installing the BusinessObjects 6.5 suite.
After installing BusinessObjects 6.5

Once the suite is installed, you create the Business Objects repository then
create users/groups and define their access rights. You then use the Business
Objects Security Tool to configure security on the Business Objects system.
Overview of Security in Business Objects

What’s the bare minimum in terms of security?

What you must do
At a minimum, you must:
• Secure your web servers
• If you are using Windows 2003, define security-related operating system
settings
• Set up a secure Business Objects environment by creating a repository and
defining access rights
• Set an authentication mode and source for the cluster
What you should do

Business Objects recommends adding the following security features to your
Business Objects system:
• firewalls
• reverse proxies
Additional security options

You may also want to consider adding the following, particularly for large and
complex systems:
• A third-party security management system
This is usually combined with SSO (single sign-on)
• An external LDAP-based user management system
How this guide is organized

This guide is divided into two parts:
• Part I: Planning a Secure Environment
This part explains how a secure environment works, and how all the pieces fit
together. It gives you the information you need to make intelligent choices that
are appropriate for your particular Business Objects system.
• Part II: Implementing a Secure Environment
This part explains what you actually do in order to implement the choices you
have made.
At the beginning of each implementation section, a table indicates where you are
in the security implementation process. Optional steps are in red:
Where you Step in overall security implementation process Page

are now
D 1. Set up your configuration’s firewalls. 67
Set up a reverse proxy. 74
2. For Windows 2003, configure Windows operating 77
system security.
3. Install and configure the Business Objects suite. 78
Activate SSL. 79
4. Create the repository. 88
5. Create users/groups and assign them rights. 88
Set up and configure LDAP and external user 91
management.
Configure third-party security management 105
system.
6. Use the Security Configuration Tool to: 119
- select authentication mode
- select authentication and authorization source
- configure and customize LDAP connections
Following is a brief description of each section in the guide.

Planning a secure environment

Network and system security options
This chapter describes common network security options. This includes:
• web browsers and web servers
• encryption
• firewalls
• reverse proxies
This topic starts on page 21.
Choosing appropriate authentication and authorization

This chapter explains authentication and authorization, how they work, and the
choices available to you. This topic starts on page 37.
LDAP and external user management choices

This chapter describes how an LDAP (Lightweight Directory Access Protocol)
directory works with Business Objects.
It describes supported LDAP-based external user management systems
(Microsoft Active Directory® and Sun Directory Server®) and how they work with
Business Objects. Managing Business Objects user identities in this type of
system allows you to store user information for all your enterprise applications—
including the Business Objects suite—in a single corporate directory.
Third-party security management choices

This chapter explains how third-party security management systems work with
the BusinessObjects 6.5 suite. These systems let you authenticate and authorize
users in one centralized location, with maximum security. One supported system,
Netegrity Siteminder®, is presented.
Implementing a secure environment

Setting up firewalls
This section explains how to set up firewalls within a Business Objects
deployment. This topic starts on page 67.
How this guide is organized

Setting up reverse proxies

This section explains how to set up reverse proxies within a Business Objects
deployment. This topic starts on page 74.
Configuring operating system security on Windows 2003

Installing and configuring the BusinessObjects 6.5 suite

Now that you have set up your firewalls and planned your overall Business
Objects deployment, you can install the BusinessObjects 6.5 suite. See the
Installation and Configuration Guide (Windows or UNIX) for instructions.
Creating the Business Objects repository, then creating users and groups
Security within the Business Objects system depends upon the repository, which
stores Business Objects resources such as universes and documents, as well as
the access rights defined for users and groups. This topic starts on page 88.
Configuring LDAP and external user management

This chapter explains how to configure an external user management system to
work with Business Objects. This includes:
• mapping between LDAP users and Business Objects
• customizing LDAP queries
Configuring third-party security management systems

This chapter explains how to configure a third-party security management
system to work with Business Objects. This topic starts on page 105.
Using the Security Configuration Tool

You use the Security Configuration Tool to:
• select authentication mode
• select authentication and authorization source
• configure and customize LDAP connections
This chapter explains how to use the Security Configuration Tool, which
completes the setup of security for your Business Objects system.

Planning a Secure
Environment
part
Common Network and System
Security Options
chapter
Overview
This chapter describes common network security options. This includes:
• securing web browsers and web servers
• SSL
• encryption
• firewalls
• reverse proxies
Common Network and System Security Options

Securing web browsers and web servers

Although the Internet and web-based systems are increasingly popular due to
their flexibility and range of functionality, they operate in an environment that can
be difficult to secure.
It is possible, of course, to isolate the Business Objects network from all means
of access, such as modem lines and outside network connections. This is the
most secure way to protect a network, but it also prevents the network’s users
from easily contacting other networks and external resources.
If you deploy Business Objects with a connection to outside networks, a secure
environment starts with two key areas:
• web browser to web server
• web server to Business Objects
Web browser to web server

When sensitive data is transmitted between the web browser and the web server,
security measures usually involve making sure that:
• the communication of data is secure
• only valid users retrieve information from the web server
These tasks are typically handled by web servers through various security
mechanisms, such as Windows authentication.
You must secure communication between the web browser and the web server
independently of Business Objects. For details, refer to your web server
documentation.
Web server to Business Objects

You secure this area by using a firewall. Firewalls are commonly used to secure
the area of communication between the web server and the rest of the corporate
intranet (including Business Objects).
Firewalls are discussed on page 28.
Securing web browsers and web servers

SSL
SSL (Secure Sockets Layer) is the most popular client-server encryption
mechanism used in web-based systems. It provides a secure, encrypted
connection between the server and client machine when they connect via the
Internet or other exposed network. Most popular free and commercial web
servers provide SSL encryption.
SSL sessions start with the SSL handshake, which is an exchange of messages
in which the server uses public keys to identify (authenticate) itself to the client.
The server and client then together create symmetric keys for encryption and
other security measures used during the subsequent session.
The server must have a digital certificate. The validity of the digital certificate is
signed by a CA (Certificate Authority).
The certificates used by SSL are defined in the X.509 standard issued by the
International Telecommunications Union (ITU). Among the items contained in an
X.509-compliant digital certificate are:
• Certificate owner’s name
• Certificate issuer’s name
• Owner’s public key
• Issuer’s signature
• Valid dates

Advantages and disadvantages of SSL

SSL provides major benefits over most other encryption or data protection
schemes:
• Authentication certificates permit positive identification of the server through
the exchange of certificates that have been validated by a certificate authority.
Only a valid key on the client can decrypt the data.
• Transaction validation prevents data from being modified between the sender
and the receiver. Changes in the data invalidate the authentication code, and
the receiver is alerted to the fact that the data has been modified.
There are, however, some disadvantages to using SSL. For example, network
performance may decrease slightly, and SSLs must be renewed and updated
from public authorities. In addition, SSL requires additional CPU power on the
web server and this can impact performance.
How SSL connections work

Creating and using a secure SSL connection is a simple process, especially from
the client standpoint. The process, similar to that of a public-key encrypted
session, is as follows:
1. The browser sends a secure HTTP request to the server. A secure HTTP URL
begins with https instead of the standard http.
2. The server passes its certificate to the browser.
3. The browser checks the certificate for validity. If the certificate has expired or
its authority is not trusted, the browser prompts the user to decide whether or
not to accept the certificate.
4. If the certificate is valid and from a trusted authority, the browser generates a
set of random numbers, encrypts them using the server’s public key, and
passes them to the server. These numbers are used to encrypt all further
communications.
There is generally an indication in the browser that a secure transaction is taking
place. For example, in Netscape Navigator, the key in the lower-left-hand corner
is whole, while for non-secure transactions, the key appears “broken.”
With HTTPS, applet communications are also secure because they use the same
path as HTML pages.
SSL
Encryption
Encryption means that data transmitted over a network is translated into a secret
code. You cannot read an encrypted file unless you have access to a key or
password that allows you to decrypt it. It is the best way to achieve data security.
When data is not encrypted it is called plain text, and when it is encrypted, it is
called cipher text.
There are two primary methods of encrypting data:
• Symmetric-key cryptography
• Public-key cryptography
Symmetric-key cryptography
Symmetric-key cryptography is the simpler of the two methods. It uses the same
key to encrypt and decrypt the data. The sender gives the data and the key to the
encryption engine, which encrypts the data and sends it to the receiver. The
receiver passes the encrypted data and key to the decryption engine, which runs
the process in reverse.
The problem with doing this over the network is that, at some point, the key used
to encrypt and decrypt the data has to be exchanged. Because the person
receiving the key doesn’t already have the key, transmission of the key can’t be
encrypted. A third party could theoretically intercept the unencrypted key and use
it to decrypt (and listen in on or disrupt) any later communications that use that
key.
Public-key cryptography
Public-key cryptography solves the problem of key exchange by using two keys,
one public and one private:
• The public key is available to anyone who wants to send encrypted messages
or data to you.
• The private key stays private and is used to decrypt data encrypted with the
public key.
Data encrypted with the public key can not be decrypted with it and can only be
decrypted through the use of your private key. The process of public-key
encryption works like this:
1. To begin a secure session with a server, a browser requests the server’s
public key.
2. The server sends its public key to the browser.

3. The browser receives the server’s public key, encrypts a message using the
key, and sends the message to the server.
4. The server receives the encrypted message and decrypts it using its private
key.
Note that in Step 2, the communication is not yet secure, just like in symmetric-
key cryptography. Someone could intercept B’s unencrypted public key as it
makes its way to A. The difference is that the symmetric key can be used to
decrypt the encoded data. But a public key can only be used to encrypt data.
Someone who intercepted B’s public key would only be able to send secure
messages to B, not decrypt A’s subsequent messages to B.
Most encryption schemes are actually a combination of symmetric-key and
public-key encryption. Although more secure, public-key encryption uses a
complex encryption algorithm. Symmetric-key encryption is much faster and
cheaper. Public-key encryption is used to establish the secure connection where
a randomly generated symmetric key can be exchanged, and the rest of the
transaction is encrypted by the quicker symmetric-key encryption.
Encryption
Firewalls
For most 3-tier Business Objects extranet and intranet deployments, a corporate
intranet protected by double firewalls is highly recommended. For specific
intranet/extranet deployment information, see Deploying the Business Objects
System.
What is a firewall?
A firewall can be a router, a personal computer, a host, or a collection of hosts,
set up specifically to shield a site or subnet from protocols and services that can
be abused from hosts outside the subnet. It does this by implementing a set of
rules which can be configured. A firewall rule looks like this:
Authorize incoming TCP connections to <Host address> on <port>
A firewall can greatly improve network security and reduce risks to hosts on the
subnet by filtering inherently insecure services. As a result, the subnet network
environment is exposed to fewer risks because only selected protocols can pass
through the firewall.
A firewall also allows you to control access to site systems. For example, some
hosts can be made reachable from outside networks whereas others can be
effectively sealed off from unwanted access. A site can prevent outside access
to its hosts except for special cases such as mail servers or information servers.
Firewalls are also used to secure the area of communication between the web
server and the rest of the corporate intranet (including Business Objects).
Business Objects supports firewalls that use IP filtering, static NAT (Network
Address Translation), or SOCKS proxy servers, and it supports many different
configurations. Supported environments can involve multiple firewalls, web
servers, and application servers.
In addition to port filtering, a NAT firewall also performs network address (IP)
translation. This prevents the revealing of IP addresses of internal servers. If you
have private IP addresses, Business Objects recommends using a NAT-enabled
firewall.

What is a DMZ?
A DMZ is the secure buffer zone between two firewalls located between an
organization’s intranet and the Internet. It is designed to keep outside users from
accessing sensitive company data or to limit access to restricted users.
It is closely controlled by administrators so that only trusted processes are
allowed to run on machines within the DMZ. These trusted processes are closely
monitored, and if any abnormal behavior is observed, an alert is given and the
inner firewall is shut. The two firewalls allow limited sets of ports to be open. Each
set of ports is distinct from the other, and no single communication protocol can
traverse both firewalls.
Client
users Corporate
database
Application
Web server server
Network
Primary
node
Repository
Typical DMZ configuration
Communication through firewalls

Communication through firewalls uses the CORBA communication standard. In
CORBA:
• servers host objects and expose them through the naming, trading, and
locator services
• clients access objects through remote method invocation mechanisms, via
the IIOP protocol
Firewalls
To be able to talk to a server located behind a firewall:

• the client must be able to locate and access the object through the firewall
• the server and CORBA location services must be started on fixed ports
• the port used by the server and CORBA location services must be enabled on
the firewall
In a Business Objects system, each Orbix 2000 server uses its own TCP port for
communication. This port can be either fixed by configuration or chosen
dynamically from among free TCP ports (default).
This type of configuration uses two types of communication protocols to cross the
two firewalls:
• HTTP
• TCP
Secondary
Application server node
HTTP TCP
Intranet
External network
or Internet
Outer Inner Primary
firewall firewall node
Communication protocols in a DMZ configuration
The outer firewall, next to the external network or Internet, allows HTTP
communication between the clients and the web server (and through it, the
Business Objects cluster), by default through port 80. The connector on the
application server machines tunnels the communication with the cluster.
The inner firewall, next to the intranet, allows TCP traffic in both directions
through the ports that the web servers and application server are using to
communicate.
Both firewalls perform filtering. They may also perform IP address translation.
(Most deployments have network address translation at the inner firewall to
protect the intranets.)

Deployment schema
Client Primary node

users
Application
Web server server
Database
Intranet
Outer firewall Inner firewall Repository
Secondary Secondary
node node
Typical DMZ topology
• Client machines on the Internet can be the clients for Business Objects server
products. All these clients communicate in HTTP with the web servers in the
DMZ.
• Web servers are always deployed within the DMZ. You can deploy several
web servers if you want.
• The application servers are always deployed inside the intranet; an
appropriate connection module is plugged into the web servers in the DMZ
with which the application servers are communicating. The application server
constructor provides these connection modules.
The communication between the web servers and application servers occurs
via these connectors, through a restricted number of TCP ports, ideally one
per server.
Constraints
In this configuration, data exchange between the clients and the database
servers is not supported.
However, all Business Objects downloads and installations through InfoView,
such as the various applets and BusinessObjects in 3-tier mode, are supported.
Firewalls
Using a firewall between the application server and the cluster

Configurations in which the application server is separated from the Business
Objects cluster by a firewall are called deported application server configurations.
Client Primary node

users
Web server Application

Application server
server
Database
WAN WAN
Intranet
Single Repository
Double firewalls Double firewalls
firewall
protecting Secondary
cluster node
Example deported application server configuration
This type of configuration provides an additional layer of security by shielding the

web and application servers and the cluster from unauthorized access. It also
allows you to have an Internet Service Provider (ISP) host maintain your
application server, while you keep the web server and the cluster on-site.
Communication between the application server and the cluster

Several processes on the application server communicate directly with
processes on the Business Objects server. The Business Objects server listens
on TCP ports displayed in the Administration Console.
In this example, the TCP port numbers are just examples:

Business Objects server
ASF and
Business Objects TCP port numbers
Application server
processes
itconfig_rep.exe 10000
itconfig_rep.exe 10001
itnode_daemon.exe 10002
itnaming.exe 10003
WIProcessManager 10034
WIDispatcher 10035
WIAPIBroker 10040
WIReportServer 10041
ConnectionServer 10042
ASF and Business Objects processes passing through firewall
Communication is established by the application server calling the Business

Objects server on the appropriate port. Replies are across TCP ports that are
dynamically allocated; your firewall must let all reply calls pass.
This is acceptable because the firewall controls the initial communication from
the outside (application server) to the inside (Business Objects server). This
initial communication must go across the TCP allocated port, from application
server to Business Objects server. The reply is trusted, and can therefore go
across any port.
The Administration Console tells you what ports to open. If you add a process on
a Business Objects server, you must open another port (again, specified in the
Administration Console).
NOTE
TCP port allocation is not necessarily contiguous. Other internal ports may be
used by the Business Objects server, and other ports that may be busy when you
start the Business Objects server.
Once started, however, the ports do not change. For example, if you add a
WIReportServer instance (in addition to the one using port 10041), you must also
open an additional listening port, which you specify using the Administration
Console).
Firewalls
If you have multiple Business Objects servers, you must open sets of ports for
each of these servers.

Reverse proxies
In extranets in particular, web servers represent one of the system’s weakest
points. This is because they are usually deployed inside the DMZ (and therefore
closest to the outside world), and because you need to rely on application
security.
You can protect sensitive information on your web server by deploying a DMZ
between two firewalls and using a reverse proxy to protect your Business Objects
servers from direct uncontrolled access from extranet clients.
A reverse proxy is a proxy server which appears to be a normal web server to
clients, but in fact reroutes user requests to a machine deeper into the network
(and with a different name and IP address). The responses from the web server
are routed via the reverse proxy back to the client browser.
The word “reverse” refers to the inverted role of the proxy server. While normal
proxy servers act as a proxy for the client (the request is made on behalf of the
client by the proxy server), a reverse proxy handles requests on behalf of the
server, in this case, the Business Objects cluster.
How reverse proxies work with Business Objects

In reverse proxy configurations, extranet user requests to your site go straight to
the reverse proxy. The reverse proxy sends this request to the web server,
generally on another subnet, which sends the request on to the cluster for
processing. The result is then passed back to the web server, which sends it back
to the reverse proxy. The reverse proxy sends the information to the extranet
user as if it were coming directly from the actual Business Objects server. The
real URL address of your site is thus not revealed to outsiders.
Because the reverse proxy does not run any scripts, the system is less vulnerable
to attack. The hacker may still try to tunnel through to the web server, but it is
harder to determine the port on which the web server listens, and it is difficult to
get the proxy to route any responses back.
Reverse proxies

Choosing Appropriate
Authentication and Authorization
chapter
Overview
Authentication and authorization are two distinct but related processes:
• Authentication examines the user name and password a user enters at login
to verify that the user really is the person he or she claims to be.
• Authorization is the subsequent calculation of a user’s access rights, in order
to provide the correct access to applications and resources.
Before logging into your system, you must choose the cluster’s authentication
mode, which determines the method by which users are authenticated: Business
Objects, Windows, SSO (Single Sign-on), or Basic.
You must also choose an authentication and authorization source; that is, where
and how you are going to store user authentication and authorization information.
This chapter describes authentication and authorization, how they work, and
provides you with some of the information you need to choose the right
authentication for your Business Objects deployment.
Choosing Appropriate Authentication and Authorization

Sessions and login

One of the key building blocks in the authentication process is the session. A
session is a series of interactions that occur during the span of a single
connection. In Business Objects, user sessions begin when a user logs in, and
end when the user logs out or remains inactive for more than a predetermined
timeout. Sessions can also be terminated by the administrator or by a problem
causing the entire system or server to fail.
The session stores user information such as preferences and security profiles, as
well as temporary information needed to process documents.
In a standard HTTP transaction, the browser requests a web page from the web
server. The web server responds to the request, and then “forgets” the browser.
Information about the request exists only for the duration of a single request/
response interaction.
With sessions, the web server retains the session ID by means of a header
cookie, an additional line of information entered in the page’s HTTP header.
Sessions in Business Objects are used to:
• authenticate InfoView users
• enable other components to access user and security information when
processing user requests
• track and record user actions
• enable administrators to manage user access to the system
The login process is the starting point of each user session. This process is
initiated by the WISessionManager in the Session Stack on the node used for
processing required during the user session. The login is then managed by an
ASF component called WILoginServer which speeds up and optimizes the login
process.
Types of sessions
In Business Objects, there are three types of sessions:
• InfoView user sessions
• 3-tier BusinessObjects sessions
• sessions used by Broadcast Agent for the processing of scheduled tasks
Sessions and login

A session is therefore created when one of the following occurs:

• a user clicks the Login button on the InfoView Login page
• a user logs into a 3-tier deployment of BusinessObjects
• Broadcast Agent schedules a request in batch mode
The following diagram illustrates the types of session creation.
BusinessObjects
login in 3-tier mode
InfoView login
Session creation
Broadcast
Agent

Authentication modes
Your choice of authentication mode determines the method by which users are
authenticated for both 2- and 3-tier Business Objects applications. Business
Objects recommends that you do not mix authentication modes within a single
Business Objects cluster. This can potentially compromise your system’s
security.
The following table summarizes the different authentication modes in a 2-tier and
3-tier Business Objects system.
Authentication mode In a 2-tier system In a 3-tier system

Business Objects The Business Objects system performs the entire
authentication process from the repository. The 2- and 3-tier
modes use the same user name and password.
Windows The user is authenticated on The user is authenticated by
the Windows workstation and an IIS web server. There is no
on the repository. independent checking by
Business Objects; Windows
is completely trusted.
SSO The workstation asks the The user is authenticated by
SSO server to authenticate the SSO server in an external
the user. The SSO system user management system.
then returns the After authentication, the
authentication ticket to the server sends an authorization
workstation. ticket to the web server, and
the authentication ticket is
checked again by Business
Objects.
Basic authentication The Business Objects user User authentication is
name and password is delegated to the web server.
required. The web server is trusted
without being checked.
Business Objects verifies the
user name, but not the
password, in the repository or
in the external source.
How authentication modes work

The sections below describe the workflow of each mode (in 3-tier authentication),
as well as its advantages and disadvantages.
Business Objects
When Business Objects authentication is selected:
1. The user requests the InfoView portal page in a web browser.
2. The user clicks the Login button, then enters a valid username and password.
3. The password is encoded and sent with the username to WILoginServer.
4. WILoginServer verifies the existence of the username and the validity of the
password entered for this user.
5. If the username and password are valid, WILoginServer builds:
- the list of applications the user is allowed to use
- the list of documents the user is allowed to use
- the list of security metadata (such as connection or universe overloads),
which is kept with the session as long as it is valid
Advantages/disadvantages
Because it uses proprietary access techniques, it is normally hard to crack.
Business Objects mode is also strengthened by the use of strong encryption and
decryption techniques like DES/AES.
When used with the Repository authentication source, Business Objects mode is
more suitable to simple deployments with a small user population.
Windows
When Windows authentication is selected:
2. The Microsoft IIS web server (set to Windows Authentication or NT
Challenge-Response, depending on the version) transparently asks the
browser for the user’s credentials.
3. The browser responds.
4. The web server verifies these credentials against its authentication source.
5. If the credentials are accepted, the web server returns the InfoView portal
page.
6. The user clicks the Login button.
7. The user’s identity is retrieved from the web server and used by
WILoginServer to calculate the user's security rights.

This mode leverages the trust relationship between the various domains in the
network.
Windows 2000 servers use the Kerberos authentication protocol, which is now a
recommended standard. (NT uses NTLM)
With Windows 2000 Server, you can use Active Directory for user management.
There is a danger, however, that a hacker could bypass the authentication
mechanism by accessing the application server directly from the outside. This
can be avoided by using a firewall, so that all transmissions pass via IIS.
SSO
To use SSO, you must have a supported third-party security management
system that is supported by Business Objects (see Optional Third-Party Security
Management Systems on page 59).
When SSO authentication is selected:
1. The client user initiate a session in the portal. The call is redirected by the
SSO Agent for credential checks.
2. The SSO Agent queries the security server to authenticate the user. If the
result is positive, the security server instructs the Agent on the policy to follow
with the user.
3. The SSO Agent redirects the user’s calls to the web server, according to the
Security Server policy, and adds the appropriate ticket to the HTTP headers.
This is the ticket used to identify the session.
4. The user’s request for an application service is sent to the application along
with the session ticket.
5. The Affiliate Agent checks for the portal session ticket authenticity with the
Security Server, and instructs the application to act accordingly.
SSO mode provides a single point of login between multiple applications.
You can use it to leverage the capabilities of an external security management
system to authenticate users.
Basic
When Basic authentication is selected:
2. The user clicks the Login button.
3. The web server requests the user’s credentials.
4. The user enters the credentials (username and password, LDAP username
and password).
5. The web server verifies these credentials against its authentication source.
6. If the credentials are accepted, the web server returns the user’s identity,
which WILoginServer uses to calculate the user’s rights.
Be careful when using Basic authentication because passwords are transmitted
openly over the network. There is no encryption. Any eavesdropper can capture
the password, which can lead to replay attacks.

Authentication sources
To authenticate a user, the system checks the username and password entered
at login against preregistered authentication information required for access to
the system.
You set where Business Objects finds this information. This is called the
authentication and authorization source. As a Business Objects administrator,
you can manage this type of user information in the repository, in a third-party
security management system, or in an LDAP database.
Types of authentication source

If you select SSO as authentication mode, the source is always the SSO server
within the third-party security management system.
If you select one of the other modes (Business Objects, Windows, or Basic), you
have a choice of three options:
• Repository
• External then Repository
• External
Whether you store user authentication information in the repository or in an
external system, the system relies upon the access rights stored in the Business
Objects repository, as you defined them using Supervisor.
The following table describes the different authentication sources.
Authentication Description
source
Repository The traditional Business Objects approach, in which each user’s
authentication information and security profile is entered using
Supervisor and stored in the repository’s security domain. Users
are both authenticated and authorized through the repository,
using Business Objects security mechanisms.
External then Mapping between the external LDAP directory to the Business
Repository Objects repository is set by either one of two methods:
and 1. Each user is declared in an external LDAP directory (this makes
External them external users) and is mapped directly to a user that has been
declared by name in the repository using Supervisor. The user
must be declared by the same name in both the external directory
and the repository. The external user is granted all the rights of the
repository user. (If a user is declared only in the repository, the
login will still be successful.)
2. Each external user is mapped to one or more repository groups
declared using Supervisor, thereby acquiring all the access rights
of those groups. The user is declared in the LDAP directory but is
not actually named in the repository. The relationship between the
external user and the security profiles in the repository is defined in
the external directory itself. Authorization is calculated by
combining the authorizations of the mapped user groups and their
parent groups in the repository.
Only when the setting “External then Repository” is selected will the
system first attempt authentication via the LDAP directory; if the
user is not found in LDAP then authentication is performed via the
Business Objects repository.
For more detailed information on the mapping between externalized users and
the security profiles in the repository, see Mapping LDAP users to Business
Objects on page 93.
Advantages and disadvantages of the sources

The following sections explain the advantages and disadvantages of the various
authentication and authorization sources.
Repository source
When used with the Business Objects authentication mode, it is more suitable to
simple deployments with a small user population.

External then Repository source

It provides a reliable and strong level of authentication, but is still not as robust
as the External source.
External then repository is particularly suited to either:
• simple, small deployments
• migration of users from the Business Objects repository to an LDAP directory
External source
All users are available only in the LDAP directory, so there is no need to
synchronize the user profiles in the Business Objects repository. However, you
cannot manage security at the user level unless the user is declared in the
repository.
This source uses the same LDAP directory for all applications within the
enterprise network.
In most cases, External is the most secure authentication source.
The following diagram shows how authentication source works.
Start
authentication
Check source in
repository
External External then Repository

repository
Authenticate Yes Is this user No Repository user

user via external in the external Authenticate and authorize
system system? user via the repository
Is the user
Yes No
declared in the
repository?
External and External-only user

repository user Read security profiles in
Authorization based external authorization
on repository access based on mapping
rights between external user
profiles and repository

What security options and sources can you use with each authentication
mode?
The following tables show which security options and sources can be used with
each type of authentication mode.
You can use ...with these authentication modes:

this security
option... Business Objects Windows SSO Basic
External LDAP- Yes Yes No Yes
based user
management
system
Third-party security No No Yes Yes
management
system
SSO No No Yes No
You can use ...with these authentication modes:

this source... Business Objects Windows SSO Basic
Repository source Yes Yes No Yes
External then Yes Yes No Yes
Repository source
External source Yes Yes Yes (source must Yes
be the SSO server)

LDAP and External User
Management Choices
chapter
Overview
This chapter describes how an LDAP (Lightweight Directory Access Protocol)
based directory works with Business Objects. Managing Business Objects user
identities in this type of system allows you to store user information for all your
enterprise applications—including the Business Objects suite—in a single
corporate directory.
This chapter also covers the LDAP-based external user management systems
supported with this release (Microsoft Active Directory® and
Sun Directory Server®) and how they work with Business Objects.
LDAP and External User Management Choices

What is LDAP?
LDAP is protocol that enables users to share information among applications.
An LDAP-based directory is a database used to store users, groups, distribution
lists, and other objects inside a structure which represents the organization of the
company. It is used for user authentication and retrieval of user attributes such
as identity, email and phone number, position in the company, department,
security groups, and publication lists.
LDAP is based on the X.500 standard, which uses a directory access protocol
(DAP) for client-server communication. LDAP is an alternative to DAP because it
uses fewer resources and simplifies and omits some X.500 operations and
features.
With LDAP, you can:
• store the entire organization (users and resources) on a single directory
• support a well-defined API which is easy to code and use
• work efficiently with popular third-party security management systems like
SiteMinder
• use the PKI infrastructure, which enhances user security
• service a large number of users
• build a solid foundation for UNIX and extranet deployments
LDAP directories are not functional without a network connection.
What is LDAP?
LDAP directories and queries

LDAP directories are organized as a tree that models the company organization.
The tree contains objects that represent users, groups, distribution lists, roles,
and so on.
Every object is identified by a distinguished name (DN) which represents its full
path and which is unique inside the organizational tree. Every object is also
defined as a set of attributes, each attribute having one or more values.
Common attributes for a user are:
• FirstName
• LastName
• Common Name (CN)
• User ID (UID)
• Password
• E-Mail
• Phone
• Fax
Common attribute for a group are:
• Common Name (CN)
• uniquemember
LDAP queries
The LDAP query is the mechanism used to retrieve and update objects inside the
tree.
Before being able to retrieve objects from an LDAP directory, a client must
establish a connection to the LDAP server. This is called binding. To bind to the
server, the client must provide:
• Connection parameters: LDAP server hostname and port
• Credentials: user’s full distinguished name (FDN) and password

An LDAP search query is composed of:

• Root DN
Represents the starting point of the search in the LDAP tree.
• Scope
Defines the level at which the search will be performed:
- Base: only the object represented by the DN
- One: the objects directly contained in the folder represented by the DN
- Subtree: all objects in all subtrees, starting from the DN
• Filter
Determines the objects to be retrieved. It is an expression, composed of a set
of criteria linked together by logical operators. Each criteria is defined as a
comparison between:
- a list of attributes returned as the result of the query
- a set of options (preferences)
LDAP directories and queries

LDAP and Business Objects

Because LDAP is application-independent, any client with the proper
authorization can access its directories. This means that you can set up users to
log on to Business Objects via LDAP. It also enables users to be authorized when
attempting to access resources in Business Objects.
You map user accounts and groups from your LDAP server to Business Objects
(see Active Directory on page 58). This enables the system to verify all logon
requests that specify LDAP authentication. Users are authenticated against the
LDAP directory server, and have their membership in a mapped LDAP group
verified before being allowed entry into an active Business Objects session.
LDAP authentication for Business Objects is similar to Windows authentication in
that you can map groups and set up authentication and authorization.
How LDAP works with Business Objects

When an externalized user logs onto a Business Objects application, certain
operations are performed together with the LDAP server.
First, the user is located as an entry inside the LDAP directory tree.
The progress from login name to the user’s full definition is called the
disambiguation phase. Disambiguation relies on the LDAP search function. The
search query must be consistent with the target directory tree. Keep in mind that
queries differ significantly from one system to another.
The LDAP user entry is retrieved inside the directory tree. By default, the search
query is simple. Its base argument is the root entry and its filter argument is
(uid=<loginname>).

After the user is localized inside the directory, the DN is known and the password
is validated by issuing an LDAP bind request. Then the group membership
(symbolic name) is retrieved by Business Objects.
LDAP and Business Objects

External user management systems

BusinessObjects 6.5 supports two LDAP-based external user management
systems: Microsoft Active Directory and Sun Directory Server. You can find
instructions for using these systems with Business Objects in Chapter 7.
Active Directory
Microsoft Active Directory provides centralized management of users and user
rights. Active Directory:
• is bundled with Windows 2000 Server and 2003 Server
• conforms to the latest LDAP V3 standards
• provides centralized user management for the enterprise domain
• forms a trust relationship between domains
• supports PKI
• supports SSO
Sun Directory Server

The Sun Java System Directory Server is another LDAP database that is
supported by Business Objects. It provides a user management system for
organizations that deal with a high volume of user information. You can use
Directory Server as a centralized repository for storing and managing users and
application and resource information.

Optional Third-Party Security
Management Systems
chapter
Overview
This chapter explains how third-party security management systems work with
the BusinessObjects 6.5 suite.
These systems enable you to have users authenticated in one central location,
with maximum security.
A major reason for using these systems with Business Objects is that they
provide single sign-on (SSO), which allows users to authenticate once, then
access other protected resources without re-authenticating. Depending on your
configuration, this can occur when users enter the operating system, an
enterprise portal, or elsewhere.
These systems usually work together with an LDAP directory. (For a full
discussion of LDAP, see Chapter 4.)
For the list of supported third-party security management systems and versions,
see the PAR:
1. Go to www.techsupport.businessobjects.com.
2. Log into the site.
3. Select Enterprise 6 > PAR > BI Platform 6.
NOTE
Business Objects recommends that you configure your third-party security
management system, as explained in the sections below, before installing the
BusinessObjects 6.5 suite.
Optional Third-Party Security Management Systems

Netegrity SiteMinder
SiteMinder is a platform for secure portal, extranet, and intranet management. It
meets key authentication, authorization, and personalization requirements for
building and managing secure websites. SiteMinder is supported by
BusinessObjects 6.5.
Using SiteMinder, you can easily implement security policies that protect web
applications and resources. It enables you to manage both authentication and
authorization privileges based on a user-centric, policy-based model for security.
SiteMinder is a directory-enabled, standards-based system that can work with
heterogeneous web and application servers, operating systems, and application
development platforms.
The following diagram illustrates how SSO works with SiteMinder.
2
The SSO Agent queries the
3 Security server to
The SSO Agent authenticate the user. If the
redirects the user’s calls user is authenticated, the
to the web server security server instructs the
according to the Agent on the policy to follow
Security Server policy, Web server for the user.
and adds the SSO Agent
appropriate ticket to the
HTTP headers. This is
the ticket used to identify
1
Security Server
the session. The user logs into
InfoView.
The call is redirected
by the SSO Agent for
credential checks.
Client
Netegrity SiteMinder
SiteMinder components
A SiteMinder installation has two main components:
• Policy Server
• Web Agent
Policy Server
The SiteMinder Policy Server manages the access-control policies established
by an administrator. These policies define which resources are protected and
which users or user groups are allowed access to resources. Using policies, you
can set time constraints on resource availability and IP address constraints on
the client attempting access.
The Policy Server runs on a Windows or UNIX system and performs key security
and portal management operations. To meet the security needs of each
environment, the Policy Server supports a range of authentication methods and
uses existing directory services to authenticate users. By supporting a wide
range of authentication methods, the Policy Server provides flexibility and
security for a diverse set of users.
To define policies, administrators use the Policy Server User Interface. This web-
based application enables you to create policies that protect any resource, and
lets you configure responses that supply data for web applications.
Web Agent
SiteMinder Web Agents work with the Policy Server to authenticate and authorize
users for access to resources on a web server.
The Web Agent is integrated with a web server or application server. The agent
intercepts requests for a resource and determines whether or not the resource is
protected by SiteMinder.
The SiteMinder Agent Operations Guide describes how to manage web agents
according to the web server or web application server with which they are
integrated.
Optional Third-Party Security Management Systems

Implementing a Secure
Environment
part
Preparing Your Environment
chapter
Overview
This chapter describes how to set up basic network and system security. This
includes:
• setting up firewalls
• setting up a reverse proxy
• configuring security on Windows 2003
• installing the BusinessObjects 6.5 suite
• activating SSL
• setting security for the Business Objects environment

Here’s an overview of the overall security implementation process, and where
you should be now. Optional steps are in red:

are now
D 1. Set up your configuration’s firewalls. 67
system security.
Activate SSL. 79
management.
system.
This section explains how to set up a firewall. For general information on

firewalls, see Firewalls on page 28.
To begin with, install the required components on the web server, application
server and cluster nodes as described in the Installation and Configuration
Guide.
Internet Primary node

users
Application
server
Web server
Database
Intranet
Outer firewall Inner firewall Repository
Secondary Secondary
node node
Sample firewall/DMZ deployment schema
Firewall restrictions
This release supports neither Business Objects server components (such as a
“dead” secondary node) nor a firewall between primary and secondary nodes in
the cluster.
However, you can have the application server in its own DMZ, separated from the
cluster by one or more firewalls. This is called a deported application server. For
information, see the Deploying the Business Objects System guide.
Setting the TCP ports used by cluster processes

When you configure the cluster’s ORB, usually using the Configuration Tool, you
set the range of ports to be used by the processes on each primary or secondary
node. At server startup, each of the processes on the primary or secondary node
is allocated a fixed port within the range you specified, through which it listens for
incoming requests coming from other nodes, or the application or web server.
The range of ports you set for secondary nodes must be the same as those you
set for the primary node.
Depending on your deployment scenario, you may need to open specific ports in
the firewall to allow communication through the firewall. All the nodes in the
cluster must have openings on the inner firewall through which to communicate
with components in the DMZ and beyond.

Allowing the web servers to communicate with the cluster

When the web server is situated in the DMZ, the outer firewall must allow HTTP
communication. Usually port 80 is used for this, so in the rules for the outer
firewall, any client port must be able to talk with port 80 on the cluster’s primary
node (or a different port set during ORB configuration with the Configuration
Tool). In the Administration Console, you can see which ports are allocated to
which processes.
The inner firewall must allow TCP traffic in both directions through the TCP ports
that the web servers, the cluster’s primary node, and the application server are
using to communicate. The web and application server ports are set when these
servers are set up. See the web and application server documentation for
instructions on how to do this.
Allowing application server/cluster communication through a firewall

For complete instructions, see Implementing a deported application server on
page 70.
Enabling the web and application servers to communicate

If you are using separate web and application servers in your deployment,
regardless of where they are hosted, the web server communicates with the
application server through the third-party connector. You still need to configure
the ORB on the application server machine, however, so that it can communicate
as a client node with the cluster’s primary node. You do this with the
Configuration Tool that you installed on the application server machine.
You must also configure the connector on the web server. To do this, you specify
a port through which the application server and the web server can communicate
in the inner firewall. You must then open that port in the inner firewall, according
to the instructions in the firewall manufacturer’s documentation.
Implementing a deported application server

For this type of configuration, your deployment depends on whether you’re using
ASP or JSP technology:
• This is a typical ASP configuration with a deported application server:

users
IIS
Database
WAN
Intranet
Repository
Double firewalls Single
firewall
cluster node
Example deported application server ASP deployment
• This is a typical JSP configuration with a deported application server:

users
Web server Application

Application server
server
Database
WAN WAN
Intranet
Repository
Double firewalls Double firewalls Single
firewall
cluster node
Example deported application server JSP deployment

Several processes on the application server communicate directly with

processes on the Business Objects server.
As the Business Objects server listens for requests from these processes on TCP
ports, and each process is assigned a specific port for the duration of the server
session, you must open a set of ports in the firewall to allow this. If you have
multiple Business Objects servers, you must open sets of ports for each of these
servers.
Before configuring the firewalls

Before configuring the firewalls in your configuration to allow communication
between the cluster and the deported application server, you must:
1. Install the Business Objects server products on the machine that will host the
Business Objects server.
2. Configure that machine as the cluster’s primary node.
3. Start the server.
4. Install the required Business Objects components on the web and application
servers (see the Installation and Configuration Guide).
5. On the web and application server machine(s), check whether the following
directory exists:
$INSTALLDIR\BusinessObjects Enterprise 6\http_server_bin
It should contain the following DLLs:
- BODocGenISAPI.dll
- iswi.dll
If this directory does not exist, copy it from the
$INSTALLDIR\BusinessObjects Enterprise 6 directory on the cluster’s
primary node machine.

6. Run the Configuration Tool on the application server machine, configuring the
machine as a client node.
If you’re using NAT (Network Address Translation) between the application
server client node and the other cluster nodes, when you run the
Configuration Tool on the application server node, you must configure the
ORB using the node’s hostname, not IP address.
If you start the primary node, you should be able to ping the client node
hostname from the primary node.
7. Deploy the Business Objects web applications (InfoView and the
Administration Console at least) on the web and application servers, using
either the Configuration Tool, the wdeploy script, or manual configuration
procedures.
8. Test the configuration by running an Internet browser on a client machine and
typing the URL pointing to the primary node (for example, http://server1/
wijsp).
Opening the firewall for cluster/application server communication

To use a firewall between the application server and the cluster, you must open
certain ports in the firewall to permit the cluster’s primary node and the
application server to communicate through the firewall.
For application server / cluster communication

To permit application server -> cluster communication, you must open the ports
allocated to the following processes on the cluster’s primary and secondary
nodes:
• all it* processes, such as itconfig_rep.exe, itlocator.exe and itnaming.exe
• WIProcessManager
• WIDispatcher
• WIAPIBroker
• WIReportServer (you must open a separate port for each WIReportServer
instance)
• ConnectionServer (if you’re using BusinessObjects in 3-tier mode)

The list of the ports you must open is displayed in the Administration Console:
List of exposed ports in the Administration Console
You can also retrieve this list using the wasfadm utility, by typing for example:
% wasfadm -port
The result looks something like this:

NODE PORT PROCESS
server1 100010 it_naming.exe
server1 100011 it_locator.exe
...
For cluster/application server communication

As ports for communication running from the cluster’s primary node to the
application server on the client node are allocated dynamically, you must open
all the ports on the cluster’s primary and secondary nodes in this direction.

Setting up a reverse proxy


are now
1. Set up your configuration’s firewalls. 67
D Set up a reverse proxy. 74
2. For Windows 2003, configure Windows 77
operating system security.
Activate SSL. 79
management.
system.
Although it is possible to place the reverse proxy outside the outer firewall, there
are important reasons to have the reverse proxy within the DMZ:
• With the reverse proxy inside the firewall, it benefits from the protection of the
outer firewall
• The reverse proxy may need to cross the DMZ to access the security server
in the intranet. Because the outer firewall allows HTTP access only, it would
not permit this connection.
When you deploy a reverse proxy within a DMZ, you must use one of the
following configurations, depending on whether you have an JSP or an ASP
deployment.

JSP deployments
In this schema:
• the reverse proxy and the web server are positioned within the DMZ
• the outer firewall provides access control for users trying to use the system
from the Internet
• the reverse proxy provides authentication and data control
Client
users
Application
Web server server
Database
Intranet
Reverse
proxy
Outer firewall DMZ Inner firewall Repository
Primary Secondary
node node
Reverse proxy and web server within DMZ (JSP)
ASP deployments
In this schema:
• the reverse proxy is situated within the DMZ
• the outer firewall provides access control for users trying to use the system
from the Internet
• the web server provides authentication and data control
Setting up a reverse proxy

Client
users
Application/
web server
Database
Intranet
Reverse
proxy
Outer firewall DMZ Inner firewall Repository
Primary Secondary
node node
Reverse proxy alone within DMZ (ASP)

Configuring security on Windows 2003


are now
D 2. For Windows 2003, configure Windows operating 77
system security.
Activate SSL. 79
management.
system.
Business Objects recommends setting security on Windows 2003 before you

install the BusinessObjects 6.5 suite.
If you are not installing Business Objects on your c:\ drive, you must enable
access to the x:\install_path. This is because the w3svc.exe worker process runs
as a Network Service account.
Do either of the following:
• Give Network Servce access to x:\install_path so that w3svc.exe (which by
default runs as a Network Service) will have access to the installed directory
• Configure the App Pool to login with a user that has access to x:\install_path
to prevent access denied when users log into IIS
Configuring security on Windows 2003

Installing and configuring the

BusinessObjects 6.5 suite

are now
system security.
D 3. Install and configure the Business Objects suite. 78
Activate SSL. 79
management.
system.
Now that you have set up your firewalls and planned your overall Business
Objects deployment, you install the BusinessObjects 6.5 suite.
See the Installation and Configuration Guide (Windows or UNIX) for instructions.

Activating SSL

are now
system security.
D Activate SSL. 79
management.
system.
For general information about SSL, see SSL on page 24.

To activate SSL:
1. Create a new key and a CSR (Certificate Signing Request) file.
2. Request a certificate from your CA (Certification Authority).
The key you generated is not valid for use on the Internet until you obtain a
valid certificate for it from a CA. Send the CSR to the CA in order to obtain a
valid certificate. Until you do so, the key on the host computer cannot be used.
3. Install the certificate on the server.
4. Activate SSL security on the web server.
Activating SSL
5. Test the SSL security by logging into InfoView from a client browser using
https://<Business Objects Host Name>/<wiasp or wijsp>
If you can log in, SSL security is functioning.
After the web server is set up to work with SSLs, Business Objects will use the
same HTTPS for sending and receiving information to and from the client.
Example: Activating SSL for Apache on Windows32

This section is provided as an example of SSL activation. It explains how to
activate SSL for Apache and Business Objects running on Windows32.
For general information on SSL with Apache, see www.modssl.org.
You configure Apache and InfoView so that you have two access points, one via
standard HTTP (Port 80) and the other via HTTPS (Port 443/SSL).
Here is a summary of the steps:
1. Undeploy Apache.
2. Overwrite your existing installation of Apache with the modified mod_SSL
version.
3. Install OpenSSL on the machine.
4. Create a private key and certificate for your machine.
5. Reconfigure Apache to use the new certificate.
6. Start ApacheSSL and install the certificate into your browser’s certificate
store.
7. Configure the HTTP and HTTPS Apache ports within the Configuration Tool.
These steps are explained in the following sections.
Undeploying Apache
To undeploy Apache:
1. Stop Apache and the Business Objects server.
2. Undeploy Apache using the Configuration Tool.
(See the Installation and Configuration Guide for instructions.)

There is no need to undeploy Tomcat as the application server. You are only
deleting the virtual directory for the web server:
Overwriting existing Apache installation

In this stage, you overwrite your existing installation of Apache with the modified
mod_SSL version.
To overwrite the installation:
1. Backup your existing httpd.conf file.
It is normally located under \...\Program Files\Apache Group\Apache\conf.
You will overwrite it in the next step, so you need to take a copy in order to
restore it afterwards.
2. Open Apache_1.3.27-Mod_SSL_2.8.12-OpenSSL_0.96h-Win32.zip
Activating SSL
3. Unzip it, specifying the following:

- Extract it to the root of your existing Apache installation. For example,
\...\Program Files\Apache Group\Apache
- Select All files
- Select Use folder names
4. Restore your original httpd.conf file back into the conf directory
5. Temporarily restart Apache to make sure it is still listening on its original port.
Installing OpenSSL
To install OpenSSL:
1. Open OpenSSL-0.9.6h-Win32.zip from the Business Objects CD.
2. Extract the following three files, and place them directly into the
\WINNT\System32 folder:
- libeay32.dll
- ssleay32.dll
- openssl.exe

Creating a private key and certificate for your machine

To create a private key and a certificate:
1. Create an ssl folder within the Apache conf folder. This is where the key and
certificate will be stored.
2. Paste the createKeys.cmd and openssl.conf files into this folder.
You can obtain these from the my zip file.
3. In a command prompt, change to your new ssl directory.
4. Run createKeys and answer the prompts.
The most important is the first (Common Name). Enter your unqualified server
name, for example wwwserver1. It will build the (unprotected) private key and
certificate in that directory.
Reconfiguring Apache to use your new certificate

To reconfigure Apache, you edit the httpd.conf file:
1. Add two Listen lines (one for HTTP and the other for HTTPS).
2. Add a LoadModule line.
3. Add an AddModule line.
Activating SSL
4. Comment out your original Port line (the Listen options override it).
5. Add the lines from the httpd.conf.ssl file to the end of the file. (Available from
the my zip file).
Starting ApacheSSL and installing the certificate

To start ApacheSSL and install the certificate into your browser’s certificate store:
1. From a command prompt, change to the Apache root directory.
For example, \...\Program Files\Apache Group\Apache
2. Start Apache interactively, so that any errors will be visible. Use the following:
apache.exe -k start

3. Note any errors. If it appears to start successfully, test it using a browser or

the OpenSSL Client utility:
- From a browser, use the URL: https://localhost
- From a command prompt, use:
D:> openssl.exe s_client -connect localhost:443
4. After the handshake is complete, try:
GET / HTTP/1.0
then press the enter key twice.
If successful, the browser alerts you about the certificate:
This occurs because you created and signed it yourself, but it doesn't
recognize the CA that you represent. Note in the picture above that it is
providing an alert only about the issuer; the validity dates and subject name
are valid. If the last point also raises a warning, you may have created the
certificate with an incorrect server name.
In order for the WebIntelligence Java Report Panel to transparently establish
a connection back to the server via this SSL-enabled route, you must install
this certificate within your browser’s certificate store. This means that it is
effectively “trusting” that this certificate came from a valid CA.
Activating SSL
5. Click View Certificate.

The Certificate dialog box appears.
Notice that this certificate has been issued by the same server/CA that is
destined for <name of machine>.
6. Click Install Certificate.
7. Accept all of the defaults.
8. After the certificate is installed, open a new browser and retry your SSL-
enabled URL, https://localhost
This time it should allow you to enter.
9. Stop the Apache instance you started interactively by pressing Ctrl-C in the
open window.
10. Install it as an NT service using:
apache.exe -k install

Configuring the HTTP and HTTPS Apache ports

In this stage, you configure both the HTTP and HTTPS Apache ports using the
Configuration Tool.
1. Start the Configuration Tool.
2. Under the InfoView web application, add two new virtual directories to your
web server instance:
- In the first, select APACHE SSL FOR TOMCAT, but keep its alias as wijsp.
- In the second, again select APACHE SSL FOR TOMCAT, but select the
_default_-443(443). You can reuse the same alias wijsp.
(See the Installation and Configuration Guide for instructions.)
3. Quit the Configuration Tool.
4. Restart the Business Objects server.
Testing the connection

Try to log into InfoView via HTTP and HTTPS. Make sure you can start the
WebIntelligence Java Report Panel.
Activating SSL
Setting up the Business Objects repository

then creating users and groups

are now
2. For Windows 2003, configure Windows 77
operating system security.
Activate SSL. 79
D 4. Create the repository. 88
D 5. Create users/groups and assign them rights. 88
management.
system.
There are a number of security-related configurations that you may need to

perform within the Business Objects system. The most important of these are the
settings in Supervisor.

Repositories and users

Using Supervisor, create the repositories that will be used by the clusters. This
also creates the repository’s .key file.
Make sure the bomain.key file of the repository you are using has been copied to
$INSTALLDIR\nodes\<hostname>\<clustername>\locdata\. Only one .key file
must be present in this folder and must be named bomain.key. The same key file
must be available to all the clients using the cluster, either installed on the client
machine or available in a shared directory. See the Supervisor’s Guide for details.
Use Supervisor to create or import the system’s users and user groups, then
assign them access rights. If you are using Broadcast Agent, define at least one
Broadcast Agent for one or more user groups.
Setting up the Business Objects repository then creating users and groups

Configuring LDAP and External
User Management
chapter
Overview
This chapter describes how to configure an LDAP directory to work with Business
Objects. First, general LDAP configuration is discussed, then specific instructions
are given for using Microsoft Active Directory and Sun Directory Server.

are now
system security.
Activate SSL. 79
D Set up and configure LDAP and external user 91
management.
system.
Configuring LDAP and External User Management

Mapping LDAP users to Business Objects

Mapping is an important part of user externalization. You can map external user
accounts or groups to existing Business Objects user accounts or groups, or you
can create new Business Objects user accounts or groups that correspond to
each mapped entry in the external system.
In configurations using an LDAP directory for storing user identities, you can
declare users in either of two ways:
• LDAP user directly to Business Objects repository user
The same name is used to declare the user in both the external LDAP
directory and in the repository.
• LDAP user to repository group
In this scenario, the relationship between the LDAP user and the repository
group can be defined by mapping any of the following:
- the user directly to the repository groups
- the user to the repository groups as defined by a specific LDAP user
attribute referencing these groups by name
- the groups to which a user belongs to a specific group or groups in the
repository. In this case, the names of the LDAP groups and the repository
groups are identical.
Mapping an LDAP user directly to a repository user

This type of mapping is advantageous if you already have a large set of users in
your corporate LDAP directory and it is the central repository for SSO that
involves other applications. In this case, there is no need for managing user
passwords in Business Objects.
If you are setting up a new deployment, user-to-user mapping is generally not
recommended.
Some advanced users, such as the general supervisor, must in all cases be
maintained in the repository. In an LDAP deployment, they are defined both in the
repository and in the LDAP directory.
This direct mapping is very useful when you have to merge a legacy repository
with your LDAP-based system during the transition phase. If there are too many
users, however, it can become difficult and costly to administer.

Here’s an example of user-to-user mapping:
LDAP users Business Objects repository
North America
Ontario Instance 1
of John Smith
Instance 2
cn = ‘John Smith’ of John Smith
South America
The LDAP user is mapped to the user instances in the repository, in this case to
Instance 1 and 2 of John Smith.
In this case, more than one LDAP user can be mapped to a single repository
user.
Mapping an LDAP user to a group in the repository

Here are two examples of mapping between LDAP users and repository groups.
Mapping an LDAP user directly to user groups in the repository
North America
Ontario
cn = ‘John Smith’
Roles = Group 1
Group 22
South America
The LDAP user is mapped to Groups 1 and 22 in the repository.

Mapping an LDAP user to repository groups based on an external attribute
North America
Ontario
NSROLE=Group 1, Group 22
South America
The LDAP server maps the external user attribute to groups in the repository, in
this case to Group 1 and Group 22.
In this example, the attribute, NSROLE, includes Group 1 and Group 22 for user
John Smith. Therefore, when John logs in, he inherits the access rights defined
for Groups 1 and 22 in the repository.
The main constraint here is that you need the attribute in your LDAP schema. If
there is already one that can be used, it’s easier. If not, you must modify your
schema, which is not acceptable in most cases.
This solution is often used when:
• the LDAP group structure doesn’t match the structure of repository users or
groups
• you want to merge an existing LDAP directory and a legacy repository whose
group organizations are different
• LDAP groups could not be used in Business Objects to define rights at the
group level
Mapping LDAP groups to repository groups

This type of mapping is highly recommended.
It is much easier to set user access rights (and rules for application access) for
groups rather than for individual users.
Generally users are grouped together because they have common attributes. For
example, they belong to the same department, or are from the same job level.

Here’s an example of group-to-group mapping.
North America
Ontario
Group = ‘Group 11’
Members = ‘John Smith’
‘Mary Jones’
South America
Group = ‘Group 2’
Members = ‘John Smith’
‘Steve Adams’
The LDAP user groups are mapped to groups in the repository (Group 11 and
Group 2). LDAP Group 2 has the members John Smith and Steve Adams, who
inherit the Business Objects group rights of Group 2.
Therefore, user John Smith also inherits the group rights of Group 11.
Synchronizing logins and externalizing repository users

To externalize a user, you must create the user in LDAP with a name that
corresponds to the repository user. If you delete a user from the repository and
then re-create the user in LDAP, the user’s ID will change at the next login.
Information attached to the previous user ID (personal options, personal
documents, Inbox, Broadcast Agent tasks) will not be available through the new
user ID. You externalize the repository user by creating the link between it and
LDAP.
The coherence between LDAP and repository mapping is maintained at the level
of group names. If a supervisor deletes a group called Sales and another
supervisor then creates a group called Sales, mapping between that group name
and LDAP will be altered, most likely without the supervisor’s knowledge.

Customizing LDAP queries

This is recommended only for experts. Customization is performed only in rare
cases, and it must be done with extreme caution. The default settings are
adequate in most situations.
The main reason for customization is to improve performance. For example,
when the system is running too slowly.
You can:
• adapt to non-standard LDAP schemas by defining new queries to be used by
the LDAP connector
• define the attributes you use in Business Objects applications
• define the Send To search
• specify a group membership query
• store an external password for use with Broadcast Agent
All of this is done on the Advanced LDAP Configuration page of the Security
Configuration Tool. (See Customizing LDAP query parameters on page 134.)
For example, you may not want to use uid as the attribute, or you may want to
change the Root DN, the root from which the query starts.
Customizing LDAP queries

LDAP restrictions for specific Business

Objects applications
Some restrictions apply when you use LDAP with the following Business Objects
applications:
• Supervisor
• InfoView
• Broadcast Agent
Supervisor
Users stored externally are not visible in Supervisor.
The supervisor and the designer users cannot be externalized. They can be
authenticated externally but must still be administered in the repository.
InfoView
To limit the scope of LDAP searches in the Send To workflow, not all LDAP users
can be displayed in the drop-down list at the same time. To find an LDAP user,
type the first letters of the user’s name.
Broadcast Agent
Send To workflow
To limit the scope of LDAP searches in the Send To workflow, not all LDAP users
can be displayed in the drop-down list at the same time. To find an LDAP user,
type the first letters of the user’s name.
Broadcast Agent requires a Broadcast Agent user to execute tasks. This user
must still be declared and authenticated through the repository; you can't
externalize Broadcast Agent users through LDAP.
Broadcast Agent account

For batch scheduling purposes, Broadcast Agent requires the Broadcast Agent
user to be in the repository. Therefore, if an externalized user has the same name
as a Broadcast Agent user, they both must have the same password. Otherwise,
Broadcast Agent cannot authenticate the user and scheduled tasks will not be
executed.

To avoid this problem, the Broadcast Agent user must either:

• be declared in the repository only and have a Broadcast Agent-specific name,
such as “bca123”
• hold the same name and password as the corresponding LDAP user
Refreshing a Broadcast Agent document

When logged into Business Objects in Business Objects authentication mode, a
user has BOUSER and BOPASS variable values, specifically the name and
password entered for external authentication. This user can use any connection
to build or refresh documents and use Broadcast Agent as long as the document
is refreshed in the user’s name, whether relying on a BOUSER/BOPASS
dynamic connection or a fixed credential static connection.
When the user wants to schedule a document to be refreshed in the name of
other users, however, the static connection works, but dynamic connections do
not.
When logged in to Business Objects with an external authentication source,
users have a BOUSER variable value, but no BOPASS value. As a result, they
cannot use dynamic connections.
A solution to this issue is the option available in the Configuration Tool to store,
in the repository, the passwords of externalized users. This permits dynamic
connections and scheduling in the name of specific users. Be aware, however,
that this may render the password non-secure.
For more information about the BOUSER and BOPASS variables, see the
Designer’s Guide.
LDAP restrictions for specific Business Objects applications

Configuring Active Directory

Active Directory enables you to map user accounts and groups from your Active
Directory user database to Business Objects. It also enables Business Objects
to verify all logon requests that specify Active Directory authentication.
Users are authenticated against the Active Directory user database, and have
their membership in a mapped Active Directory group verified before they are
granted a Business Objects session.
Before users can log on to Business Objects using their Active Directory user
name and password, their Active Directory user account needs to be mapped to
Business Objects. NT user names containing the @ symbol can be mapped.
For information on mapping users and groups to Business Objects, see Mapping
LDAP users to Business Objects on page 93. Note that groups do not have to be
under the same root.
After you map your Active Directory users and groups, all Business Objects client
tools support Active Directory authentication.
Note that:
• Active Directory authentication works only for servers running on Windows
systems
• Active Directory authentication and aggregation may not function if the
administration credentials become invalid (for example, if the administrator
changes his or her password or if the account becomes disabled).
• In order to use the Active Directory connector, there must be a user account
that has the right to Act as Part of the Operating System. See the Windows
documentation for more information.
SSO requirements
SSO requirements for Active Directory depend on the way in which users access
Business Objects: either via a thick client, or over the web. In both scenarios, the
security plug-in obtains the security context for the user from the authentication
provider, and grants the user an active Business Objects session if the user is a
member of a mapped Active Directory group.
To obtain SSO functionality over the web, the system must use Microsoft
components only. Specifically, the user must be running Internet Explorer on a
Windows operating system, and the web server must be IIS.

What you need to set in Active Directory

Make sure that you have the appropriate Active Directory domain and group
information. Create a domain user account on your Active Directory server for
Business Objects to use when authenticating Active Directory users and groups.
You need to:
• create groups appropriately and add users to them
• set their PWD rules, such as expiry and strength
• clearly set the schema, with the appropriate DN
What you need to set in Business Objects

You need to do the following in Business Objects:
• Install the Security Connector
• Select the correct settings in the Security Configuration Tool
Security Connector
When you install the BusinessObjects Suite, make sure you select the Security
Connector for LDAP. It is found in the Installer under Administration Products >
Security Connector > LDAP.
In the Security Configuration Tool

To use Active Directory with Business Objects, you select Windows as your
authentication mode in the Security Configuration Tool (see Setting the
authentication mode on page 123).
Then, on the Authentication and Authorization Source page, you select External
then Repository or External as the authentication source.
You configure the LDAP server connection. In the External source drop-down list,
you select MS Active directory.
Configuring Active Directory

Later, in the Advanced LDAP Configuration, you will come to the Mapping page.
Select the mapping method you have used.

Configuring Sun Directory Server

The Sun Java System Directory Server is another LDAP-based external user
management system that is supported by Business Objects. It provides user
management for organizations that deal with a high volume of user information.
You can use Directory Server as a centralized repository for storing and
managing users as well as application and resource information.
Users are authenticated against the Directory Server user database, and have
their membership in a mapped Directory Server group verified before they are
granted a Business Objects session.
Before users can log on to Business Objects using their Directory Server user
name and password, their Directory Server user account needs to be mapped to
Business Objects.
For information on mapping users and groups to Business Objects, see Mapping
LDAP users to Business Objects on page 93.
After you map your Directory Server users and groups, all Business Objects
client tools support Directory Server authentication.
What you need to set in Directory Server

In Directory Server, you need to:
• create user groups appropriately and add users to them
• set their PWD rules, such as expiry and strength
• clearly set the schema, with the appropriate Base DN
Creating an administrator’s account

You must create an administrator user account in Directory Server. This account
will be used to perform the binding.
For UNIX, define the administrator user account during the Directory Server
setup. Or, you can create an additional user account with the same rights.

You need to do the following in Business Objects:
• Install the Security Connector
• Select the correct settings in the Security Configuration Tool
Configuring Sun Directory Server

Security Connector
When you install the BusinessObjects Suite, make sure you select the Security
Connector for LDAP. It is found in the Installer under Administration Products >
Security Connector > LDAP.
In the Security Configuration Tool

You can select either Basic or Business Objects as your authentication mode in
the Security Configuration Tool (see Setting the authentication mode on
page 123).
Then, on the Authentication and Authorization Source page, you select External
then Repository or External as the authentication source.
Configure the LDAP server connection. In the External source drop-down list,
you select Sun Directory Server.
Later, in the Advanced LDAP Configuration, you will come to the Mapping page.
Select the mapping method you have used.

Configuring Third-Party Security
Management Systems
chapter
Overview
This chapter explains how to configure a third-party security management
system, Netegrity SiteMinder, to work with the BusinessObjects 6.5 suite.

are now
system security.
Activate SSL. 79
management.
D Configure third-party security management 105
system.
Configuring Third-Party Security Management Systems

Configuring SiteMinder
Before you begin...
Before setting up SiteMinder, Business Objects recommends that you read the
SiteMinder documentation:
• Concepts Guide
• Deployment Guide
• Release Notes
• Installation Guide
• Agent Operations Guide
NOTE
This guide includes information about SiteMinder that is current at the time of
writing. Check the SiteMinder documentation to verify that the information is still
up to date.
Supported platforms
Make sure your platform and operating system is supported for use with both
BusinessObjects 6.5 and SiteMinder 5.5. You can do this by checking the PAR:
1. Go to www.techsupport.businessobjects.com.
2. Log into the site.
3. Select Enterprise 6 > PAR > BI Platform 6.
You must use WebAgent version 5 QMR6 HF 007.
Supported deployment configuration

The following diagram shows the recommended deployment for using SiteMinder
with BusinessObjects 6.5.
Users
Secondary node
--SiteMinder Policy Server
Network
Primary node
--Business Objects server
--SiteMinder Web Agent
--Web server LDAP server
Note that the LDAP server can be located on any machine in the network. In
order for users to be logged into Business Objects products using SiteMinder's
SSO feature, their Business Objects user names must correspond to their LDAP
user names.
If you are using SiteMinder with SSO authentication, you must use an LDAP user
directory. Make sure you declare an LDAP server when you create the Business
Objects agent in SiteMinder.

For Business Objects products to work with SiteMinder, the cluster must use
either the Basic or the SSO authentication modes.

You set the mode on the Authentication Mode page of the Business Objects
Security Configuration Tool.
For instructions, see Setting the authentication mode on page 123.

The authentication mode you select here determines what you need to set in
SiteMinder, as explained in the next section.
If you are using the SSO authentication mode, you must install the Business
Objects Security Connector. When you install the BusinessObjects Suite, make
sure you select the Security Connector for SiteMinder. It is found in the Installer
under Administration Products > Security Connector > SSO > SiteMinder.
What you need to set in SiteMinder

What you need to set and configure in SiteMinder depends on the authentication
mode you set in Business Objects.
If you are using the Basic authentication mode, you must create a Web Agent on
the web server.
If you are using SSO authentication mode, you must:

• create a Web Agent on the web server
• create a Business Objects agent
Declare an LDAP server when you create the agent.
Creating a Web Agent and a Business Objects agent are explained in the
sections below.
Creating a Web Agent

You need to create a Web Agent no matter which authentication mode you are
using in Business Objects. For more information about the Web Agent, see
Optional Third-Party Security Management Systems on page 59.
To create a Web Agent:
1. Launch SiteMinder (Netegrity Policy Server User Interface).
2. Click Administer Policy Server.
The Login dialog box appears.
3. Enter SiteMinder as the user name.
4. Enter the password you defined during installation.
The SiteMinder Administration Console appears.

5. In the System tab, right-click Agents, then select Create Agent.

The Agent Properties dialog box appears.
6. Enter the following information:
- name and description of the Web Agent
- IP address or host name of the machine on which the Web Agent is installed
- shared secret
The shared secret is an encryption key used for encrypting traffic between
the Web Agent and the Policy Server.
7. Select SiteMinder as the Agent Type.
8. Click OK.
The new Web Agent appears in the Agent List of the SiteMinder
Administration Console.
Configuring the Web Agent
To configure the Web Agent, you need to set several parameters related to
cookies. You can set these parameters by either:
• modifying the Agent Conf object in the SiteMinder Policy Server
• modifying the webagent.conf file in a text editor
The location of this file depends on the type of Web Agent. See the SiteMinder
Agent Operations Guide.
If you select this option, first set the AllowLocalConfig variable to yes in the
Agent Conf object.
The following table shows the parameters you need to set in either case.
Set this parameter... To this value... Notes

RequireCookies yes This makes it possible to perform single
sign-on and enforce session timeouts. If
you set the timeout parameters without
requiring cookies, the Web Agent
functions normally but cannot enforce the
timeouts. If the Web Agent requires
cookies but the user's browser does not
accept them, the user is denied access to
all protected resources.
PersistentCookies no Using persistent cookies is a security risk
because the cookie can be used to launch
subsequent sessions by other valid user
names, with no password validation.
CookieDomain <local cookie Verify that this is the local cookie domain
domain> of the system on which the Web Agent is
installed. For example:
usa.mycompany.com
This value is case-sensitive.
CookieProvider <cookie provider This URL must have a *.ccc extension.
URL> For example:
http://
1020.usa.mycompany.com:1080/
SmMakeCookie.ccc
LegacyVariables yes
Configuring the Web Agent for use with BusinessObjects in 3-tier mode
To be able to install and use 3-tier deployments of BusinessObjects with
Netegrity SiteMinder’s SSO feature, you must do one of the following:
• In your Policy Server, create an unprotected realm under your principal realm,
which contains as Resource Filter the distribution folder (wijsp/distribution or
wiasp/distribution).
• Enable persistent cookies (PersistentCookies=yes)

Creating a Business Objects Agent

The Business Objects Agent handles communication between the Business
Objects server and the SiteMinder Policy Server.
You must create a BO Agent before you set the authentication mode to SSO in
the Business Objects Security Configuration Tool.
Creating a BO Agent includes:
1. Copying the .dll or .so file
2. Creating a new type of agent
3. Creating the agent
4. Creating responses for the agent
5. Creating a realm
6. Creating a policy
7. Restarting SiteMinder and testing the BO Agent
These steps are explained in the subsections below.
Copying the .dll or .so file
To copy the .dll (Windows) or .so (UNIX) file:
1. Copy the file from the Business Objects installation directory:
- Windows: $INSTALLDIR\bin\bosmapi.dll
- UNIX: $INSTALLDIR/lib/libbosmapi.so.1
2. Paste the file into the Policy Server folder of your SiteMinder installation
directory.
Normally, this directory is located in:
- Windows: \<SiteMinder install directory>\bin\
- UNIX: /<SiteMinder install directory>/lib/
Creating a new type of agent
You must create a new type of agent before you can create the agent itself.
To create a new type of agent:
1. Log into SiteMinder, and open the Administration Console.
2. On the System tab, right-click Agent Types, and then select Create Agent
Type.
The Agent Type Properties dialog box appears.
3. Give the agent type a name, such as BO Agent, and define the following
actions:
- Search (use identifier 222)
- SearchGroup (identifier 223)
- SearchUsers (identifier 224)
4. When you finish entering the information, click OK.
The Administration Console reappears.
Creating the agent
To create the agent:
1. On the System tab, right-click Agents, and then select Create Agent.
The Agent Properties dialog box appears.
2. Give the agent a name, such as boagent, and enter the following:
- IP address or host name of the machine (usually the same as for the Web
Agent)
- Shared secret
3. Click OK.
Creating responses for the agent
Responses are actions the BO Agent performs. You must create the following
three responses for the BO Agent:
• Search
• SearchGroup
• SearchUsers

To create the responses:

1. On the Domains tab, right-click Responses, and then select Create
Response.
The Response Properties dialog box appears.
2. Give the response a name, and then click Create.
The Response Attribute dialog box appears.
3. Enter the following attributes for each response.
Response Library Function Parameters

Search bosmapi getUsersOfGroups (&(objectclass=groupofuniquenames)
(cn=%s));uniquemember
SearchGroup bosmapi getGroupsOfUser (&(objectclass=groupofuniquenames)
(UniqueMember=uid=%s,*));cn
SearchUsers bosmapi getUsers (|(uid=%s)(cn=%s));uid,cn
For example, the Attribute Setup tab for the SearchUsers response would
look like this:
4. When you have finished defining the three responses, click OK.
5. Close the Response Properties dialog box.
Creating a realm
You must now create a realm, and then add rules to it.
To create a realm:
1. On the Domains tab, right-click Realms, and then select Create Realm.
The Realm Properties dialog box appears.
2. Give the realm a name, such as BO Agent-realm.

3. Enter the required information in the various tabs. In the Advanced tab, in the
Directory Mapping area, make sure you select a user directory.
4. When you finish entering the information on the three tabs, click OK.
5. In the Domains tab, right-click the name of the realm, and then select Create
Rule under Realm.
The Rule Properties dialog box appears.
6. Add rules for the three BO Agent actions:

Creating a policy
You must now create a policy, and then add realms and responses to it.
To create a policy:
1. In the Domains tab, right-click Policies, and then select Create Policy.
The Policy Properties dialog box appears.
2. Click the Rules tab.
3. Attach the following realms and responses for each of the three rules.
Rule Realm Response

Search <the realm you created> Search
SearchGroup <the realm you created> SearchGroup
SearchUsers <the realm you created> SearchUsers

The BO Agent has been created.
Restarting SiteMinder and testing the BO Agent

When you have finished the above procedures, Business Objects recommends
that you start and stop all the services in the Status tab of the Policy Server
Management Console:
• Authentication
• Authorization
• Accounting
• Administration
• OneView Monitor
Then, use the SiteMinder Test Tool to test the BO Agent.

Using the Security Configuration
Tool
chapter
Overview
This chapter describes how to use the Security Configuration Tool.

are now
system security.
Activate SSL. 79
management.
system.
D 6. Use the Security Configuration Tool to: 119
You use the Security Configuration Tool to configure the following:

• Authentication mode
• Authentication and authorization source
• Server connection for an external LDAP database or security management
system
• Mapping between groups in the external system and Business Objects
groups
• Advanced LDAP features

The Security Configuration Tool can be used from any node which has a valid
repository key file. Although you can modify your configuration at any time, the
changes will not take effect until the cluster is restarted from the Administration
Console.
Who can use the Security Configuration Tool

To have access to the Security Configuration Tool, you must have a general
supervisor profile that is authenticated and authorized in the repository.
All other general supervisors can be authenticated in an third-party security
management system but must also be declared in the repository.
Making sure the Security Configuration Tool is installed

The Security Configuration Tool is automatically installed during a standard
BusinessObjects 6.5 Desktop or Server installation, provided the license key is
available. You do not need to install any special software.
If you select Custom Installation, however, you must select and install the LDAP
Security Connector. It is located in the product tree under Administration
Products.
Where are Security Configuration Tool choices stored?

The choices you make when you use the Security Configuration Tool are stored
in an XML file that is exported to the repository. This XML file has the same root
name as the cluster’s .key file.
Launching the Security Configuration Tool

To launch the Security Configuration Tool:
1. Do one of the following:
- From the DOS prompt, type:
cd $INSTALLDIR\bin\scripts\
configtool.bat -security
- From the Windows Start menu, select Programs > Business Objects >
Security Configuration Tool 6.5.
The Login dialog box appears.
2. Enter your general supervisor user name and password.

3. Select or browse for the repository KEY file, and then click Next.
The Authentication Mode page appears.

Setting the authentication mode

You set the authentication mode on the Security Configuration Tool’s
Authentication Mode page.
For an explanation of these modes, see 41.

Select the authentication mode you want, and then click Next.

The Authentication and Authorization Source page appears. The procedures you
now follow depend on the authentication mode you selected:
• If you selected Business Objects authentication, go directly to Setting the
source for standard modes on page 129.
• If you selected Windows authentication, read If you chose Windows
authentication on page 124, and then go to Setting the source for standard
modes on page 129.
• If you selected Basic authentication, read If you chose Basic authentication
on page 126, and then go to Setting the source for standard modes on
page 129.
• If you selected Single Sign-on, go directly to Setting the source for SSO mode
on page 130.
If you chose Windows authentication

This feature is available if you are using an IIS web server and clients are using
Internet Explorer. If you install Business Objects on a Windows NT/2000
machine, Windows authentication is installed and enabled by default.
NOTE
NT accounts refers to both Windows NT and Windows 2000 accounts.
Business Objects supports user and group accounts that are created with
Windows NT or Windows 2000. However, before users can use their NT user
name and password to log on to Business Objects, their NT user account must
be mapped to a new or existing Business Objects account.
Note that this is in addition to the mapping you perform using the Security
Configuration Tool.

Mapping via Windows NT

1. From the Windows Start menu, point to Programs > Administrative Tools >
User Manager.
Make sure that you select the domain that contains the Business Objects NT
Users group.
2. Click the Business Objects NT Users group.
3. From the User menu, select Archives > Properties.
4. Click Add.
5. Select the groups and users you want, and then click Add.
6. Click OK.
Users will now be able to log into InfoView using their NT account if they use one
of the following formats:
• \\<NTDomainName>\<NTusername>
• \\<NTMachineName>\<LocalUserName>
Users do not have to specify the NT Domain Name if it is already specified in the
Default NT Domain field on the Windows NT tab.
Mapping via Windows 2000

1. From the Windows Start menu, point to Programs > Administrative Tools >
Computer Management.
The Computer Management dialog box appears.
2. In the left panel, under System Tools, click Local Users and Groups.
3. Open the Groups folder.
4. Select the Business Objects NT Users.
5. From the Action menu, select Archives > Properties.
The Users Properties dialog box appears.
6. Click Add.
The Select Users or Groups dialog box appears.
7. Select the groups and users you want, click Add, and then click OK.
8. Close the remaining dialog boxes.

Users will now be able to log on to InfoView using their NT account if they use the
following format:
• \\NTDomainName\NTusername
• \\NTMachineName\LocalUserName
Users do not have to specify the NT Domain Name if it is specified in the Default
NT Domain field on the Windows NT tab.
Go to Setting the source for standard modes on page 129.
If you chose Basic authentication

If you selected Basic authentication mode, you must configure your web server
to use Basic authentication as well.
The instructions are divided into type of web server:
• Apache: see below
• Apache with Tomcat: see page 127
• IIS: see page 128
If you’re using Apache

To configure the web server:
1. Navigate to <Web Server Install Dir>\bin, then type the following at the DOS
prompt:
htpasswd -c <Web Server Install Dir>\conf\users GS
2. To add users, type the following:
htpasswd <Web Server Install Dir>\conf\users auto
Make sure that the users created with htpasswd are already declared in the
repository.
3. Using a standard text editor, open the httpd.conf file located in
<Web Server Install Dir>\conf, then add the following to the end of it:
<Location />
AuthName "BA Authentication"
AuthType Basic
AuthUserFile "<Web Server Install Dir>\conf\users"
require valid-user
</Location>
Save your changes and close the editor.

4. Do either of the following:

- If you’re using an Apache web server with a Tomcat application server,
follow the instructions in the next section.
- If you’re using any other web/application server combination, start the
Business Objects server, the application server, and the web server.
If you’re using Apache/Tomcat

1. Open the server.xml file in an XML editor. You can find this file in the <Tomcat
Install Dir>.
2. Comment the Coyote connector by doing the following:
- Insert the following line:

just below the line:
Name="org.apache.jk.server.JkCoyoteHandler"/>
3. Uncomment and adapt the ajp13 connector by doing the following:
- Remove the  in the next line.
This part of the server.xml file should now look like this:





<Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
port="8009" minProcessors="5" maxProcessors="75"
acceptCount="10" debug="0" tomcatAuthentication="false"/>
5. Save your changes and close the editor.
6. In a standard text editor, open the httpd.conf file, located in <Apache Install
Dir>\conf.
7. Add the two lines in bold to the following section, in order to permit the
downloading and installation of BusinessObjects in 3-tier mode (the path
used in the Alias line is an example):
Alias /wijsp/distribution "C:/Program Files/
Business Objects/BusinessObjects Enterprise 6/
distribution"
<Directory "C:/Program Files/Business Objects/
BusinessObjects Enterprise 6/distribution">
Options FollowSymLinks
Allow from All
Satisfy Any
</Directory>
8. Save your changes and close the editor.
9. Start the Business Objects server, the application server, and the web server.
If you’re using IIS

After choosing Basic authentication in the Security Configuration Tool, do the
following:
1. Click Start > Programs > Administrative Tools > Internet Service Manager.
2. Click the Directory Security tab.
3. Uncheck Anonymous access.
4. Check Basic Authentication (Password sent in clear Text), then click OK.
The Inheritance Overrides dialog box appears.
5. Select the scripts, viewers, bin and classes child nodes, then click OK.
Go to Setting the source for standard modes on page 129.

Setting the authentication source

This section explains how to set the authentication and authorization source.
Setting the source for standard modes

To set the authentication and authorization source:
1. On the Authentication and Authorization Source page of the Security

Configuration Tool, select an authentication source:
- Repository
- External then Repository
- External
For a full description of the sources, see Authentication sources on page 45.
2. Do either of the following:
- If you selected Repository, there is no further configuration required; click
Next and then Finish. Go to Confirming your configuration on page 139.
- If you selected External then Repository or External, you must configure
the LDAP server connection by following the steps below.

3. Select a source from the External Source drop-down list.

If you have chosen the Windows authentication mode, you must select MS
Active directory.
4. In the Host Name box, type the name or the IP address of the server hosting
the external system.
5. In the Port box, type the port number through which the LDAP server is
accessed.
6. Click Connect.
7. If the connection is successful, click OK, and then click Next.
The Choose LDAP Connection page appears. Go to Configuring LDAP
connection parameters on page 132.
Setting the source for SSO mode

SSO (Single sign-on) refers to a situation where a user can access two or more
applications or systems while providing their log-on credentials only once,
making it easier for users to interact with the system.
SSO is based on a third-party security management system (see Optional Third-
Party Security Management Systems on page 59).
If you selected SSO as your authentication mode, you must provide SSO server
information on the Authentication and Authorization Source page.

To provide SSO server information:

1. In the Policy server host box, type the name or the IP address of the server.
2. In the Accounting port box, type the port number through which the server is
accessed.
3. Type the authentication and authorization port numbers.
4. In the Business Objects agent name box, type the name of the agent; for
example, the Business Objects Agent in SiteMinder.
See Configuring Third-Party Security Management Systems on page 105.
5. In the Shared secret box, type the password.
6. Click Connect.
If the SSO server responds, a confirmation message appears.
7. Click OK, and then Next.
The SSO Administrator page appears.
8. Enter the account name and password of the administrator, and then click
Next.
The Final Confirmation page appears.
9. Click Finish.
Activating SSO for Windows NT

To activate SSO for NT, you set SSO on the IIS web server:
1. On the IIS web server, change the access and authentication settings for the
Business Objects virtual directory as follows:
- Clear the Anonymous Access and Basic Authentication check box.
- Select the Integrated Windows Authentication check box.
2. Restart your IIS server.

Configuring LDAP connection parameters

After you finish setting the authentication and authorization source for a standard
(non-SSO) connection, the LDAP Configuration page appears.
To configure the LDAP connection parameters:

1. In the LDAP Naming area, select the Root DN.
2. Type the naming attribute.
3. If you want a name attribute to be displayed, select Display name attribute,
then type the attribute name in the text box.
4. In the LDAP Connection area, select whether to bind anonymously or with an
Administrator account.
This option is available only if you selected External then Repository or
External as the authentication source for Business Objects or Basic modes.

5. If you selected Bind with the following account, enter the account name and
bind password of your LDAP account in the Account DN and Bind Password
boxes. Read access is sufficient.
The Bind user name and password are for the LDAP account used to log into
LDAP and query for user attributes and groups.
6. Click Next.
The Mapping page appears.
Setting the mapping

To map to a group or user:
1. On the Mapping page, select the type of mapping you want.
- If you select LDAP user to Business Objects group, you have two options:
• LDAP group membership
• LDAP attribute
If you select LDAP attribute, type the attribute name in the Attribute box.
- If you select LDAP user to Business Objects user, security is inherited from
the repository user.

2. If you want to set LDAP attributes and filter queries, click Advanced, and go
to Customizing LDAP query parameters on page 134.
If you use a standard LDAP schema (users identified by ID or user-to-
repository mapping based on group or LDAP attributes), then you do not need
to set the Advanced LDAP Configuration.
3. Click Next.
The Final Confirmation page appears. Go to Confirming your configuration on
page 139.
Customizing LDAP query parameters

You can:
• adapt to non-standard LDAP schemas by defining new queries to be used by
the LDAP connector
• define the attributes you use in Business Objects applications
• define the Send To search
• specify a group membership query
• store an external password for use with Broadcast Agent
All of this is done on the Advanced LDAP Configuration page of the Security
Configuration Tool.
Use %1 in place of the search pattern or group name and %u in place of the user
name.

When you click Advanced on the Mapping page, the Advanced LDAP
Configuration page appears.
Store Password for Broadcast Agent

You can store an external user’s password for use with Broadcast Agent. To
store the password, select the Store Passwords in Repository check box at the
top of the Advanced LDAP Configuration page.

Customizing the search query

To customize the search query:
1. At the top of the Advanced LDAP Configuration page, in the Filter Formula
box, type the filter formula.
The filter determines the objects to be retrieved in the LDAP search query.
2. In the Base box, type the base (root) at which the query begins.
This represents the starting point of the search in the LDAP tree.
3. In the Scope drop-down list, select the scope.
This defines the level at which the search will be performed.
4. If you are not setting any additional Advanced LDAP parameters, click OK.
Creating an attribute
Each object in an LDAP directory is defined as a set of attributes, each attribute
having one or more values.
To create a new attribute:
1. Under the Attribute Returned area, click New.
The LDAP Attribute Configuration dialog box appears.
2. Type the name of the new attribute.

3. If you select the Extract Only check box, type the value you want extracted.
This avoids extracting all the values of the attribute.
4. If the attribute value corresponds to a group, select the Group Attribute
check box.

5. In the Use list, select an attribute type.

This corresponds to the Usage column in the Attribute Returned area of the
Advanced LDAP Configuration page.
You have the following choice of attribute types:
- User Unique Identifier
- User Display Name
- Business Objects Group
- Business Objects User
- Business Objects Variable
6. If you selected Business Objects Variable, the BO Variable Name text box
becomes active. Type the BO Variable name.
7. Click OK.
The Advanced LDAP Configuration page re-appears. The attribute you
created appears in the Attribute Returned area.
Editing an attribute
To edit an attribute:
1. In the Attribute Returned area, highlight the attribute you want to edit.
2. Click Edit.
The LDAP Attribute Configuration dialog box appears.
3. Make the changes you want. (See Creating an attribute on page 136 for
instructions.)
4. Click OK.
The Advanced LDAP Configuration page reappears.

Defining the Send To search

This defines the query used to enumerate Business Objects group membership.
To define the filter formula used for the search mechanism in the Send To
feature:
1. In the Filter Formula text box, type the filter formula.
2. In the Base box, set the Base (root) at which the query will begin its search.
3. In the Scope drop-down list, select the scope of the query.
4. In the Attribute Returned box, type the attribute the query will return.
If you select the Extract Only check box, type the value you want to extract.
5. In the Max. Fetched text box, type the maximum number of users queried.
6. If you are not setting any additional Advanced LDAP parameters, click OK.
Defining the Group Membership query

The Group Membership query determines the filter formula used to query groups
for the Broadcast Agent Send To feature. It is also used for Send to Groups.
To define the Group Membership query:
1. In the Filter Formula box, type the filter formula.
2. In the Base box, set the base (root) at which the query is to begin its search.
Select the corresponding value in the Scope drop-down list.
3. In the Attribute Returned box, enter the attribute the query is to return.
If you select the Extract Only option, enter the value you want to extract.
4. In the Max. Fetched box, type the maximum number of users queried.
5. Click OK.
The LDAP Mapping page appears.
6. Click Next.
The Final Confirmation page appears. Continue to the next section.

Confirming your configuration

Before you can close the Security Configuration Tool, you must confirm your
configuration. The Final Confirmation page lists the configuration choices you
made.
If the parameters are correct, click Finish.


Index
$INSTALLDIR 89 Authentication and Authorization Source window
.key file 89 129, 130
authentication certificates 25
Symbols authentication mode 38
Basic 41
3-tier deployments
Business Objects 41
using reverse proxies 35
how they work 42
SSO 41
A Windows 41
Access Packs 60, 107 Authentication Mode window 109, 122
Accounting port 131 authentication source 38, 45, 129, 130
activating SSL 79 advantages and disadvantages 46
Active Directory 58 description of different 45
and SSO 100 diagram 48
authentication 100 selecting standard 129
configuring 100 authorization
PWD rules 101, 103 defined 38
what you need to set 101 diagram 49
additional security options 15
AddModule line 83
B
Administration Console 69
base argument 56
Advanced LDAP Configuration window 134, 135
Basic authentication 41
advantages and disadvantages of SSL 25
advantages and disadvantages 44
Affiliate Agent 43
configuring the web server 126
Agent Conf object 111
how it works 44
Agent Properties dialog box 114
bind request 57
Agent Type Properties dialog box 113
binding 54
AllowLocalConfig variable 111
binding anonymously 132
Apache 80, 126
BODocGenISAPI.dll file 71
undeploying 80
bomain.key 89
ApacheSSL 84
BOPASS variable 99
applet communications 25
bosmapi.dll file 113
application servers
BOUSER variable 99
deported 32, 68
Broadcast Agent 89
in DMZ configurations 31
account 98
Attribute Setup tab 116
refreshing a document 99
attributes in LDAP 136
restrictions 98
authentication 130
storing passwords 135
defined 38
Index
buffer zone 29 D
Business Objects DAP (directory access protocol) 53
consulting services 9, 11 demo
documentation 8 materials 7
Documentation Supply Store 7 deployment configurations
support services 9 using reverse proxies 35
training services 9, 11 deported application server 68
Business Objects Agent 113 designer user 98
creating a realm 116 Developer Suite 8, 10
responses 115 digital certificate 24
Business Objects authentication 41 directory access protocol (DAP) 53
advantages and disadvantages 42 disambiguation 56
how it works 42 distinguished name (DN) 54
Business Objects server DMZ 29
and reverse proxies 35 typical topology 31
Business Objects system where to place reverse proxy 74
login 39 DN (distinguished name) 54
documentation
C CD 7
CA (Certificate Authority) 24, 79 feedback on 8
Certificate dialog box 86 on the web 7
certificate store 84 printed, ordering 7
Choose LDAP Connection window 130 roadmap 7
cipher text 26 search 7
common name (CN) 54 Documentation Supply Store 7
communication through firewalls 29
configuring Active Directory 100 E
configuring LDAP education see training
confirmation 139 encryption
configuring LDAP connection parameters 132 defined 26
configuring the ORB 69 External authentication source
confirming your LDAP configuration 139 advantages and disadvantages 47
consultants External then Repository authentication source
Business Objects 9 advantages and disadvantages 47
CookieDomain parameter 112 external user management system
CookieProvider parameter 112 mapping to groups based on external attributes
cookies 95
header 39 mapping to groups based on external user
CORBA 29 groups 95
Coyote connector 127 overview 58
CSR (Certificate Signing Request) 79 restrictions on Broadcast Agent 98
customer support 9 restrictions on InfoView 98
customizing LDAP queries 97, 134 restrictions on Supervisor 98
customizing search queries 136 supported directories 60, 107
Index
externalizing repository users 96 InfoView

extranets restrictions 98
and reverse proxies 35 web application 87
inner firewall 30, 69
F installing the BusinessObjects suite 78
International Telecommunications Union (ITU) 24
feedback
IP address translation 30
on documentation 8
IP filtering 28
filter formula 136
iswi.dll file 71
filtering 30
Final Confirmation window 138
firewalls 28 K
between cluster and application server 32 Knowledge Base 10
inner and outer 30
restrictions 68 L
rules 28
LDAP
setting up 67
and Business Objects 56
fixed credential static connection 99
attributes 54
bind request 57
G binding 54
Group Membership query 97, 138 configuring with Business Objects 92
group names 96 connection parameters 132
groupMembers attribute 54 creating an attribute 136
groupName attribute 54 customizing LDAP query parameters 134
groups in LDAP 95 customizing queries 97
group-to-group mapping 96 customizing search queries 136
guide organization 16 defining the Send To search 138
directory tree 56
H disambiguation 56
filter 55
how SSL connections work 25
Group Membership query 97
HTTP
group names 96
groups 95
headers 43
mapping 93
httpd.conf file 81, 83, 126
non-standard schemas 97
httpd.conf.ssl file 84
objects 54
HTTPS 25, 80, 83, 87
organizational tree 54
queries 54
I restrictions 98
IIOP protocol scope 55
and CORBA 29 search query 55
IIS 128, 131 Send To search 97
implementing a secure environment 63 subtree 55
overview 17 user entry 56
LDAP Attribute Configuration dialog box 136
Index
LDAP Configuration window 132 Policy Server 62, 111, 113

legacy repository 95 port 443/SSL 80
LegacyVariables parameter 112 port 80 69, 80
libbosmapi.so.1 file 113 Port line 84
libeay32.dll 82 preparing your environment 65
LoadModule line 83 public-key encryption 27
login PWD rules 101, 103
how it works 39
R
M recommended deployment for SiteMinder 108
mapping recommended features 15
group-to-group 96 repositories 89
LDAP users to Business Objects 93 Repository authentication source
LDAP users to repository groups 94 advantages and disadvantages 46
user-to-user 93 RequireCookies parameter 112
Mapping window 102, 104, 133 Response Properties dialog box 116
minimum security configuration 15 responses for Business Objects Agent 115
mod_SSL 81 restrictions on LDAP 98
multimedia reverse proxies 35
quick tours 8 and Business Objects server 35
my zip file 84 ASP deployments 75
defined 35
N JSP deployments 75
setting up 74
NAT (Network Address Translation) 28
where to place them in DMZ configurations 74
non-secure transactions 25
root DN 55, 97, 132
non-standard LDAP schemas 97
Rule Properties dialog box 117
O
S
Online Customer Support 9
scope 55
OpenSSL 80, 82
search
OpenSSL Client utility 85
documentation 7
openssl.exe 82
search query 55
ORB configuration 69
SearchUsers response 116
Orbix 2000 server 30
secure environment
organization of guide 16
implementing 63
outer firewall 30, 69
secure HTTP request 25
securing web browsers and web servers 23
P
PersistentCookies parameter 112
PKI infrastructure 53
plain text 26
planning a secure environment 19
overview 17
Index
Security Configuration Tool 120 SiteMinder 61

and Windows authentication 124 Agent Conf object 111
Final Confirmation window 138 AllowLocalConfig variable 111
installing 121 and SSO 108
launching 122 components 62
logging in 122 configuring 107
where choices are stored 121 configuring with 3-tier deployments 112
who can use it 121 CookieDomain parameter 112
security implementation process 16 CookieProvider parameter 112
selecting SSO 130 creating a Business Objects Agent 113
selecting standard authentication source 129 creating a web agent 110
Send To search 97 LegacyVariables parameter 112
defining 138 parameters 112
Send To workflow 98 PersistentCookies parameter 112
sensitive data 23 Policy Server 62, 111, 113
session ticket 43 recommended deployment 108
sessions RequireCookies parameter 112
and login 39 supported platforms and operating systems
defined 39 107
diagram 40 Test Tool 118
in Business Objects 39 Web Agent 62
types 39 webagent.conf file 111
setting authentication source 129 what you need to set 108, 109
setting security on Windows 77 with SSO 61
setting up firewalls 67 SOCKS proxy servers 28
SSL
activating 79
activating on Apache 80
disadvantages 25
handshake 24
how connections work 25
overview 24
ssleay32.dll 82
SSO 60, 100, 108
activating for Windows NT 131
configuring server connection 131
setting the source 130
SSO Agent 43
SSO authentication
how it works 43
SSO authentication mode 41
SSO server connection 131
SSO source
selecting 130
Index
static NAT 28 web browser and web server 23

storing passwords for Broadcast Agent 135 web server to Business Objects 23
subnet network environment 28 web servers
subtree 55 as security risk 35
Sun Java System Directory Server 58 communication with cluster 69
configuring 103 in DMZ configurations 31
Supervisor 88, 98 webagent.conf file 111
supervisor user 98 WebIntelligence Java Report Panel 85, 87
support WILoginServer 44
customer 9 Windows
symbolic name 57 setting security 77
symmetric-key cryptography 26 Windows 2000
mapping user accounts 124
T Windows authentication
TCP
how it works 42
Windows authentication mode 41
TCP ports 30
Windows NT
Test Tool (SiteMinder) 118
mapping user accounts 124
third-party connector 69
Windows32 80
third-party security management systems 60
Tips & Tricks 8
Tomcat 81, 127 X
training X.500 standard 53
on Business Objects products 9 X.509 standard 24
transaction validation 25
types of sessions 39
typical DMZ topology 31
U
uid 56
undeploying Apache 80
user entry 56
user externalization 93
user ID 96
user-to-user mapping 93
W
wasfadm tool
retrieving list of processes/ports 73
web
customer support 9
getting documentation via 7
useful addresses 10
Web Agent 62, 110
Index

Security For BO

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Security For BO

Încărcat de

Drepturi de autor:

Formate disponibile

Security for Business Objects

Windows and UNIX

Copyright Copyright © 2004 Business Objects. All rights reserved.

Chapter 1 Overview of Security in Business Objects 13

Part I Planning a Secure Environment

Chapter 2 Common Network and System Security Options 21

Chapter 3 Choosing Appropriate Authentication and Authorization 37

Chapter 4 LDAP and External User Management Choices 51

Chapter 5 Optional Third-Party Security Management Systems 59

Part II Implementing a Secure Environment

Chapter 6 Preparing Your Environment 65

Chapter 7 Configuring LDAP and External User Management 91

Chapter 8 Configuring Third-Party Security Management Systems 105

Chapter 9 Using the Security Configuration Tool 119

Maximizing Your Information Resources

Documentation from the products

Documentation on the web

Buy printed documentation

Search the Documentation CD

How can I get the most recent documentation?

Tips & Tricks

Developer Suite Online

Send us your feedback

Maximizing Your Information Resources

How we can support you?

Online Customer Support

Having an issue with the product?

Looking for the best deployment solution for your company?

Looking for training options?

Useful addresses at a glance

Business Objects Documentation Feedback or questions about documentation.

Maximizing Your Information Resources

www.techsupport.businessobjects.com Starting point for answering questions, resolving

www.businessobjects.com/services Information about registering with Worldwide

Useful addresses at a glance

About this guide

Conventions used in this guide

Maximizing Your Information Resources

How security fits into your implementation of BusinessObjects 6.5

Before installing BusinessObjects 6.5

After installing BusinessObjects 6.5

Overview of Security in Business Objects

What’s the bare minimum in terms of security?

What you should do

Additional security options

How this guide is organized

Where you Step in overall security implementation process Page

Following is a brief description of each section in the guide.

Overview of Security in Business Objects

Planning a secure environment

Choosing appropriate authentication and authorization

LDAP and external user management choices

Third-party security management choices

Implementing a secure environment

How this guide is organized

Setting up reverse proxies

Configuring operating system security on Windows 2003

Installing and configuring the BusinessObjects 6.5 suite

Configuring LDAP and external user management

Configuring third-party security management systems

Using the Security Configuration Tool

Overview of Security in Business Objects