Forum Discussion
Setting of Membership in Semantic Models using notebook
- 1 year ago
To pass an Azure AD security group correctly as a role member in your semantic model, you typically need to provide more structured information than just the group’s ObjectID. Many SDKs, including the one you're using (sem-py-labs), are designed to accept simple string inputs like user email addresses, which work fine for individual users but fail for security groups because the system cannot determine the principal type. To add a group, the expected format is often a structured object that explicitly defines both the member’s identity and type. For example, some APIs and tools require the group to be identified using a prefix like aad://<group-object-id> and specify the memberType as "Group". This helps the service recognize that the ObjectID belongs to a group and not a user. However, if your current SDK doesn’t support structured inputs, you may need to switch to a tool that supports the Tabular Object Model (TOM) or XMLA scripting, such as Tabular Editor, PowerShell, or direct XMLA requests. These methods allow more control and let you add role members with detailed metadata, ensuring that Azure AD groups are properly recognized and accepted.
Poojara_D12 thank you for your reply.
Please could you be a little more specific on how I pass the group information as a structured object as currently not seeing anything in the documentation to demonstrate this.
To pass an Azure AD security group correctly as a role member in your semantic model, you typically need to provide more structured information than just the group’s ObjectID. Many SDKs, including the one you're using (sem-py-labs), are designed to accept simple string inputs like user email addresses, which work fine for individual users but fail for security groups because the system cannot determine the principal type. To add a group, the expected format is often a structured object that explicitly defines both the member’s identity and type. For example, some APIs and tools require the group to be identified using a prefix like aad://<group-object-id> and specify the memberType as "Group". This helps the service recognize that the ObjectID belongs to a group and not a user. However, if your current SDK doesn’t support structured inputs, you may need to switch to a tool that supports the Tabular Object Model (TOM) or XMLA scripting, such as Tabular Editor, PowerShell, or direct XMLA requests. These methods allow more control and let you add role members with detailed metadata, ensuring that Azure AD groups are properly recognized and accepted.
- BalfourBen1 year ago
Advocate I
Poojara_D12 Thanks for that.
After some searching I have found that they are adding the ability to add security groups and define the princiapal type in the next release.
Thank you for your help!