On-Premises RBAC in Power BI Report Server

Overall Diagram

When you’re running Power BI on-premises (via Power BI Report Server) instead of the Power BI Service, you don’t get the cloud-native workspace roles and Azure AD-driven sharing model out of the box. Instead, access control leans heavily on Windows-level users/groups combined with Report Server folder and item security.

We’ll start by walking through how to control who can even see a dashboard, then move into row-level RBAC -restricting what data a user sees within a dashboard.

To keep things concrete, I’ll use a fictional retail company, NovaMart Retail, with three departments -Sales, Finance, and Warehouse Ops -each needing their own dashboard, visible only to the right people.

Controlling Dashboard Access

Step 1: Create Windows Users (Per License)

Power BI Report Server ties access to Windows accounts, so the first step happens outside Power BI entirely.

• Your Windows/IT admin creates a local or Active Directory user for each licensed person.
• Example: NovaMart has 3 Power BI Report Server licenses this month, so the admin creates:
• NOVAMART\j.tan (Sales Manager)
• NOVAMART\r.kumar (Finance Analyst)
• NOVAMART\s.lee (Warehouse Supervisor)

These accounts are what you’ll later map to roles inside Report Server — there’s no separate “Power BI account” to manage on-prem; it rides on your existing Windows/AD identity.

Example — creating a local Windows user (Command Prompt, run as Administrator):

net user j.tan "REPLACE-STRONG-PW" /add /fullname:"Jia Tan" /passwordchg:yes

• net user j.tan "REPLACE-STRONG-PW" — sets the username and initial password
• /add — creates the account
• /fullname:"Jia Tan" — sets the display name
• /passwordchg:yes — allows the user to change their own password later

Optionally, add the new user straight into a local group so it’s easier to manage Report Server security later:

net localgroup NovaMart_Sales j.tan /add

Repeat the same net user command for r.kumar and s.lee, just changing the username, password, and full name.

Step 2: Organize Reports Into Folders (Recommended)

Inside the Power BI Report Server web portal, it helps (though it’s optional) to structure content by department or purpose, rather than dropping every report in the root folder.

Example folder structure for NovaMart:

Home ├── Sales │ └── Regional Sales Performance.pbix ├── Finance │ └── Monthly P&L Dashboard.pbix └── Warehouse Ops └── Inventory & Fulfillment Dashboard.pbix

This makes security assignment much easier later, since you can secure a whole folder at once instead of every report individually.

Folder Structure

Step 3: Assign Access at the Report/Dashboard Level

For each dashboard, go to: Dashboard → Manage → Security

From here:

1. Click Add Group or User.
2. Enter the Windows account (e.g., NOVAMART\j.tan).
3. Assign the relevant role:

• Browser — can view and interact with the report, no editing.
• Content Manager — can manage, edit, move, or delete items in that location.
• Publisher — can upload/publish new reports.
• (Additional built-in roles like My Reports or custom roles can also be defined.)

Example: For NovaMart’s Regional Sales Performance dashboard, j.tan gets Browser access — she should see the numbers, not edit the report definition.

Access at Dashboard level

Step 4: Assign Access at the Folder Level

The same Manage → Security pattern applies one level up, at the folder itself: Home → Sales (folder) → Manage → Security

This controls who can even see the folder exists and browse what’s inside it — useful when you want, say, all of Sales to land on their folder without stumbling into Finance’s.

Example: The Finance folder at NovaMart gets Browser access only for r.kumar and the Finance department group, while j.tan and s.lee have no access entry at all -so the folder (and everything in it) simply doesn't appear for them.

Don’t forget the root folder. Permissions in Report Server are inherited from the top down, so the same security setup also needs to happen at Home → Manage folder → Security (the root folder itself).

Root folder Access

If a user isn’t added there, they may not be able to browse into the portal at all, even if they have access to a subfolder deeper inside. A common approach is to give everyone a baseline Browser role at the Home/root level, then lock things down further at the department folder and report level as shown above.

Restricting Data Within a Dashboard (Row-Level Security)

Folder and report-level security controls access to the dashboard itself. But often, several people need to open the same dashboard while each seeing only their own slice of the data — for example, a regional sales rep who should only see their own region, while an admin sees everything.

This is where Row-Level Security (RLS) comes in. On-prem, this is typically built with a dedicated security table, a DAX rule, and a role assigned inside Report Server.

Step 1: Create a Security Mapping Table

We create a table in SQL Server that maps each Windows user to what they’re allowed to see:

CREATE TABLE [dbo].[tbl_UserSecurity](
 [Id] [bigint] IDENTITY(1,1) NOT NULL,
 [Profile] [varchar](50) NULL,
 [Dashboard] [varchar](100) NULL,
 [RestrictionField] [varchar](50) NULL,
 [RestrictionValue] [varchar](100) NULL,
 [NetworkUser] [varchar](100) NULL
) ON [PRIMARY]
GO

This table drives the RLS logic — each row says “this Windows user, on this dashboard, is restricted to this value of this field.”

Step 2: Populate the Table

Using the NovaMart example, the Regional Sales Performance dashboard has a Region column, and we want to restrict sales reps to their own region while giving admins full visibility:

Values in the table

• RestrictionField = All / RestrictionValue = ALL → this row bypasses filtering entirely (used for admins).
• RestrictionField = Region / RestrictionValue = <specific region> → this row limits the user to only that region’s data.

Step 3: Create the Role in Power BI Desktop

In Power BI Desktop: Modeling → Manage Roles → Create Role, name it **DynamicSecurityRole**, select the fact/dimension table you want to restrict (e.g., SalesReportingUnit), and apply this DAX filter:

VAR CurrentUser = LOWER(USERNAME())
VAR CurrentUPN  = LOWER(USERPRINCIPALNAME())

// Check 1: Is the user an Admin (RestrictionValue = "ALL")?
VAR IsAdmin = 
    CALCULATE(
        COUNTROWS(tbl_UserSecurity),
        FILTER(
            ALL(tbl_UserSecurity),
            (LOWER(tbl_UserSecurity[NetworkUser]) = CurrentUser || LOWER(tbl_UserSecurity[NetworkUser]) = CurrentUPN)
                && tbl_UserSecurity[Dashboard] = "Regional Sales Performance"
                && tbl_UserSecurity[RestrictionValue] = "ALL"
        )
    ) > 0

// Check 2: Match region directly per row
VAR CurrentRegion = LOWER('SalesReportingUnit'[Region])

VAR IsAllowedRegion = 
    CALCULATE(
        COUNTROWS(tbl_UserSecurity),
        FILTER(
            ALL(tbl_UserSecurity),
            (LOWER(tbl_UserSecurity[NetworkUser]) = CurrentUser || LOWER(tbl_UserSecurity[NetworkUser]) = CurrentUPN)
                && tbl_UserSecurity[Dashboard] = "Regional Sales Performance"
                && tbl_UserSecurity[RestrictionField] = "Region"
                && LOWER(tbl_UserSecurity[RestrictionValue]) = CurrentRegion
        )
    ) > 0

RETURN
    IsAdmin || IsAllowedRegion

How this works:

• USERNAME() / USERPRINCIPALNAME() returns the identity of the logged-in Report Server user (Windows account), which is matched (case-insensitively) against the NetworkUser column.
• If a matching row has RestrictionValue = "ALL", the user sees everything (IsAdmin = TRUE).
• Otherwise, the row’s Region must match a row in the security table tied to that user — if j.tan opens the dashboard, only rows where Region = "North Region" pass the filter.
• The RETURN IsAdmin || IsAllowedRegion combines both checks — either condition being true unlocks the data.

Publish the report, and the role DynamicSecurityRole now travels with it to Report Server.

Step 4: Assign Windows Users to the Role in Report Server

Back in the Power BI Report Server portal:

Dashboard → Manage → Row-Level Security

1. Select the role — DynamicSecurityRole
2. Click Add Group or User
3. Enter the Windows account, e.g. NOVAMART\j.tan
4. Save

Row-level security in report server

Now when j.tan opens the Regional Sales Performance dashboard, the DAX rule kicks in and filters everything down to North Region only — no separate copy of the report is needed, and no folder/report-level permission changes are required. The same report serves every rep and admin, each seeing only what their row in tbl_UserSecurity allows.

Putting It All Together

The first layer answers “can this person even open the dashboard?” The second answers “of the data on that dashboard, what part is actually theirs to see?” Together, one published report can safely serve an entire organization — sales reps, department heads, and admins alike — without maintaining separate copies of the same dashboard for each audience.

A few things worth double-checking if you’re setting this up yourself:

• Test roles using View As Roles in Power BI Desktop before publishing, so you catch mismatches early.
• Make sure the NetworkUser values in the security table match exactly (case doesn't matter here since the DAX lowercases both sides, but typos won't be forgiven).
• Refresh the security table’s data source after adding new rows — RLS won’t pick up new mappings until the model refreshes.
• Don’t forget the root Home folder permission — it’s the one people usually miss first.

If you’re already running Power BI Report Server on-prem, I’d love to hear how you’re handling access control today — drop a comment below.