Dan Malagari on Fri, 25 Aug 2017 18:36:35
I'm having an issue with Office 365 Groups assigned to a Tabular Model role. I feel like I've been through the paces troubleshooting this, but I figured I'd raise it to the community to see if there's something wrong in my execution or if there's something wrong in the Azure Analysis Services offering.
A few months ago, the only way to assign an group to a role was following this guide: https://blogs.msdn.microsoft.com/sqlblog/2017/01/24/azure-analysis-services-howto-add-security-group/. This involved creating an Azure AD Group with Office Features enabled, and then grabbing the GUID@domain.com email address to apply to the role in SSMS.
Fast forward a few months, and the SSDT/SSMS tooling now supports searching an Azure AD for users and groups to add to a role. However, when adding an Office 365 Group to one of the tabular model roles, the users associated with that group aren't able to see the model. I've verified this in SQL Server Profiler 17 - the users are getting kicked out saying they don't have permission, even though they are clearly part of the group and the group is assigned to the role.
After a bit of troubleshooting, I've come to the following conclusions:
- Groups created in the Office 365 Portal that are assigned to a tabular model role do not work.
- Groups created in Exchange Online PowerShell also do not work.
- Groups created in the Azure AD pane in the Azure Portal, with Office Features turned on (similar to the article above), do work.
Unfortunately, Office 365 Groups cannot be created in the AzureAD PowerShell cmdlets - it explicitly errors out saying that mail-enabled groups cannot be created at this time. The only other option I haven't tried is the Microsoft Graph API, which was an intentional effort to not deal with API permissions.
Has anyone run into this issue, or can anyone try and recreate my issue?
Dan Malagari on Fri, 25 Aug 2017 19:46:46
Alright, I may have found a solution to my problem.. but it is something that should be documented.
I pulled in the groups that I had created in the Office 365 Portal and Azure AD Portal using the Get-UnifiedGroup command in PowerShell and compared all of the properties. The only difference, aside from some GUIDs and naming, was the 'AccessType' property. It turns out, making a group in Azure AD with Office Features enabled automatically creates an Office 365 Group as Public, whereas making an Office 365 Group in the Office portal allows you to choose public/private.
If the group is set to Private, it cannot be used for authentication against an SSAS Tabular Role. As soon as I switched my Office 365 Portal created groups to Public, the users were authenticating as expected.