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.

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.