Pipeline giving LSROBOTokenFailure after developer password reset.

[jisaac]

Before I begin, this post is not about data connections in pipeline activities, those are working fine.

This morning, the password for my Entra account was expired and I changed it. I logged out of Fabric and back in, now every one of my pipelines fails to run immediately giving the following error on initial tasks:

UUIDs and Timestamps redacted. 

BadRequest Error fetching pipeline default identity userToken, response content: {
  "code": "LSROBOTokenFailure",
  "message": "AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '0000-00-00T00:00:00.0000000Z' and the TokensValidFrom date (before which tokens are not valid) for this user is '0000-00-00T00:00:00.0000000Z'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: 0000-00-00 00:00:00Z",
  "target": "PipelineDefaultIdentity-00000000-0000-0000-0000-000000000000",
  "details": null,
  "error": null
}. FetchUserTokenForPipelineAsync

This is similar to these two posts:

Solved: Fabric Data Pipeline fails with "LSROBOTokenFailur... - Microsoft Fabric Community

Sudden pipeline authorization issues - using crede... - Microsoft Fabric Community 

This bug will presumably happen whenever a person who last edited a pipeline has their password reset.

I can fix them by manually making a minor change, saving, reverting the change, and saving again, but this is not a solution. I have too many pipelines to be able to do this every time a developer's password is reset.

I believe this is a bug and pipelines should not be self-destructing when their creator's account is deactivated. Can anyone confirm this?

I need a solution to refresh all authentication tokens on pipelines (wherever those are accessed?) in my workspaces. I cannot afford to make minor edits to all of my pipelines.

[v-nuoc-msft]

Hi @jisaac 

The issue you're experiencing with Microsoft Fabric pipelines failing due to the "LSROBOTokenFailure" error after a password reset is a known problem. It occurs because the authentication tokens associated with the pipelines become invalid when the password of the account that last edited the pipeline is changed or reset. Here are some insights and potential solutions:

The error message indicates that the authentication grant (token) has expired or been revoked due to the password reset. This is tied to the pipeline's default identity, which relies on the credentials of the user who last modified the pipeline.

As you've mentioned, making a minor change to the pipeline, saving it, and then reverting the change refreshes the token. However, this is not practical for a large number of pipelines.

Unfortunately, there isn't a built-in feature in Microsoft Fabric to refresh tokens for all pipelines in bulk. However, you can automate this process using the Microsoft Fabric API or PowerShell scripts to programmatically update and save pipelines. This would simulate the manual "tickling" process for all pipelines.

To avoid this issue in the future, consider using a service principal for pipeline authentication instead of a user account. Service principals are not tied to individual user credentials and are unaffected by password resets.

Regards,

Nono Chen

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[jisaac]

Hi @v-nuoc-msft,

Thanks for letting me know. It's good to hear that it's a known issue. Do you know if it will be addressed and fixed in the future?

For Service Principal accounts, I understand using a Service Principal for data connections, but is there documentation you can send me on how to use a Server Principal to own Fabric pipelines and other items? For instance, if a developer needs to change a pipeline and they do it from their account, they become the owner, correct? How can I make it so the Service Principal is always the owner even if a developer makes a change, or am I looking at it the wrong way?

Thanks,

Jacob Isaac