Cognos Analytics

 View Only

 Scheduled jobs fail due to expired Microsoft EntraID refresh tokens in Cognos Analytics with MFA

Yauhen Panimatchanka's profile image
Yauhen Panimatchanka posted Tue June 03, 2025 09:35 AM

We are currently using Cognos Analytics 11.2.4 with Microsoft Entra ID (formerly Azure AD) as the authentication provider — configured using the Microsoft Identity integration. All users authenticate through MFA, in accordance with corporate policy.

We’re encountering a persistent issue where scheduled jobs (such as report generation) fail due to expired refresh tokens.
This typically happens within 1–4 weeks, depending on token lifetime policies, and is accompanied by errors like:

CM-REQ-4159 Content Manager returned an error in the response header.
cmAuthenticateFailed CM-CAM-4005 Unable to authenticate.
CAF-WRN-2082 An error has occurred. Please contact your administrator.

We’ve reviewed existing forum posts and IBM documentation, and understand this is expected behavior when using MFA with refresh_token authentication strategy.
We also tested switching to the id_token strategy, but this is not supported in combination with MFA, and leads to login failures.

Business context:

  1. We cannot disable MFA due to corporate security policies.

  2. We need scheduled jobs to run reliably, even if a user's token has expired — since these jobs don’t require interactive access or live user credentials to retrieve data.

We understand that Cognos enforces token checks for security reasons (e.g., to ensure the account is still valid and hasn’t been deactivated).
However, we’re looking for a supported or practical way to run scheduled jobs in the background, without being blocked by token expiration.

We have considered creating a separate authentication provider with service accounts, but this is a workaround and introduces complexity for users.
We are hoping to find a more integrated and secure solution.

Question:


Is there any supported way in Cognos to allow scheduled jobs to run independently of token expiration, or to decouple job execution from interactive token checks — especially in an MFA environment?

Any suggestions or insights would be greatly appreciated.

Patrick Neveu's profile image
Patrick Neveu IBM Champion

Hi,

Did you try the following with an user who is running scheduled jobs:

  1. Click the Personal menu icon then click Profile and settings.
  2. On the Profile tab, under Advanced options, for Credentials, click Renew.

Best regards,

Yauhen Panimatchanka's profile image
Yauhen Panimatchanka

Hi Patrik,
Yes, we do ask users to perform these actions, and it helps temporarily resolve the issue for them.
However, there are a few challenges from a product usage perspective:

  • The refresh token expires after about a week.

  • Users are not always able to log in regularly within that time frame to refresh their credentials. For example, a user might be on vacation, but scheduled jobs under their account are still expected to run — and during that period, all their reports fail.

  • Users only find out that their refresh token has expired when they receive complaints that their reports weren't generated on time. In other words, when they create scheduled jobs, they expect that the system will run independently — but they’re forced to log in manually just to restore functionality by refreshing credentials.

Frankly, users are just frustrated with having to constantly renew their tokens — it’s inconvenient.
They expect Cognos to continue running scheduled jobs without requiring frequent logins or credential updates.

GREG MCDONALD's profile image
GREG MCDONALD

Hi Yauhen,

have you seen this?   https://www.ibm.com/docs/en/cognos-analytics/12.1.0?topic=provider-generic-oidc-type

the details:

  • For the Scheduling credentials section:

    This section is used to configure offline authentication or when interactive authentication is not possible. An example is a schedule that runs a report.

    For offline authentication to be possible, an encrypted blob is stored in Content Manager while the user is logged on interactively, for example, when the schedule is created. Then later a trusted service can use this blob to create a session to perform work on behalf of a user.

    The configured strategy controls what this encrypted blob contains:

    • ID Token: store only the id_token. Later the idtoken is used directly to establish the users identity. This is the most compatible setting but it prevents certain forms of Data Source authentication. Also the IDP is not contacted so the credentials will be valid until the user is disabled in Cognos Analytics.
    • Credentials: Cognos Analytics will prompt for a username and password. When needed, they are directly used to authenticate the user with the IDP using ROPC/password grant.
    • Credentials and ID Token: A combination of both. Password grant is used, and claims can come from either the old or new token. Use this if your IDP returns limited claims when using password grant.
    • Refresh token: The most secure setting. It is the default recommended setting if it is supported by your IDP. This setting usually requires the offline_access scope, but check with your administrator to see if additional scopes are required.

Idtoken looks to be exactly what you need so why did this not work?   What issues because it is supported.

Thanks

Greg

Yauhen Panimatchanka's profile image
Yauhen Panimatchanka

Hi Greg, as I mentioned in the question, we tested the approach using the ID token strategy, and as the tests showed — it doesn’t work for us.
Later, after also analyzing Microsoft’s documentation, we concluded that the ID token strategy is only applicable in cases where two-factor authentication is not required. In our case, two-factor authentication is mandatory.

When using the ID token strategy, we were also getting the same authorization error:

CM-REQ-4159 Content Manager returned an error in the response header. cmAuthenticateFailed CM-CAM-4005 Unable to authenticate. CAF-WRN-2082 An error has occurred. Please contact your administrator.

GREG MCDONALD's profile image
GREG MCDONALD

Hi Yauhen,

i think you really need to engage customer support so they can take the time and work through this issue with you.   

From our Documentation:
ID Token: store only the id_token. Later the idtoken is used directly to establish the users identity. This is the most compatible setting but it prevents certain forms of Data Source authentication. Also the IDP is not contacted so the credentials will be valid until the user is disabled in Cognos Analytics.
 
Not sure how MFA would apply as the above states this:
Also the IDP is not contacted
The "ID token only" scheduling credential strategy is supported and works with MFA. 
it's not working for you and I don't know why so please contact support and they will gladly help you resolve this!!
Thank you
Greg
Yauhen Panimatchanka's profile image
Yauhen Panimatchanka

Hi Greg!

Yesterday we decided to test the use of the ID token strategy once again.
To do this, we selected the appropriate strategy in the Cognos settings and restarted the instance.

Here is a screenshot of our configuration.

Unfortunately, after enabling this setting, none of the scheduled jobs that use this authentication provider start — they all fail with the previously mentioned error.
Even when I click the Renew Credentials button in the web interface, it doesn’t help, and the jobs still don’t run.

Attachment  View in library
idtoken.jpg 160 KB
Ralf Roeber's profile image
Ralf Roeber IBM Champion

Created Support case: TS019620464