The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.
I'll start by saying we have strict standards for how we manage connections; and unless it is unavoidable - we only use connections that use a service principal or managed identity.
Yesterday, every pipeline that I created in our workspace started failing after my Entra ID had a 'force logout' issued (due to another Azure problem). Not a single connection within any pipeline uses my credentials; yet none of them would work. They all got this message on step zero just trying to run at all:
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 '2024-11-24T16:54:46.2621875Z' and the TokensValidFrom date (before which tokens are not valid) for this user is '2024-12-11T14:47:33.0000000Z'. Trace ID: b615c280-4d7b-4a8b-8d01-a87ef6b52d00 Correlation ID: ebec8b83-985c-4933-908e-2010f1635d85 Timestamp: 2024-12-12 14:59:03Z",
"target": "PipelineDefaultIdentity-28091b52-991e-4f96-b93c-046d6a3d51fb",
"details": null,
"error": null
}. FetchUserTokenForPipelineAsync
I found this ticket and "solution", but I feel it is absurd to suggest to people that they need to go into, edit, and save potentially 100s of pipelines - all because pipelines use an authorization mechanism that we have zero insight into. This (being able to at least see the auth/security context under which pipelines run) feels like a critical core piece of functionality. How does one access or change the context under which pipelines run? Where does this magic happen?
@HoneHealthMB did you ever get this figured out? I'm in the exact same situation and agree with you. Renaming something, saving, renaming it back, and saving again is not practical on my 50+ pipelines. I need a solution I can run to fix the whole workspace whenever I need to reset my password.
Also, for the future, is there a way to have a service account own the pipelines? Even still, what happens when the service account's authentication is reset or broken?
Any help would be appreciated.
Hi @HoneHealthMB ,
As you can see from your reported error message, the problem you are experiencing is an expired authentication token.
The error message indicates that the token has been revoked, probably because of a password change or reset.
So I think you can take the following steps:
1. log in again to refresh the authentication token.
2. Make sure you have not changed or reset your password recently. If you have, log in with the new password.
3. if you are using an application or service, make sure it requests a new token after the old one expires.
Best Regards
Yilong Zhou
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
That reply makes no sense.
Let's start with a simple question.
For a given pipeline, what "token" is it referring to? I have connections to 3 different warehouses/databases in that pipeline. None of them use anything about a token. They all use service principals.
I am saying that it is absurd that a pipeline has to run as its "owner", and there is no ability to change the owner. What are you supposed to do when an employee leaves?
To add our woes to your woes... we recently had a load of pipelines fail on April 1st. Sadly not an April Fools either! Errors relating to Conditional Access failures, no clues in the logs, no useful articles to help us. Checked all authentication for connectors related to pipelines, all checked-out fine. In the end, we went into each pipeline, made an inoccuous change (like renaming an action), and re-saved. After the save, everything was fine. Had to do this 10s of times. Utter nonsense.
The more I use Fabric, the more I feel that it is not fit for Enterprise.
If you are wondering - we've just had an employee leaving and all his work stopped working.
Apparently you what you need to do - give access to connections you are using, that is expected. Then you have to give data pipeline, dataflows, etc. authority for some reason, because it will not work and also if it had schedule - you need to take ownership of the schedule also. Our best solution, since our number of items is around 10, is to change something in the pipeline - save it, then change the schedule and save it also. Then it is likely that it won't fail, but you never know.