Are you accidentally exposing confidential data with Microsoft Power BI?

Are you accidentally exposing confidential data with Microsoft Power BI? You may if you are misusing the Publish to Web functionality.

What is Publish to Web?

Publish to Web is a function that enables you to share your Microsoft Power BI content with the world. For example, if you are a government agency and you wanted to publish the latest Zika virus statistics or you are a company that wants to show your charitable efforts, you could use Publish to Web to do this. You can see the details here.

This Microsoft Power BI function creates an embed code that you can put into most websites and have it render the reports as needed. One thing that occurs under the covers is all security validation to access the content and detailed data is stripped away. It has to in order to enable anonymous access for internet users.

So what’s the problem?

Some folks, either to avoid the need to buy a Microsoft Power BI license or in trying to embed Microsoft Power BI content in an On-Premises site like Microsoft SharePoint 2013, published their content using this function.

The risk is that if the content is on a page that gets indexed by a major search engine, like Google, the embed code will likely live in Google’s index forever. Then anyone can search for your data.

Really, I need licenses for all data consumers?

Yes, you do. Microsoft Power BI requires both content creator and consumer to be licensed in some fashion. This is true even if you embed the report in Microsoft SharePoint or Microsoft Teams. If you attempt to avoid it using some automated means, you could be creating a multiplexing licensing violation with Microsoft, which can very expensive to resolve.

There are three ways to license Microsoft Power BI. You can license individuals using Microsoft Power BI Pro. Pro is also included in Microsoft Office 365 E5 license. You can also license capacity using Microsoft Power BI Premium, which covers all consumers without having to license them individually. You can also license by usage, using Microsoft Power BI Embedded.

To justify Pro licensing expense, you have to deliver more than $120/year of value per person. Premium/Embedded may lower this bar. These are very low bars.

Using Microsoft Power BI to automate one manual effort heavy, copy/paste operation usually crosses this value bar. We did a one week effort that resulted in a 120 hour per week savings of time, eliminating the need to hire more people. The internal rate for an employee was $65/hour so this one project freed up $405,600 of time to be allocated to higher value activities. Licensing was $8400 for the year so this project returned a 14x benefit for the cost.

The alternative is to risk a data leak, as some folks are doing. The legal cost of a leak will greatly overshadow any license cost for Power BI.

I still need to embed so now what?

Please use the secure embed option if you are on-premises or are using a non-Office 365 platform. You can read more about it here. If you need to embed Microsoft Power BI content in Microsoft Office 365, use the new Power BI web part for Modern pages. You can read about it here.

Power BI Administrator Recommendations

We strongly recommend you either disallow Publish to Web or you restrict it’s use to specific report creators. Having it open to all report creators could lead to accidental use, resulting in a costly data leak.

The easiest method is to manage this with an Active Directory group that has the ability to Publish to Web. Then you can add and subtract members as needed.

You should also consider doing the following:

  • Review the Publish to Web tenant setting documentation here.
  • Review all embed codes in use within your tenant by referring to this doc.
  • Monitor the “PublishToWebReport” audit log event and setup an alert so you can review newly published embed codes for confidentiality

Let us know what you think in the comments below.

Don’t Get Burned By Your Security Templates



If you’ve ever tried to use the built-in security templates in Project Web App, you may have accidentally messed up your security model without realizing it. This problem applies to Project Server 2003-2013 versions.

Security templates are designed as a way to quickly apply or reapply permissions for predefined roles, when creating new groups and categories. However, the out of box implementation can lead to issues if you don’t realize the impact of applying them.


Groups and Categories have what is known as a many to many relationship.  A group can be associated to multiple categories and a category can be associated to multiple groups. The default security model relationships are shown below where blue boxes represent the Groups and orange boxes represent the Categories.


We’ll use Resource Manager as an example of the security template issue. Resource Manager has four relationships out of box by design:

  • My Organization so that they can see all resources and build team on any project
  • My Projects so that they can view any project of which they are part of the project team or own
  • My Resources so they can only see their resources below them in the RBS so that the Resource Manager can add them to a Resource Plan
  • My Direct Report which is reserved for you to customize functionality for the resources directly below the Resource Manager in the RBS The heavy lifting in the security model is at the intersection points between Group and Category. The intersection is where you set the what allowed Project and Resource actions (Group) can be taken on the data returned by the Category. If you’ve seen a “troubled” security model, it’s usually because this nuance was lost on whoever was maintaining the model.



Felix is a Project Server administrator who accidentally changed some category permissions in production on the Resource Manager – My Projects intersection. “No problem”, thinks Felix, “I’ll just reapply the Resource Manager security template and all will be good.”

    Felix then does the following actions.

He goes to PWA Settings under the Gear.


He clicks on Manage Groups under the Security section.


He clicks on the Resource Managers group to edit.


He scrolls down to Categories to access the Category permissions for the group for My Projects.

He selects My Projects in the Category list to show the permissions. At the bottom of the category permissions section, he selects the Resource Manager template and clicks Apply.


All good right? Not exactly.

The Issue

Remember, Resource Manager Group has four category relationships.


However, if you go into Manage Security Templates, there’s only one entry for Resource Manager.


So, which relationship does this security template represent? Was it the right one for Felix to apply? You don’t know without further research.

Suggested Fix For This Situation

If you choose to use Security Templates, I highly recommend doing the following prep work. This recommendation is based on the real world experience of managing two Fortune 250 company implementations and having cleaned up numerous security models for other companies. An hour or two of prep now will prevent tears later on.

Create a new template for group permissions and one for each intersection for the category permissions using this procedure. If you’ve heavily customized your security model, you will need to create a diagram similar to the one I have above first.

The resulting template list for Resource Manager will be as follows.

  • Resource Manager – Group Permissions Only
  • Resource Manager – My Organization
  • Resource Manager – My Projects
  • Resource Manager – My Resources
  • Resource Manager – My Direct Reports
    Now, when Felix applies a security template, he knows exactly which one he is applying to the security relationship.


You can find the default Project Server 2013 group and category permissions at these links for constructing your templates.

Project Server Security–Part 1

Security configuration is a confusing topic for many new and old to Project Server. This series provides a in-depth look at the security model and provides decision points and suggested best practices where applicable. We’ll also work through some common scenarios so that you can see how to best utilize the Project Server security model.

This first post provides an overview of the concepts upon which the rest of the series will build. The subsequent posts will dive into the various components that comprise the security system and how they fit together.

A key piece of advice is to keep things simple. Many times, I’ve had to reset a customer’s security configuration because things had become unmanageable. If you find that you are creating single group-category pairs, you may be working too hard to achieve your security goals.

Let’s Talk Terms

It’s important that you understand the terminology used with regards to security.

Project Server Security has three primary parts and supports three levels of security permissions. It also has the ability to control the data that you can see, based on your organizational position.

The three primary parts of security are:

  • Users
  • Groups
  • Categories

Users (or User Accounts) typically represent a single person who can log into Project Server. This is important as Project Server security only applies to Users, to control which functions they can perform and which project and resource data they can see.

Users are sometimes used synonymously with Resources, though this is incorrect. Resources can be assigned work in Projects but may not necessarily be able to log into the system. An example would be a generic role based resource. They are added to the plan to show the resource demand. However,  they will never log into the system. Users, like the system administrator, are typically not resources.

Groups represent roles within Project Server and the specific functional permissions needed to support those roles. These permissions are called Global Permissions, which is the second level of permission.  these permissions define what you can generally do in Project Server. We will discuss the standard roles in greater detail in a later post.

Categories represent pools of Projects and Resource data. The data returned by categories is used to populate Views, like the Project Center. They also contain the security permissions related to allowable actions on the returned data. Hence, these permissions are called Category Permissions, which is the third level of permission. Category Permissions define what you can do functionally to the data you see returned by the Category. In my opinion, these are the most important permissions as they control the ability to create and update data.

You are probably wondering what happened to the first level of permissions? These permissions are called Organizational Permissions, as they impact the entire organization. Organizational Permissions enable the implementer to turn off Project Server functionality for all users, including the administrator.

Lastly, there is a special custom field in Project Server called the Resource Breakdown Structure or RBS. This optional use field is used to capture a data visibility hierarchy. The RBS, when used, filters the visible project or resource data based on a user’s position within the hierarchy. For example, the RBS is used to denote a Resource Manager’s Direct Reports.

Key Entities and Relationships

At the most basic level, the diagram below shows the relationship between key entities. Users derive their allowed functions from the Group. The user also accesses data via Views. The View data derives from the Categories associated with the User’s member Groups.

Therefore, views should only be associated to categories which supply the desired data for the given user role.


The key to understanding the security model is in the relationships between groups and categories. The diagram below outlines the relationships of the out of box security model, where the arrows show the categories associated to each group. Category permissions, set in the relationship, determine what project and resource data appears and how it can be acted upon by a given group of users. Therefore, the category permissions (the intersections) are the most important part of the overall model. A deep dive into this area will be the topic of a future post.


What Security Does and Does Not Control

The Project Server security model controls functionality and data visibility within Project Server and Project Professional. It also automatically manages access to the Project Team Sites created in SharePoint by Project Server when a project plan is published.

Project Server security only applies to Project functionality. Therefore, there is no impact on Business Intelligence Center functionality or in direct SQL database access needed for report development. Special consideration should be taken into account for the handling of confidential projects. For example, if you have configured Project Server to prevent the 2013 Headcount Reduction plan from appearing in Project Center, rest assured, it is likely still visible via the Reporting database and Business Intelligence tools.

The Project Team Site aspect controls the level of access that a Project Team Member has to that Team Site. By default, the Project Owner who is also a member of the Project Manager Group, is the Team Site administrator. If a team member is on the Project team but is not assigned work, they are placed in the Viewer (Read only) role on the Team Site by Project Server. If the team member is assigned to a task, they are promoted to Contributor role on the site, where they can make changes to documents and lists. This permissions synchronization between Project Server and the Project Team Site occurs every time the project is published.

Subsequent posts will cover security configuration in greater detail. Future topics will include understanding the use of the RBS and how to configure Project Server to handle confidential projects.