Configure Azure and Fabric

Fabric Desktop by KratosBI needs no app registration: it signs people in as themselves through Microsoft's own Fabric sign-in, the same one Fabric CLI uses. What's left to set up is a few Fabric settings, and workspaces with capacity. This page walks through it in order. It is written for whoever administers Fabric in your organization. Most of it is done once.

Everything about sign-in and permissions, including how to use your own app registration if your organization requires one, is in permissions.md.

1. Check your Fabric tenant settings#

In the Fabric admin portal (app.fabric.microsoft.com > gear > Admin portal > Tenant settings), check these. Most tenants already have them on.

Settings can be on for the whole organization or for named security groups. If you limit them to groups, make sure Fabric Desktop by KratosBI's users are in them.

2. Check sign-in policies#

There is no app to register and no consent to grant. People sign in with their work account; on Windows that usually happens through Windows itself, with no prompt.

Two Conditional Access policies can still get in the way:

• "Require a compliant or managed device": works on PCs your organization manages, because Windows sign-in proves the device. Unmanaged PCs are refused, as they are for Fabric in the browser.
• Policies that block Microsoft's developer tools (Azure CLI, Fabric CLI) for some users: Fabric Desktop by KratosBI signs in through the Fabric CLI app, so those users are refused too. Exclude the Fabric CLI app for Fabric Desktop by KratosBI's users, or use step 3.

permissions.md has the details and which features each Microsoft API covers.

3. Only if required: your own app registration#

Skip this unless your organization requires every app to use a registration in your own tenant, or wants to pick the exact permissions. Then follow permissions.md: Using your own app registration: register a public client with the redirect URI http://localhost, add the delegated permissions in its table, and give its ID to everyone with step 4. None of those permissions needs admin consent, unless your tenant stops users consenting to apps.

4. Push settings to everyone#

Nothing here is required. A policy file at %ProgramData%\FabricDesktop\policy.json, pushed with Intune or Group Policy, can fix the update channel or turn self-updates off, hide Preview features, keep work off Fabric capacity, limit sign-in to your own tenant, point Report a problem at your own support channel, and name your own app registration (step 3). People see "Set by your organization" and can't change those settings.

A policy file that sets everything an organization usually wants:

{
  "channel": "stable",
  "show_preview": false,
  "support_url": "https://teams.microsoft.com/l/channel/..."
}

A key that is misspelled is ignored. An invalid file or key fails closed for anything the file can restrict, so a mistake never opens up what you meant to lock down:

• The file is there but can't be read (a stray comma, not one JSON object, no permission to open it): each PC keeps using the last copy of the file it could read, as Group Policy keeps its last applied settings, until you fix it. Each PC saves that copy whenever it reads a valid file, and deletes it when the file is removed. The copy is %LOCALAPPDATA%\FabricDesktop\policy-last-good.json. It sits in the person's own profile, so someone could edit it, but it only counts while the real file is broken, and Settings > Help and about says when it is in use.
• The file can't be read and the PC has never read a valid one (a new PC whose first file is broken): none of it applies, and every restriction takes its most restrictive value until you fix it. People can still sign in and work on their PC, but there are no runs in Fabric, Preview features and telemetry are off, external AI tools are off with no permissions, no HTTP API and no extensions, and receipt exports leave out every part. Other settings (client_id, channel, support_url, platform, the SQL and notebook limits, local_retention_days) go back to what they'd be with no file.
• A restriction has the wrong kind of value ("false" in quotes instead of false): that key takes its most restrictive value. allow_fabric_runs, show_preview, telemetry, integrations and integrations_http become false; allowed_tenants lets no account sign in; integrations_max_permissions and integrations_extensions allow none; receipt_redactions leaves out every part.
• Any other key has the wrong kind of value: it's ignored, and the person's own choice or the default applies.

With no policy file at all, nothing is restricted. Settings > Help and about lists every problem in the file and what Fabric Desktop by KratosBI did about it. Check there after you push a new file.

auto_update and channel are also read by the app's updater, which still treats an unreadable file or a wrongly typed auto_update as no setting, so the app keeps updating itself on the channel chosen in Settings (Stable unless someone picked Preview).

Every key is optional. More detail is in permissions.md: Rolling out to your organization.

With about 5,000 people, consider "show_preview": false for most of them and a pilot group with Preview features on. Preview features haven't been tried on a live tenant (what is tested).

5. Plan workspaces and capacity#

Notebooks and SQL queries can use any lakehouse a person can open. The metadata framework expects a particular shape, so plan it before a team starts.

Things to know:

• Dev can stay on the PC. A new project's Dev keeps its tables in a .local folder on the developer's PC. It needs no workspace until someone assigns one in Data mesh > Environments and promote.
• Test and Prod lakehouses are created by the app on the first promote. You don't create them by hand.
• Capacity. Lakehouses need a workspace on a Fabric capacity (F SKU, or a trial). Runs on a PC start no Fabric job, though their OneLake reads and writes still use some of it. Features that deliberately run in Fabric do: Run in Fabric, Fabric schedules, environments set to Runs on: Fabric, Optimize (Fabric's table maintenance job), and semantic models. Optimize > Cost and savings estimates how much.
• Workspaces can be created from the app (Data mesh > Environments and promote > Assign workspace > Create a new workspace) if people are allowed to create workspaces.

6. Give people access#

Fabric Desktop by KratosBI never gets more access than the person using it. It uses their own Fabric workspace roles.

Using security groups for these roles makes working across teams much easier than adding people one by one.

7. Optional extras#

8. Check it works#

Have one person do this on a PC with the app installed:

1. Start Fabric Desktop by KratosBI and Sign in. Expected: Home says "Welcome back".

2. Open Workspaces. Expected: the workspaces they can open in Fabric. If it's empty, they have no workspace roles yet.

3. Open OneLake, expand a lakehouse, and choose SQL query. Run SELECT * FROM <a table> LIMIT 10. Expected: rows. This proves OneLake access from outside Fabric works.

4. Create > Notebook, Add data items, attach a lakehouse they can write to, and run:

   import polars as pl
   from fabric_desktop import lakehouse
   lakehouse.write_table(pl.DataFrame({"ok": [1]}), "dbo.fabric_desktop_check")
   

   Expected: the table shows in Fabric (refresh the lakehouse there if it shows under Unidentified). Delete it afterwards.

5. If anything fails, the bell (Activity) has the error with its details. Troubleshooting lists the common ones.