Windows AD authentication for Business Objects using Kerberos – Part II

This is our continuation of our SSO configuration from starting from SIA configuration.

4.     Configuring the Server Intelligence Agent to use the service account

In order to support Kerberos, Server Intelligence Agent must be configured in CCM to log on as the service account:

To configure a Server Intelligence Agent

1)  Start the CCM.

2)  Stop the Server Intelligence Agent.

3)  Double-click the Server Intelligence Agent and the Properties dialog box is displayed.

4)  On the Properties tab:

• In the Log On As area, deselect the System Account check box.
• Enter the user name and password for the service account.
• Click Apply, and click OK.

5)       Start the server again.

5.     Configure the AD plug-in

In order to support Kerberos, we have to configure the Windows AD security plug-in the CMC to use Kerberos authentication.

To configure the Windows AD security plug-in for Kerberos

• Go to the Authentication management area of the CMC and Click the Windows AD tab.

• Ensure that the Windows Active Directory Authentication is enabled check box is selected.
• In the Windows AD Configuration Summary area of the page, click the link beside AD Administration Name.
• Enter the credentials that have read access to Active Directory in the Name and Password fields.

Note:

Use the format Domain\Account in the Name field LIKE NA\ BOLab-Admin.

• Enter the default domain in the Default AD Domain field.

Note:

Use FQDN format and enter the domain in uppercase, here it is NA.HEXAWARE.COM

• In the Mapped AD Member Group area, enter the name of an AD group whose users require access to Business Objects Enterprise, and then click Add.

• In the Authentication Options area, select Use Kerberos authentication.
• In the Service Principal Name field, enter the account and domain of the service account or the SPN mapping to the service account which was created

In this case, BOBJCentralMS/TESTSERVER.NA.HEXAWARE.COM.

• Click Update

6.     Configure Tomcat web.xml file

Modify the web.config file to ensure Windows authentication is enabled.

To configure InfoView for AD authentication mode, configure the web.config file in the

\Tomcat55\webapps\InfoViewApp\WEB-INF directory.

Edit the web.xml. Then, change the authentication default value to secWinAD.

7.     Configure the Krb5AuthLoginModule and krb5.ini

Create a folder in C:\WINNT to store the following two files:

1. krb5.ini
2. bscLogin.conf

The contents of the krb5.ini and the bscLogin.conf were the following:

Note: 1. This should be done on all computers that run application servers.

2.  KDC is the Domain Controller(s) of the particular domain.

8.     Configure the Tomcat Java option

Launch the Tomcat Configuration program & add the following Java command in the Java Optionsof the Java tab.

-Djava.security.auth.login.config=C:\WINNT\bscLogin.conf

-Djava.security.krb5.conf= C:\WINNT \krb5.ini

Hope this will be useful for Kerberos based windows AD authentication. Feel free to get back to me in case of any issues. I am privileged to helping you all. Happy Blogging!

Windows AD authentication for Business Objects using Kerberos

Hi All,

Hope you continue to read our Series of blogs. Let me discuss something about Single Sign-on implementation in Business Objects in this blog.

Configuring Windows Active Directory SSO with the SAP BusinessObjects XI 3.1 is one of the challenges for a Business Objects Administrator. If you go with java based BO deployment, utmost care should be taken as Java is case sensitive.

What is Single sign-on?

Single sign-on (SSO) is a user authentication process that permits a user to enter one name and password to access multiple applications. This authenticates the user for all the applications they have been given rights to and eliminates further prompts.

Role of Kerberos in SSO

Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography where a user authenticates to an authentication server that creates a ticket. This ticket is actually sent to the application which can recognize the ticket and the user is granted access.

This blog refers

TESTSERVER - BusinessObjects server installed with Windows 2008 server. The version is XI 3.1 SP3

ADSERVER – Active Directory server installed with Windows 2003 server. Its Domain Functional Level is 2003.

BOLAB-ADMIN – Service Account used to run Business Objects Service.

Steps for configuring Windows AD authentication

Below is the general overview of the steps, which are required to configure the Business objects windows authentication using Kerberos.

• Setting up a service account
• Configure the service account rights
• Register Service Principle Name (SPN)
• Configuring the Server Intelligence Agent to use the service account
• Configure the AD plug-in
• Configure Tomcat web.xml file
• Configure the Krb5AuthLoginModule and krb5.ini
• Configure the Tomcat Java option

Setting up a service account

To configure Business Objects Enterprise using Kerberos and Windows AD authentication, we require a service account which should be a domain account that has been trusted for delegation. We can either use an existing domain account or create a new domain account. The service account will be used to run the Business Objects Enterprise servers.

Setting up a service account with delegation on a Windows 2003 Domain

• Create an account on the domain controller or use an existing account.
• Right-click on the user accounts, then select Properties.
• Click the Delegation tab.
  • Select the Trust this user for delegation to any service(Kerberos Only

1.     Configure the service account rights

In order to support the Active Directory authentication, you must grant the service account the right to act as part of the operating system and log on as a service. This must be done on each machine running the Server Intelligence Agent Service.

To configure this

1. Click Start -> Administrative Tools -> Local Security Policy

2. Then Local Policies and then click User Rights Assignment.

3. Double-click Act as part of the operating system and click Add User or Group button.

4. Add the user account that has been trusted for delegation and clicked OK.

5. Double-click Logon as service and click Add and click Add User or Group button.

6. Add the user account that has been trusted for delegation and clicked OK.

In order to support Kerberos, we must grant the service account the right to act as part of the operating system. This must be done on each machine running the below servers:

• CMS
• Page Server
• Report Application Server
• Web Intelligence Report Server

Adding the Service account to the Administrators Group

• On the desired machine, right-click My Computer and then click Manage.
• Go to Configuration > Local Users and Groups > Groups.
• Right-click Administrators and then click Add to Group
• Click Add… and enter the logon name of the service account.
• Click Check Names to ensure the account resolves.
• Click Ok and then click OK again.
• Repeat these steps for each Business Objects server that has to be configured.

2.     Register Service Principle Name (SPN)

If you are deploying Business Objects Services in a network that uses the Kerberos protocol for mutual authentication, you must create a Service Principal Name (SPN) for the Business Objects services if you configure it to run as a domain user account. The SETSPN utility is a program that allows managing the Service Principal Name (SPN) for service accounts in Active Directory.

• Open a command prompt and enter this command:

SETSPN.exe –A BOBJCentralMS/HOSTNAME serviceaccount

Replace HOSTNAME with the fully qualified domain name of the machine running the CMS service, for example Testserver.NA.HEXAWARE.COM. Replace service account with the name of the service account that runs the CMS service. In this case it is BOLab-Admin.

SETSPN.exe –A BOBJCentralMS/TESTSERVER.NA.HEXAWARE.COM BOLab-Admin

• Once run, we should receive a message similar to the below:

Registering ServicePrincipalNames for CN=ServiceCMS, CN=Users, DC=DOMAIN, DC=COM BOBJCentralMS/HOSTNAME.DOMAIN.COM Updated object

To get a listing of what is currently registered for the account.

SETSPN.exe –L BOLab-Admin

I will discuss more about the subsequent steps in the upcoming blog.

Read More about  Windows AD Authentication

Business Objects File Repository Servers

Functions of File Repository server (FRS)

The BusinessObjects File Repository Servers(FRS) are responsible for listing files on the server, adding files to the repository, and removing files from the repository. FRS also responsible for the creation of file system objects such as exported reports, and imported files in non-native formats.

Default FRS location in BOE Installation?

FRS can be found on your disk at \Program Files\Business Objects\BusinessObjects Enterprise 12\FileStore (for XI 3.x) in default installation. The two main directories under this location are Input and Output. The Input directory stores the report templates and thumbnail images, while the Output directory stores the results from running those templates. Thus, the Output directory is normally many times larger than the Input directory. Each of these directories is managed by its own BO XI File Repository server.

In every BusinessObjects Enterprise implementation there is an Input and an Output File Repository Server. Both manage their respective directories and handle all aspects of file management.

Input FRS

The Input File Repository Server manages all of the report objects and program objects that have been published to the repository. It can store .RPT, .CAR, .EXE, .BAT, .JS, .XLS, .DOC, .PPT, .RTF, .TXT, .PDF, .WID files. In the case of .RPT files, they are stored as report definition files only which do not contain any data.

The Report Properties page of the CMC shows you the location of the Input report files. The RPT report template can be found at frs://Input/a_084/004/000/1108/ca067d4f1710cbc.rpt

Exploring to this location shows two files: the RPT file with the name indicated on the report properties page of the CMC and a JPEG file, which serves as the thumbnail image.

Output FRS

The Output File Repository Server manages all of the report instances (saved data copy of the report) generated by the Report Job Server or the Web Intelligence Report Server, and the program instances generated by the Program Job Server. It also manages instances generated by the Web Intelligence Report Server and the LOV Job Server. It can store the following files: .RPT, .CSV, .XLS, .DOC, .RTF, .TXT, .PDF, .WID. For .RPT and .WID files are stored as reports/documents with saved data.

Since Output FRS stores the report instances, deleting instances would remove instances not the actual reports. However the report structure will be stored in the Input FRS.

Using Query Builder we can find the location of the Output File repository files. The following query may be handy if you already know the report name.

SELECT SI_NAME, SI_KIND, SI_FILES, SI_INSTANCE from CI_INFOOBJECTS
Where SI_NAME =’xxxx’

If the SI_INSTANCE value is false then the InfoObject is the actual report and SI_PATH will be in Input FRS. If SI_INSTANCE is true then the InfoObject would be an Instance and the SI_PATH will be in Output FRS.

Exploring to this location shows the actual instance file pertaining report data with the appropriate export format based on the scheduling parameters.

Diagnosing File Repository Servers

Repository Diagnostic Tool (RDT) is a command-line tool that scans, diagnoses, and repairs inconsistencies between your Central Management Server (CMS) system database and the File Repository Servers (FRS) filestore, or inconsistencies that can occur in the metadata of InfoObjects stored in the CMS database. This inconsistencies may occur during unexpected events such as disaster recovery, back-up restoration, or network outages. During these events, the CMS system database may be interrupted while performing a task. This can cause inconsistencies with objects in the CMS system database.

List of inconsistencies that could potentially occur in repository which RDT can identify are

Inconsistency	Description	Repair Actions
InfoObject exists, but no file	It is possible that an InfoObject exists in the CMS, but there is no file FRS	Delete the InfoObject, unless otherwise told
File exists but no InfoObject	It is possible the file exists but there is no corresponding InfoObject	User is notified to republish the object
Invalid Parent ID	An InfoObject can potentially have an invalid parent reference	The object and its children will be moved Into a folder call ‘Repair’.
Last Successful Instance	The reference to the last successful scheduled instance could be invalid	Remove the ID and let the CMS automatically recalculate it
Invalid Target ID	A shortcut could be pointing to an invalid object	The shortcut object will be deleted, unless told otherwise.
File size is wrong	There can be information discrepancies between the InfoObject and actual file	Update the InfoObject
Empty folders in the system	There may be empty folders due to old objects	Remove the empty directories, unless otherwise told.

Limitations for File Repository Servers

• The Input and Output File Repository Servers cannot share the same directories. This is because one of the File Repository Servers could then delete files and directories belonging to the other.
• In larger deployments, there may be multiple Input and Output File Repository Servers, for redundancy. In this case, all Input File Repository Servers must share the same directory. Likewise, all Output File Repository Servers must share a directory.