This manual describes the steps necessary to enable windows AD authentication for Crystal Reports Server 2008 and Business Objects XI 3.0.

In Active Directory a user who will serve as a service account must be created. Also, there will have to be made one or more groups for users to inhabit. The groups will allow BO to see which usernames to import. Finally, a service principle name needs to be created.
* Create an AD group or multiple groups for BO users and make the users members of that group or groups.

• Check for the presence of the service account “BOservice” and, if it does not exist yet, create it.
• Select the options “user cannot change password” and “password never expires”.
• Open a command prompt and use the following command:

setspn -A BOBJCentralMS/crystalsrv.company.local BOservice

Check:

C:\Windows\system32>setspn -Q BOBJCentralMS/crystalsrv.company.local
CN=BusinessObjects Service,OU=ServiceAccounts,DC=company,DC=local
        BOBJCentralMS/crystalsrv.company.local
        BOBJCentralMS/crystal01srv.company.local

Existing SPN found!

• Open in AD the user BOservice. Go to the delegation tab and select the option “Trust this user for delegation to any service (Kerberos only)”.

Note: This tab only appears when the previous step is executed correctly.

On every machine on which the Server Intelligence Agent is active there has to be a link between this Agent and the created service account in AD.

• Go to My computer → Manage → Local users and groups → groups
• Rightclick on Administrators and choose “add to group”
• Add the AD login (BOservice) and confirm.
• Go to Start → All Programs → Crystal Reports Server 2008 → Crystal Reports Server 2008 → Central Configuration Manager and stop the Server Intelligence Agent.
• Doubleclick on Server Intelligence Agent to open the properties.
• Enter a username and password in the “Log on as” frame (company\BOservice) and confirm.
• Start the Server Intelligence Agent service again.

In the Central Management Console of Business Objects some settings have to be made to enable AD authenticatie.

• Log in on the CMC as administrator.
  • http://crystalsrv:8080/CmcApp
• Navigate to Authentication → Windows AD.
• Check the option Windows AD Authentication to enable
• Click on the “” and supply the AD administration credentials and the default domain (the latter: uppercase!)in the newly opened screen.
• In the next field, supply the AD Group. This will be converted to the correct conventions after clicking “Update” later on.
• Choose “Use Kerberos authentication” and supply the service principal name (BOBJCentralMS/crystalsrv.company.local).
• Choose “New Alias” for “Create a new account…”.
• Choose “Update options” for “New aliases will be added…”.
• Choose “Update”.
• In the CMC, navigate to “Group list”. The AD BO group should now be present in the overview.
• In the CMC, navigate to “User list”. The AD users that have been added to the group should now be present in this overview.

To facilitate AD authentication there are two files that need to be edited. Also, two new files will have to be created. To finalize this, the Tomcat configuration needs to be adapted an Tomcat needs to be restarted.

• Log in on the BO server and open Windows explorer.
• In the root, create a folder named WINNT and open it.
• Create a new file, krb5.ini, with the following content:

[libdefaults]
default_realm = COMPANY.LOCAL
dns_lookup_kdc = true
dns_lookup_realm = true
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
udp_preference_limit = 1
[realms]
COMPANY.LOCAL = {
kdc = AD.COMPANY.LOCAL
default_domain = COMPANY.LOCAL
}

• Now create another new file, bscLogin.conf, with the following content:

com.businessobjects.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required debug=true;
};

• After creation of the files, doublecheck the file extension (on a new server, file extensions are hidden).
• Go to the directory C:\Program Files (x86)\Business Objects\Tomcat55\webapps\InfoViewApp\WEB-INF
• Edit web.xml

    <!-- Choose whether to let the user change the CMS name -->
    <!-- If it isn't shown the default System from above will be used -->
    <context-param>
        <param-name>cms.visible</param-name>
        <param-value>false</param-value>
    </context-param>

    <!-- You can specify the default Authentication types here -->
    <!-- secEnterprise, secLDAP, secWinAD, secSAPR3 -->
    <context-param>
        <param-name>authentication.default</param-name>
        <param-value>secWinAD</param-value>
    </context-param>

    <!-- Choose whether to let the user change the authentication type -->
    <!-- If it isn't shown the default authentication type from above will be used -->
    <context-param>
        <param-name>authentication.visible</param-name>
        <param-value>false</param-value>
    </context-param>

• Go to the directory C:\Program Files (x86)\Business Objects\Tomcat55\webapps\CmcApp\WEB-INF
• Edit web.xml

    <context-param>
        <param-name>cms.visible</param-name>
        <param-value>false</param-value>
    </context-param>
    <!-- You can specify the default Authentication types here -->
    <!-- secEnterprise, secLDAP, secWinAD, secSAPR3 -->
    <context-param>
        <param-name>authentication.default</param-name>
        <param-value>secWinAD</param-value>
    </context-param>
    <!-- Choose whether to let the user change the authentication type -->
    <!-- If it isn't shown the default authentication type from above will be used -->
    <context-param>
        <param-name>authentication.visible</param-name>
        <param-value>true</param-value>
    </context-param>

• Go to Start → All Programs → Tomcat → Tomcat Configuration (must be run as administrator)
• Open the tab Java and add the following two lines:

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

• Choose Apply and close the tool.
• Restart the Tomcat service.

Now we can start testing the Windows AD authentication. Go to the webportal of the CMC or Infoview en try to log in with a useraccount which is present in the AD BO group. If this does not work, try to log in on the desktopapplication on the BO server (Start → All programs → Crystal reports server 2008 → Crystal reports server 2008 → Business view manager) using AD authentication.When AD authentication on the Business view manager works properly, but web authentication does not, then an error was made during configuration. Check the logging from Tomcat (/business objects/tomcat55/logs) for errors so this issue can be investigated. If logging in through Business view manager does not work, there is probably a problem with the connection to Windows AD.

Note: for this installation we are using RC4 encryption, which is standard for Windows 2008 installations. It is also possible to use DES encryption, but it is discouraged by SAP to use this because of the many problems caused by the DES protocol. However, for testing purposes, it might be usefull to use DES when the encryption is suspected to cause issues.

After importing the groups from the Active Directory it is important to set the correct rights to each imported group. By default, all imported AD groups inherit the Administrators group and the Everyone group in the user security tab of the AD group. Although this looks daunting, this actually doesn’t provide any other right then showing the basic user interface. If we want to add more rights to our AD group members, we have to make certain folders with reports members of members of the newly created AD group aliases in BO. This can be done by right-clicking the folder you wish to share and choosing manage → security → user security. In this screen the folder can be connected to the required (ad alias) group and the level of security (e.g. read, full control) can be granted.
Also, all new AD group aliases have to be member of the Everyone group. Otherwise, no actions will be allowed. Not even if the group is member of Administrators.

When creating administrators, one needs to go to the alias ad group and go to the properties > member of tab. Here, the Administrators group and the Everyone group need to be added. This is enough to grant admin rights.

After configuring AD authentication, we created a testuser “testbo” and ran some tests.

• Adding user: added user at 14:40 to the group, tried logging in at 14:43, success.
• Disabling user: disabled user at 14:45, tried logging in directly after, error message on credentials received, success.
• Enabled user: logging in was immediately possible: success.
• Removing user from group: removed user at 14:47, tried logging in at 14:50, no success, tried logging in at 15:00, error message received on credentials, success.
• Adding user to group: logging in was immediately possible, success.
• Removing user from AD: logging in was immediately impossible, error message on credentials, success.
• Alias in BO was removed after about 10-15 minutes after removing the user from AD. Although it is not instantaneous this is not a problem, since user is not able to use another authentication method with this alias.