InfoView Single Sign-On (SSO) with DNS-Alias (BOXIR2, Tomcat)

[Former Member]

Hello,

I have configured my Crystal Reports Server XI R2 and Tomcat to use Windows AD with Kerberos for Single Sign-On to InfoView.

I did all this for the acutal hostname (e.g. Crystal01.domain.com).

Now I would like to do this in addition for a DNS-Alias (e.g. Reporting.domain.com)

When I try to access InfoView with that Alias I get:

"Unable to logon to InfoView. Please contact your system administrator for assistance. Please close your browser before continuing."

Is there a way to configure this?

Thanks

Christoph

[BasicTek · Accepted solution]

Hi Christoph,

Think of your vintela service account as a point of many entries. By default you created an SPN for the FQDN of tomcat (HTTP/Crystal01.domain.com) and entered this value in the infoview web.xml. Since you are on XIR2 you probably enabled DES, reset the account password, and matched case of the SPN (not required on 3.0 with RC4).

In order for clients to SSO they will request 2 types of tickets. 1 for their own userID amd then one based on the URL in the browser (not including the port #) like HTTP/Crystal01.domain.com. You can view this with a microsoft utility known as kerbtray (free download at Microsoft.com)

So you can add additional points of entry (DNS redirect, load balancer) simply by running setspn -a HTTP/Reporting.domain.com myvintelaserviceaccount where myvintelaserviceaccount is the account that you originally ran ktpass to (create the idm.princ value and keytab)

Some more rules of thumb on SPN creation

1) SPN's should usually be created in pairs HTTP/FQDN and HTTP/hostname or shortname. This is due to the fact that some times browsers will attempt to hit either one

2) If your server has a fixed IP you should add an HTTP/ip.ip.ip.ip as a backup access point when testing (also allows SSO on the tomcat server)

3) If you have DES selected on your service account case sensitivity matters on the inital ktpass SPN but not on these "additional" SPN or points of entry (since these values are not being used in the web.xml

To note when creating SPN's in microsoft any accidental duplicates will cause problems in AD. The current tools available (ktpass and setspn) do not check for SPN duplicates when being run. Using a tool like Microsoft's AD explorer can help you search AD for duplicate SPN's should this happen. You may want to open a message with support on this one to get an authentication engineer involved.

Regards,

Tim