SSO with 11.0.6 - Successful login - followed by Unable to Authenticate

[gohabsgo]

Hey Folks,
We have a number of successful deployments with SSO working just fine, unfortunately we have 2 of them that aren't playing nice.  We're using IIS images from the working installs so I don't think it's a mis-configuration in that aspect.  There doesn't seem to be anything exception about the two non working environments that would differentiate between our good ones.  Here's our situation;

We are SSO'ing into Cognos from an external website, we pass our namespace and credentials via Cookies and when Cognos opens up we're presented with the standard login screen (without an invalid credentials message as if it wasn't accepted)

What's bizarre is that according to the logs everything seems to be successful, if we login to the portal as an admin, we're able to see that the user we attempted to SSO into has logged in successfully (via his ID showing as a link - shows previous login).


In fact the cogserver.log shows the following;

10.90.147.10:930002017-11-07 15:23:29.926-5                         
A308948536CBBDF76ADA952DD49511D083FD6731187D470F74934AC9CFF34557       
d2M4qhssM2Gdv8Mw82j8MqlCdwl9Mvw98CswsqCh0Default Executor-thread-51 
AAA62Audit.RTUsage.cms.CAM.AAA.SRVCLogonAccount                   
/directory/USERID Success<parameters><item name="namespace"><![CDATA   
[NAMESPACEID]]></item><item name="username"><![CDATA                 
[USERID]]></item><item name="   
display name"><![CDATA[USERID]] 
></item><item name="CAMID"><![CDATA[CAMID("NAMESPACEID:u:117")]]     
></item><item name="REMOTE_ADDR"><![CDATA[IP]]></item><item   
name="TENANTID"><![CDATA[]]></item></parameters>                   

But in that same timestamp event;

<messageString>CM-REQ-4159 Content Manager returned an error in the     
response header. The error "cmAuthenticateFailed CM-CAM-4005 Unable to 
authenticate. Check your security directory server connection and       
confirm the credentials entered at login." can be found in the response
SOAP header.

We did an AAAtrace and it seems to fail first at this point;

Trace.CAM.AAA.SRVC.logon.legacyProcessLogon.legacyProcessOneLogon.     
commonProcessOneLogon.applicationLogon.authenticateUser.selectNamespace.
PromptForNamespaceSelection<exception><![CDATA[com.ibm.cognos.camaaa. 
internal.auth.exception.NamespaceSelectionException

We opened a ticket with support, but because our authentication is using CJAP and the SDK to generate the SSO functionality they're refusing to help (frustrating, considering how much we're paying for support).

Thanks for anything you can point me towards

[Jeff H.]

The installation upgrades blows away any custom .dlls that you have put into the bin64 folder. For SQL Server I have to remember to re-add sqljdbc_auth.dll to that folder.

[gohabsgo]

The installation upgrades blows away any custom .dlls that you have put into the bin64 folder. For SQL Server I have to remember to re-add sqljdbc_auth.dll to that folder.

Not sure how that's relevant to SSO.

[TomCognos]

Jeff H. is right.

https://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_ssl_sqlserver.html

Bottom of the page under the heading results.

Important
For single sign-on (SSO) and Windows authentication, you need to put sqljdbc_auth.dll in the bin64 directory. Windows authentication is a single sign-on setup. The selection in Configuration Manager for the Content Manager is called Microsoft SQL Server database (Windows Authentication).

Though if its a straight lift and shift image, it could be something you have missed within IIS in configuration for the new server. You could try deleting the App Pool and IIS website for Cognos and starting again from scratch.
Or you could try deleting some of the Cognos Configuration entries and recreating them. Might be cached and still pointing to different content stores. (Long shot)
Lastly check server accounts that Cognos is using has the appropriate permissions and if those servers are setup to communicate with your authentication source.

[gohabsgo]

Ahh ok, good to know.  But we're not using windows authentication.  We're using CJAP and SDK.