microsoft
Discrepancy between resources returned by Get-M365DSCAllResources and documented resources
When running the Get-M365DSCAllResources cmdlet, I noticed it returns several resources that don't appear to be documented in the official Microsoft365DSC documentation here (https://export.microsoft365dsc.com/).
Some examples of resources returned by the cmdlet include:
AzureBillingAccountPolicy AzureBillingAccountsAssociatedTenant AzureBillingAccountScheduledAction AzureBillingAccountsRoleAssignment AzureDiagnosticSettings AzureDiagnosticSettingsCustomSecurityAttribute AzureSubscription AzureVerifiedIdFaceCheck CommerceSelfServicePurchase DefenderDeviceAuthenticatedScanDefinition DefenderSubscriptionPlan FabricAdminTenantSettings M365DSCRuleEvaluation
I am trying to map all workloads for the M365 tenant for my organisation but when it comes to determining the permissions that are required to authenticate using an app with certificate thumbprint, I'm not sure whether I should be including the resources listed above or not?
Is there a recommended way to determine which resources are fully supported vs. experimental?
Here's the AAD ones that aren't on the export.microsoft365dsc.com page (98% confidence)
AADAccessReviewDefinition AADAccessReviewPolicy AADAdminConsentRequestPolicy AADAuthenticationMethodPolicyExternal AADAuthenticationMethodPolicyHardware AADAuthenticationMethodPolicyQRCodeImage AADAuthenticationRequirement AADClaimsMappingPolicy AADConnectorGroupApplicationProxy AADCustomAuthenticationExtension AADCustomSecurityAttributeDefinition AADDeviceRegistrationPolicy AADDomain AADEnrichedAuditLogs AADEntitlementManagementSettings AADFeatureRolloutPolicy AADFederationConfiguration AADFilteringPolicy AADFilteringPolicyRule AADFilteringProfile AADGroupEligibilitySchedule AADHomeRealmDiscoveryPolicy AADIdentityAPIConnector AADIdentityB2XUserFlow AADIdentityGovernanceLifecycleWorkflow AADIdentityGovernanceLifecycleWorkflowCustomTaskExtension AADIdentityGovernanceProgram AADIdentityProtectionPolicySettings AADLifecycleWorkflowSettings AADNetworkAccessForwardingPolicy AADNetworkAccessForwardingProfile AADNetworkAccessSettingConditionalAccess AADNetworkAccessSettingCrossTenantAccess AADOnPremisesPublishingProfilesSettings AADOrganizationCertificateBasedAuthConfiguration AADPasswordRuleSettings AADRemoteNetwork AADRoleAssignmentScheduleRequest AADRoleManagementPolicyRule AADUserFlowAttribute AADVerifiedIdAuthority AADVerifiedIdAuthorityContract
The list on export.microsoft365dsc.com wasn't updated for a longer period of time. The reasons are unknown to me.
Thanks for coming back on this point - that's helpful to understand. I wrote a script using the Get-M365DSCAllResources cmdlet to work out which resources don't follow the standard workload prefixes. I've got the following resources where I'm not sure where they should belong:
CommerceSelfServicePurchase DefenderDeviceAuthenticatedScanDefinition SHSpaceUser DefenderSubscriptionPlan SentinelThreatIntelligenceIndicator SentinelWatchlist SHSpaceGroup SentinelSetting FabricAdminTenantSettings M365DSCRuleEvaluation SentinelAlertRule
Couple more questions please:
-
Is there a definitive list of which services/workloads each DSC resource maps to, particularly for those that don't follow standard naming conventions?
-
Do these resources have "friendly names" or documentation that explains what they represent? For example, what exactly does "SHSpaceGroup" relate to in the Microsoft 365 admin interface?
-
Authentication Requirements: What permissions/app registrations are needed to authenticate to these "Other" category resources? Do they map to existing workloads for authentication purposes?
I'm trying to ensure our DSC implementation is comprehensive while properly organizing resources by workload for permission management. Thank you for any clarification you can provide!
@RosalindHook The resources you mention all have a dedicated workload, although they are not visible on the export site. However, the resources site of microsoft365dsc.com contains all of them, see here: https://microsoft365dsc.com/resources/overview/
Is there a definitive list of which services/workloads each DSC resource maps to, particularly for those that don't follow standard naming conventions?
- I think the resources website mentioned earlier is the primary go-to site for the overview. They are separated by workload, with each and every resource belonging to the workload listed there.
Do these resources have "friendly names" or documentation that explains what they represent? For example, what exactly does "SHSpaceGroup" relate to in the Microsoft 365 admin interface?
- The information is present on the specific resource site as well. Example for the SHSpaceGroup: https://microsoft365dsc.com/resources/services-hub/SHSpaceGroup/ -->
Represents a Services Hub space group.
Authentication Requirements: What permissions/app registrations are needed to authenticate to these "Other" category resources? Do they map to existing workloads for authentication purposes?
- As much as I would like to say that it's all documented on the specific resource site as well, that's not always the case. @NikCharlebois has a couple of blog posts about how to authenticate against a couple of those other workloads. For the Fabrics API, see here: https://nik-charlebois.com/blog/posts/2024/authenticating-to-fabric/index.html
Hope that helps! I'm also trying to figure out how some of those resources work, despite the fact that I'm one of the main contributors here. Sometimes it's a mystery, even for us.
Thanks so much, the above has been really helpful in getting our entra apps all set up and configured, and it feels like we now have a far more comprehensive mapping of all the workloads and resources within the M365 tenant - so many thanks for taking the time to come back.
@FabienTschanz I do have a few more questions about permissions which would be helpful to understand the answers to. As I explained above, I'm implementing M365 DSC in our environment and having mapped the full set of resources by workload and set up Entra apps relating to each workload, I now have some further questions about the permission model when using the Update-M365DSCAllowedGraphScopes cmdlet to determine required permissions.
1. Permission Hierarchy and Minimization
When filtering for 'Read' permissions only, I notice many granular permissions are still required. For example, with Teams resources:
Organization.Read.All
User.Read.All
Group.ReadWrite.All
AppCatalog.ReadWrite.All
TeamSettings.ReadWrite.All
Channel.Delete.All
ChannelSettings.ReadWrite.All
ChannelMember.ReadWrite.All
ChannelSettings.Read.All
Group.Read.All
Question: Shouldn't higher-level permissions like Organization.Read.All cover many of these lower-level scopes? Is there a way to optimise this list to request fewer, broader permissions rather than many granular ones? I'm asking because we need to agree our approach with security teams, and therefore are trying to work on the principal of minimum permissions as much as possible.
2. ReadWrite and FullControl Permissions for Read Operations
When filtering by parameter 'Type' to only return 'Read' permissions, I still see many 'ReadWrite' and even 'FullControl' permissions in the results:
Group.ReadWrite.All
AppCatalog.ReadWrite.All
TeamSettings.ReadWrite.All
Channel.Delete.All
ChannelSettings.ReadWrite.All
ChannelMember.ReadWrite.All
And for SharePoint:
Sites.FullControl.All
Question: Why are write/control permissions required even when only performing read operations? This creates challenges with our security team who prefer to grant minimum necessary permissions. Is there a way to truly limit to read-only operations?
3. Additional Role Requirements Beyond API Permissions
The documentation for Teams states:
"When using Service Principals to authenticate against Teams, you have to make sure the correct permissions are configured. Besides the permissions specified in the resource documentation, the service principal also needs to get added to the Teams Administrator role in Entra ID."
I'm also aware of Nik Charlebois' blog article that you flagged above about Fabric authentication, which mentions:
"In order to be allowed to authenticate to the Fabric API, your service principal will need to be granted an appropriate Entra ID role. We recommend granting it the Fabric Administrator role, but it will also work with the Global Reader role."
Question: Is this pattern of requiring both API permissions AND directory roles consistent across all workloads? I'm experiencing authorization issues with Azure and Power Platform despite adding all the permissions returned by the cmdlet. Is there documentation that comprehensively lists all required directory roles beyond API permissions for each workload?
I appreciate that you may not have all the answers to these questions immediately, but any insights you can provide would be extremely valuable for our implementation. Understanding even partial answers would help us move forward with our security planning.
Thanks again for your support, Rosalind
@RosalindHook I'll give my best to answer your questions:
Question: Shouldn't higher-level permissions like Organization.Read.All cover many of these lower-level scopes? Is there a way to optimise this list to request fewer, broader permissions rather than many granular ones? I'm asking because we need to agree our approach with security teams, and therefore are trying to work on the principal of minimum permissions as much as possible.
This is unfortunately something that we can't do. If we were to do such a lookup, it would require us to check the permission scope of each permission in Entra and this will very likely take a long amount of time to check. For some permissions, there isn't even a description available or a scope which tells us, what permissions would be included in there. Roles usually contain the associated permissions, but API-permissions normally don't list what other permissions they contain.
Question: Why are write/control permissions required even when only performing read operations? This creates challenges with our security team who prefer to grant minimum necessary permissions. Is there a way to truly limit to read-only operations?
Sometimes it's necessary for a resource to contain permissions with a higher impact behavior, such as ReadWrite or FullControl. Some APIs that we're using simply don't support a Read version of the permission and require the full permission. I'd have to check which resources are affected, but there are a couple. Unless Microsoft fully implements the more granular version of permission scopes, we'll be on a lost ship here.
Question: Is this pattern of requiring both API permissions AND directory roles consistent across all workloads? I'm experiencing authorization issues with Azure and Power Platform despite adding all the permissions returned by the cmdlet. Is there documentation that comprehensively lists all required directory roles beyond API permissions for each workload?
Yes and no - The consistency varies by workload. E.g. ExchangeOnline as well as Teams are two of those workloads that both require dedicated API permissions on the EXO / Teams backend as well as a directory role in Entra. Why? Absolutely no idea, most likely because of how authentication was done previously where many permissions were only configured in Entra and later changed to also support app registrations. The most up-to-date authentication list you can retrieve using Get-M365DSCCompiledPermissionList. If there is a resource that doesn't work, you can open an issue on the repository here and ask for clarification. If we know it, we'll update it accordingly. But I have to be honest here too - I too didn't manage to get all workloads going (cough cough Fabric cough cough). Didn't try Azure yet, maybe will do in the future.
I hope this helps in your planning. If there are any further questions, feel free to put them here as well. I'll try and give you the best answer I can.
Thank you @FabienTschanz that is really helpful and helps our security conversations about why the permissions are configured in the way that they are.
I've got the majority of workloads going that we need and definitely want to export (AAD, Exchange, Intune, O365, SHarepoint Online, Teams), though are still working out precise use case and whether the ones we are missing are problematic or not. I'm missing Defender, Azure, Power Platform and Fabric (I am fairly sure I know why the latter doesn't work based on the blog article you pointed to, because I can't create a security group or set admin API settings as this is disabled in my org).
May come back with more precise questions relating to particular workloads or check if others have issues - but for now that's really helpful and gives a clear baseline in terms of explaining why the permissions are what they are.
Starting with the next release of Microsoft365DSC, the export website will stay up to date with our latest resources.