search

d365collaborative / d365fo.tools

Tools used for Dynamics 365 Finance and Operations
MIT License
236 stars 97 forks source link

➖ ➕ Remove PSNotification, replace AzureAd with Microsoft.Graph #744

Open FH-Inway opened 11 months ago

FH-Inway commented 11 months ago

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

https://github.com/d365collaborative/d365fo.tools/blob/f5f90697cf85216f0e92df6b4321edaa111a6f30/d365fo.tools/d365fo.tools.psd1#L30-L37

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 commented 11 months ago

PSNotification will be removed going forward...

Splaxi commented 11 months ago

PSNotification is gone!

Next up is the AzureAd

FH-Inway commented 7 months ago

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 https://github.com/microsoftgraph/msgraph-sdk-powershell/issues/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 commented 6 months ago

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 commented 1 week ago

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