The idea to implement AD groups was first realized when trying to dynamically populate O365 group membership, that can be done with PowerShell. The benefit of that knowledge lead me to thinking how I could reverse the process and extract the list of members in an AD group. A short internal discussion lead me to discover the importance of mail enabled security groups to leverage certain properties for authentication.
The Problem
Due to the nature of self-service, many organizations struggle with maintaining the current list of O365 groups or individual users that have access to data sources through the on-premises gateway. The problem being every time a new O365 group is created it would have to be added to the gateway users list for a data source. However, these struggles can be mitigated by implementing the same AD groups used for authentication on your data warehouse or analysis services cube in the on-premises gateway.
The Solution
According to the Microsoft Feature summary AD groups have been enabled since November of 2015, but there remains confusion on how to properly implement AD groups. This will be your guide to implementing AD groups in the Power BI on-premises data gateway.
1. Establishing Reporting Groups
To fully leverage the AD groups and minimize maintenance, you should grant permissions to each data source (SSAS Tabular Cubes) with a single reporting group with reader permissions for the model. This single reporting group will be specific to the business domain the tabular model was implanted to serve. Then populate that business domain’s reporting group with the current AD groups used for role based authentication. That way when associates are creating new O365 groups for organizing collaboration their authentication in the Power BI service is seamless without requiring IT involvement and reports can be authored as quickly as groups are created.
*Server admins will also need to be assigned into a business domain group as well.
2. Assigning Mail Enabled Security Groups
The solution to utilizing AD groups on the enterprise gateway can be found by leveraging the mail enabled property of the security group. Per Microsoft, “A mail-enabled security group can be used to distribute messages as well as to grant access permissions to resources in Active Directory.” The process to enable email is straight forward and only requires an email be assigned to the group.
Using mail-enabled AD groups, allows the enterprise gateway to access the Members property in the Azure Active Directory group for the user. Notice how I said Azure Active Directory, that will be covered in the next step. That way the user will always authenticate as a member of the allowed Azure Active Directory group listed, no matter which O365 group they are using. This needs to be done for all security groups and recursively for each AD group that is a member of the current group for permissions to pass through.
3. Sync to Azure Active Directory to Reflect On-Premises AD
The final step to get the on premises AD group into the Power BI on-premises data gateway is to sync the local AD in to Azure Active Directory. A prerequisite to this process will be to install the latest version of DirSync known as Azure AD Connect. In the tool you must choose which organizational units are going to by synced to Azure AD. The organizational unit where the security group resides is chosen to sync.
*Sub Groups must exist in the same organizational unit as the reporting security groups or the sync won’t contain those members.
You can confirm in Azure AD that the group sync has taken place and that the type is a “Mail-enabled security group”
Assigning Users to the Power BI On-Premises Data Gateway
Once the sync is complete, you will now be able to assign the single business domain reporting role to the on-premises data source as you would with any O365 group or individual user.
