Forum Discussion

usernamehere1's avatar
usernamehere1
New Member
4 months ago
Solved

Fabric Pipeline, T-SQL Notebook and Service principal

Hello, I have a problem when trying to run T-SQL Notebook from Pipeline when authenticate Notebook connection with Service principal.

 

This is the case: We use DevOps Pipeline to sync/update workspaces from Git. In that sync we use Service principal to authenticate the sync. When there is change in Pipeline item then Fabric changes that Service principal user as last modifier of the Pipeline. Notebook activity does not have a connection since it uses last modifiers account to authenticate the run. Because after Git sync from DevOps pipeline Fabric changes Service principal user as last modifier then T-SQL Notebook run will fail with this error:

Notebook execution failed at Notebook service with http status code - '200', please check the Run logs on Notebook, additional details - 'Error name - SqlDwException, Error value - DMS workload error in executing code cell: [TargetResource (https://analysis.windows.net/powerbi/api) is not allowed for service principal OBO. (NotebookWorkload) (ErrorCode=InternalError) (HTTP 500)]. DatamartId: xxxxxx. Data warehouse trace id: xxxxxx' :

 

With PySpark Notebooks there is no problem. So this is maybe T-SQL/Warehouse related problem. What I have tried and checked:

  • In Admin portal / Developer settings enabled Service principals can call Fabric public APIs for specific security group and added Service principal user into that group
  • Service principal user as Admin permission in workspace
  • I have made new connection for Notebook and authenticated as Service principal, shared that connection to Service principal user and set that connection for Notebook activity in Pipeline but same error
  • Added Service principal user in writer and reader roles in the Warehouse - same error and I think the issue is way before that phase since problem is about authenticating to Power BI REST API and Service principal has item permissions anyway from Workspace level

 

So what is the problem and how to fix it? I'm in Finland and using North Europe capacity so are we still missing support for Service principal (and Workspace identity) authentications?

  • Hi usernamehere1 ,

    Thank you for clarifying. The error indicates that T SQL notebook execution is still using an OBO based authentication flow for some internal Fabric or Power BI API calls. Because Service Principals aren't supported in OBO flows, the execution fails when a Service Principal is the last modifier. To work around this, you could convert the notebook to PySpark and run your queries with spark.sql(), which should bypass this issue.

     

    I hope this clarifies the situation. If I’ve misunderstood any part of your situation, please let us know.

5 Replies

  • Hello usernamehere1 

     

    Although Notebook activities in Fabric pipelines are intended to run under the identity defined by the Connection (Service Principal or Workspace Identity), this capability has not been fully rolled out or consistently applied across all notebook workloads.

     

    In practice:

    • T‑SQL notebooks (Warehouse / SQL DW workload) still rely on delegated On‑Behalf‑Of (OBO) authentication for certain internal control‑plane calls (for example, Power BI/Fabric platform operations against analysis.windows.net/powerbi/api).
    • When the effective identity is a Service Principal (e.g. because Git sync updates the item and sets the SPN as last modifier), these OBO calls fail because service principals are not supported for Power BI OBO flows.
    • As a result, even though a Connection is configured, the T‑SQL notebook execution path may still fall back to delegated/last‑modifier context, leading to authentication errors.
    • PySpark notebooks are not affected because they use a different execution path and do not hit the same Warehouse/OBO dependency.

    This is a known rollout gap / limitation rather than a misconfiguration.

     

    The most reliable way to address this today is to:
    Move T‑SQL logic into a stored procedure and execute it using a SQL/Warehouse activity in the pipeline, rather than running T‑SQL inside a notebook.
     

    This approach:

    • Uses explicit SQL authentication
    • Avoids the notebook OBO execution path entirely
    • Is stable and production‑safe for CI/CD scenarios

     

    • usernamehere1's avatar
      usernamehere1
      New Member

      Thank you for your answer. T-SQL notebook is very large and at this point I wouldn't move it to Stored procedures unless I really have to. If I change notebook to PySpark notebook and run querys as spark.sql would it be working work-a-round for OBO path?

  • Hi usernamehere1 ,

    Thank you for clarifying. The error indicates that T SQL notebook execution is still using an OBO based authentication flow for some internal Fabric or Power BI API calls. Because Service Principals aren't supported in OBO flows, the execution fails when a Service Principal is the last modifier. To work around this, you could convert the notebook to PySpark and run your queries with spark.sql(), which should bypass this issue.

     

    I hope this clarifies the situation. If I’ve misunderstood any part of your situation, please let us know.

  • Hi usernamehere1 ,

    Could you let us know if your issue has been resolved or if you are still experiencing difficulties? Your feedback is valuable to the community and can help others facing similar problems.

  • Hi usernamehere1 ,

    I hope everything is running smoothly for you. If you’re experiencing any problems, let us know so we can assist.

     

    Thanks.