TM1 Forum

Hi all,

I inherited a PA / PAW server that was installed with SSO before I arrived. It's a Windows Server 2016 machine with IIS 10 and PA 57 installed.

For reasons I won't go into, the server was setup using my colleague's AD account, rather than a dedicated service account. The account ended up being used for everything -- the Windows services, API Authentication and database connection, and who knows what else.

When my colleague resigned, his AD account was disabled, and of course all hell broke loose.

I re-enabled the account temporarily and did my best to unravel the maze of dependencies as best I could. However, when it came to disabling the AD account again, I found it caused SSO to stop working.

Users can still log in by typing their AD username and password and everything works as expected, but it would be ideal to re-establish SSO.

I can't for the life of me understand how the SSO could be dependent on an AD account, but I have reenabled the account and the SSO magically starts working again. It is definitely the cause.

Does anyone have any suggestions what could be happening?

Harvey

I am assuming you have a local install.

Have you checked what account is being used in the "ApplicationPoolIdentity" within the ICAPool of IIS ?

Once you've changed the account STOP and then START the ICAPool

Does this work ?

Ajay

Ajays response would be my first bet. But some other questions if that doesn't work... What method of single sign on is setup, kerberos or identity mapping. If you have a single sign on option set to identity mapping within advanced properties of the ca config, the it's identity mapping, otherwise its kerberos. If its kerberos is kerberos account set up may not have privileges to pass the token.

Have you had to change the binding account for the active directory/authentication within cognos configuration?

The Applcation Pool was ok, but burnstripe's suggestion about the CA Binding Identity did the trick. Thanks so much to you both!