➖ ➕ Remove PSNotification, replace AzureAd with Microsoft.Graph REST API

[FH-Inway]

Since we replaced the Azure.Storage with the Az.Storage dependency (see #361 ), I took a look at the other PowerShell module dependencies:

d365fo.tools/d365fo.tools/d365fo.tools.psd1

Lines 30 to 37 in f5f9069

	RequiredModules = @(
	@{ ModuleName = 'PSFramework'; ModuleVersion = '1.0.12' }
	, @{ ModuleName = 'Az.Storage'; ModuleVersion = '1.11.0' }
	, @{ ModuleName = 'AzureAd'; ModuleVersion = '2.0.1.16' }
	, @{ ModuleName = 'PSNotification'; ModuleVersion = '0.5.3' }
	, @{ ModuleName = 'PSOAuthHelper'; ModuleVersion = '0.3.0' }
	, @{ ModuleName = 'ImportExcel'; ModuleVersion = '7.1.0' }
	)

• PSNotification is (no longer?) used by the module and can be removed
• AzureAd is deprecated and could potentially be replaced with Microsoft.Graph modules

This issue is mainly about the AzureAd replacement. For now, I think there is no urgency behind the replacement, but eventually, it should be done. The issue was created to kick things off and act as a central point to coordinate efforts.

Deprecation

Azure AD PowerShell is planned for deprecation. The Migration FAQ sums up the deprecation timeline. Important: Azure AD Graph Retirement and Powershell Module Deprecation seems to be the latest information on the deprecation. To sum up: It seems to be a typical Microsoft deprecation where they stop supporting the AzureAd module and API behind it, but it will still work.

Why

So why would/should we replace AzureAd? Unlike with Azure.Storage, there is (currently) no functional reason to replacing it.
Upgrade from Azure AD PowerShell has a nice list of reasons (most of them would apply to Azure.Storage as well). The cross-platform support would also open up the option to use Github codespaces/devcontainers for developing/testing/teaching/presenting the d365fo.tools.

Impact

The AzureAd module is currently used in one cmdlet, Import-D365AadUser.

The following table generated by PSAzureMigrationAdvisor lists the AzureAD commands used by Import-D365AadUser and their Microsoft Graph equivalent. The listed Microsoft Graph commands would require the modules Microsoft.Graph.Users and Microsoft.Graph.Groups (note that both modules are dependent on Microsoft.Graph.Authentication).

Path	Line	Before	After
import-d365aaduser.ps1	185	Connect-AzureAD	Connect-MgGraph
import-d365aaduser.ps1	189	Connect-AzureAD	Connect-MgGraph
import-d365aaduser.ps1	205	Get-AzureADGroup	Get-MgGroup
import-d365aaduser.ps1	210	Get-AzureADGroup	Get-MgGroup
import-d365aaduser.ps1	214	Get-AzureADGroup	Get-MgGroup
import-d365aaduser.ps1	236	Get-AzureADGroupMember	Get-MgGroupMember
import-d365aaduser.ps1	240	Get-AzureADUser	Get-MgUser
import-d365aaduser.ps1	245	Get-AzureADUser	Get-MgUser
import-d365aaduser.ps1	263	Get-AzureADUser	Get-MgUser

[Splaxi]

PSNotification will be removed going forward...

[Splaxi]

PSNotification is gone!

Next up is the AzureAd

[FH-Inway]

I've been looking a bit further into Microsoft.Graph and, well, it's complicated 🥲

Basically, there are actions you can do with AzureAd such as retrieving user information from Active Directory (now Entry ID) without any further permissions. With Microsoft.Graph, your admin needs to grant you those permissions first before you can do those actions.

As far as I understand microsoftgraph/msgraph-sdk-powershell#1409, this seems to be some red tape that is not really necessary, because the access is also controlled by the roles a user has. But Microsoft says they had to do it and couldn't get a version without those permissions approved and that people need to be educated 🙃

The linked issue mentions an option to grant all permissions for the Microsoft.Graph PowerShell module as a one time setup. I think that we should research that option and document it well. In any case, switching to Microsoft.Graph will likely mean a breaking change until people can get their permissions.

[FH-Inway]

Seems Microsoft is moving to Microsoft Graph as well and encounters the same issues: https://www.yammer.com/dynamicsaxfeedbackprograms/threads/2535916690333696

Their recommendation to use an app registration could be one option for us as well: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/secure-developer-vm#external-integrations

For cloud hosted environments, we may even be able to piggy back on that and use the same certificate. For other environments (local VHD, Azure DevOps pipeline, ...), using the app registration secret instead of the certificate may be more straightforward.

[FH-Inway]

I took another stab at this and got a proof of concept working, see #837

• 6d26d0f could be done fairly soon. It replaces the AzureAd dependency during installation of d365fo.tools with a dependency when the Import-D365AadUser cmdlet is called. The cmdlet checks whether the AzureAd module is installed and if not, installs it.
• dec5de1 is a first draft of a Import-D365EntraIdUser cmdlet to replace Import-D365AadUser. I have tested it using the Microsoft Graph certificate authentication using the certificate created by New-D365EntraIntegration. See https://gist.github.com/FH-Inway/baf5932f9dc8deba94faf24de7d7de75 for a sample output.

[FH-Inway]

@Splaxi As discussed, we want to look into whether we actually need the Microsoft Graph module or can retrieve the information directly from Active Directory / Entra ID using a REST API.

[FH-Inway]

@Splaxi As also discussed in #856 , pull request #860 now contains changes to remove the AzureAD dependency.

Connect-AzureAD was replaced with Login-AzAccount, which is a cmdlet from the Az.Accounts module. This module is an implicit dependency that comes with the Az.Storage dependency.

The other AzureAD cmdlets were replaced by direct calls to the Microsoft Graph Rest API via the Invoke-AzRestMethod cmdlet (good work, @Splaxi 👍 ).

I will leave pr #837 up for the time begin, since it also contains the certificate authentication, which should be easily transferrable to Login-AzAccount.

[FH-Inway]

The AzureAD dependency is removed in version 0.7.18.