IBM’s Cognos Business Intelligence software relies on IIS for front-end publishing and authentication. If you are prompted to enter your credentials to access Cognos website or administrator console, it means Windows Authentication is failing for IBM Cognos. Here is what to do in this case.
Background
One of the ways to host Cognos BI is to use IIS. By configuring Windows Authentication in IIS, you can allow users to access Cognos without typing any credentials. This SSO (Single Sign-on) access requires certain steps to be followed as explained here and here.
If any of the settings are missing, you may come across an annoying prompt to enter your credentials. It quickly becomes cumbersome to enter your information every time you access to Cognos website.
Are you receiving Secure Channel (schannel) errors? Check these posts out.
Steps to follow when Windows Authentication is failing for IBM Cognos
Make sure that you review the steps in the IBM documentation to configure IIS (Links are above). In addition to the instructions, there are a few more things to check to solve this issue.
Solution 1
A common solution to this issue is that adding website’s domain name into the Intranet Zone of Internet Explorer as pointed out in a Microsoft support document:
Internet Explorer must consider the requested URL to be on the intranet (local). If the computer name portion of the requested URL contains periods (such as http://www.microsoft.com and http://10.0.0.1), Internet Explorer assumes that the requested address exists on the Internet and does not pass any credentials automatically.
Internet Explorer May Prompt You for a Password
Solution 2
Windows Authentication is performed by using either NTLM or Kerberos (preferred). Kerberos relies on SPNs (Service Principal Names) to operate. If there are no SPNs or there are duplicate SPNs for your domain, this might be the reason why Windows Authentication is failing for IBM Cognos. as explained in this article.
Follow the steps below to find and remove duplicate SPNs:
- Check current SPNs
Run this at Command Prompt: setspn -F -q /cognosdev
If it doesn’t bring any records or if it brings duplicate records, Kerberos authentication may not work with Cognos. In this case, continue with the following steps. Otherwise, do not perform the steps below.
For example: The command may bring a result like the one below. There are duplicate records (in bold) which should be fixed.
Checking forest DC=MyDomain,DC=com
CN=MyDomainUser,CN=Users,DC=MyDomain,DC=com
HTTP/MyReportServer
HTTP/MyReportServer.MyDomain.com
CN=MYREPORTSERVER,CN=Computers,DC=MyDomain,DC=com
WSMAN/MyReportServer
WSMAN/MyReportServer.MyDomain.com
TERMSRV/MYREPORTSERVER
TERMSRV/MyReportServer.MyDomain.com
RestrictedKrbHost/MYREPORTSERVER
HOST/MYREPORTSERVER
RestrictedKrbHost/MYREPORTSERVER.MyDomain.com
HOST/MYREPORTSERVER.MyDomain.com
Existing SPN found! - Remove duplicate SPNs (if there are any)
Run the commands below to remove duplicate SPNs in the example above.
setspn -d http/MyReportServer.MyDomain.com MyDomainUser
setspn -d http/MyReportServer MyDomainUser - Add new SPNs (if needed)
Run the following commands to get the Service Principal Name added to the Web Application Pool Account:
Setspn -f -s http/cognosdev.domain.com domain\cognosadmin
Setspn -f -s http/cognosdev domain\cognosadmin
Add this line to the Windows Authentication tag in the applicationHost.config file (under System.WebServer heading):
useAppPoolCredentials=”true”
Save the file and run iisreset
Note: You may also want to check your load balancer settings as a misconfigured load balancer can change NTLM token transmitted through. An edited NTLM token will break windows authentication.
