Note:
The focus of this article is for Cognos Administrators that applies whether you are using QueryVision’s Web Parts for Cognos or accessing Cognos BI servers via Cognos Connection.
Many, if not most organizations want Single Sign On (SSO) for Cognos access for their users. While relatively straightforward for NTLM (using REMOTE_USER), Kerberos is more difficult, partly due to the inherent complexity and manual nature of setting up Kerberos in Windows with Active Directory and partly due to some gotcha’s when making changes to Active Directory accounts and properties
Configuration is covered in the following document [link] in detail, but I’ll highlight some of the issues we’ve encountered over the years. This guide applies to II 6, 7 and 7.5 although the exact instructions may differ. These settings were tested with a Windows 2003 server and Windows 2003 native AD domain and IIS 6 with Cognos 10.1 FP1.
Enabling single sign to Cognos BI Servers for Active Directory (PDF)
It covers 3 scenarios for Active Directory/SSO
- [Cognos] Native Active Directory using Kerberos
- [Cognos] Native Active Directory using NTLM/Remote User
- [Cognos] LDAP access for Active Directory using NTLM/Remote User
The single most important issues to watch for are:
SSO in general
- Disable anonymous access in IIS for the Cognos Virtual Directories/URLs and enable Integrated Windows Authentication
- Ensure these security settings propagate to cgi-bin, etc.
- Set the Gateway namespace to the Active Directory namespace.
Kerberos SSO
- Enable Kerberos Delegation for the IIS server and Cognos server service accounts (computer or domain user account used as service account)
- Remove the singleSignOnOption = IdentityMapping for the Active Directory Namespace
- Reboot all machines (see below)
NTLM SSO
- ensure singleSignOnOption = IdentityMapping are added exactly as shown (case sensitive)
It is highly recommended to re-boot the Cognos Server, IIS server and any workstation(s) used for browser testing for SSO – particularly after changes to Active Directory (e.g. change user account or service account “trust for delegation” properties).
These (type of) changes appear to take some time to propagate from the Active Directory Domain Controller to other computers (or VMs) in the domain. Rebooting ensures that the machines re-sync/re-login to Active Directory for up to date properties. The symptoms are that changes to either AD or Cognos Configuration for Kerberos related properties don’t act as expected.