Request for Get-AzAdContact or similar

[TerryED0618]

Active Directory module

Get-ADObject -Filter "ObjectCategory -Eq 'Person' -And ObjectClass -Eq 'Contact'"
Get-ADGroup
Get-ADUser

AzureAD module

Get-AzureADContact
Get-AzureADGroup
Get-AzureADUser

AZ.Resources module

?
Get-AzADGroup
Get-AzADUser

[TerryED0618]

Get-AzADUser -IncludeContacts, and add ExternalEmailAddress or targetAddress to IMicrosoftGraphUser ?

[dcaro]

The purpose of the AzAD cmdlets in Azure PowerShell is to enable successful ARM scenarios. For example, creating a service principal to be used when creating an AKS cluster. For other cases, we prefer to rely on the Microsoft Graph module for PowerShell.

@TerryED0618 can you please share more insights about the scenario or case where this implementation would be needed so we can evaluate the feature request?

[TerryED0618]

Basically it’s the issue of Role-Based Access Control (RBAC) versus consent.

The primary user of PowerShell are M365/on-premises admins. Many which have little or no inclination for involved scripting, and yet eventually will need to use it. Traditionally the admins and their service accounts are granted rights via RBAC. Admins know this. Organization’s IT security teams are familiar with this.

Then comes MgGraph and all M365 admin tools are either to be MgGraph-based or MgGraph-backed. This is good. MgGraph scopes help to address the least-privilege principle (mostly). Auto-refresh, auto-throttling, auto-paging, Modern-Auth – it’s a great tool base. Yet there is a cost of a new technology that I don’t see all organizations embracing.

With the RBAC model, as an admin I can request required permissions. Upon review and approval my admin account or service account are added to a Directory Role or custom RBAC group. Done. My admin and service account can be used for one-liners, small ad-hoc scripts, and scheduled tasks running fully fleshed out PowerShell scripts.

With the consent model, as an admin I can request required permissions. Upon review and approval my admin account or service account are added to a Directory Role or custom RBAC group. Upon first use I will face a consent form. If the organization is consent savvy, they may have someone approve the consent on my behalf (via Azure AD portal or shared RDP session for example) or allow me to self-approve my consent. I have not seen the latter done, as I would need Cloud Application Administrator, Application Administrator, or a custom directory role. Most often I see organizations ignore and block user/admin consent. Which means no MgGraph use with that organization. Full-stop.

It’s a two step process: provision an account AND consent it for the same permissions already approved. Once done, the elevated service principal consent approvals stick, which is kind of good and kind of bad. Good for auto-refresh, bad since yesterday’s consent approval may be more privilege than I need today, and yet I have it.

The Graph REST API are fine, yet no M365 admin I know is ready to embrace URI writing just to get a one-line of PowerShell to run. No matter how secure or clever, it’s just not admin friendly.

As a M365 admin toolsmith, I’ve been following Microsoft’s lead on dropping the deprecated Basic-Auth uses and move forward with the Modern-Auth MgGraph-based or MgGraph-backed modules. I look forward for the ExchangeOnline 2.0.6 module general availability release with excitement (a non-consenting admin tool). RSAT’s ActiveDirectory module doesn’t need Modern-Auth. AzureAD/MicrosoftOnline are the core tools to work with the core of M365 - Azure AD itself. Please don’t leave us with two thirds of support or forced to us to use potentially prohibited MgGraph directly.

Please consider Az.Resources’ AzureAD module components not just Azure Resource Manager (or is that Advanced RISC Machine?) but a as a full fledge AzureAD/MicrosoftOnline module replacement.

The same should be considered for Teams, SharePoint/OneDrive, and Security and Compliance center connecting modules, et al.

[dcaro]

@TerryED0618 sorry that it took so long to come back to you.
Because of the possibilities of the Microsoft Graph PowerShell module, not requiring consent would be dangerous, think of it as an additional level of protection. One of the reasons why Azure PowerShell module do not require such a consent is because it does not access user's data.

Contacts are part of the user's data so, adding support for this type of resources would require us to think about the consent as well and today, we do not have plans to cross this line. We are working with the Identity team to clarify the boundaries between AzureAD / MS Graph and Az PowerShell modules, the document should be published at some point in the next couple of months.

I will discuss the issue regarding consent with the MS Graph team and be in touch with the M365 admin team to identify the scenarios where it makes sense to have more support from the Az PowerShell module.

Here are couple of publications about the AzureAD to MS Graph migration:

• https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/azure-ad-change-management-simplified/ba-p/2967456
• https://docs.microsoft.com/powershell/azure/active-directory/migration-faq?view=azureadps-2.0

[dingmeng-xue]

I'm closing this discussion. We will visit requirement of supporting MSGraph API in future according to priority.