How can I use a System Managed Identity with Connect-MsolService

Jonesy6123 

I need to form the habit of checking the REST APIs first, not after I've posted based on the modules.

That entire script above could easily enough be replaced with a one-liner that calls an endpoint that I can't easily see represented in the Graph modules.

• List userRegistrationDetails - Microsoft Graph beta | Microsoft Learn

Not only does this trivialise the code, it's significantly faster and comes with a much wider array of status flags - which I imagine might even be more than MSOnline provides.

(Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/reports/authenticationMethods/userRegistrationDetails" -OutputType PSObject).value;

Edited: I didn't have my thinking cap on when I wrote "one-liner", since of course, the result size could readily be larger than the page size.

Here's a "proper" implementation of the REST approach:

$uri = "https://graph.microsoft.com/beta/reports/authenticationMethods/userRegistrationDetails";

while ($null -ne ($Response = Invoke-MgGraphRequest -Method GET -Uri $uri -OutputType PSObject)) {
    $Response.value;
    
    if (-not $Response.'@odata.nextLink')
    {
        break;
    }

    $uri = $Response.'@odata.nextLink';
}

Cheers,

Lain

Jonesy6123 

Hi, Jack.

I've had a quick read - which means I'm far from being accomplished in this area - and come to the conclusion I cannot test this specific scenario.

• Managed identities for Azure resources - Managed identities for Azure resources | Microsoft Learn

Prior to finding the article above, I was thinking I might be able to utilise the user-assigned managed identity, however, that's not possible.

Both types (system- and user-assigned) of managed identity are only useful in the scenario where they are being used by an Azure resource, not by a user like me sitting in front of an interactive PowerShell console.

I work in the identity space, not the Azure resource space, meaning I have no means for conducting such a test (such as calling an Azure runbook from an Azure virtual machine).

So, that rules managed identities entirely out for me and the work that I do (where certificate-based authentication achieves the similar end of not having credentials in the script).

To be clear though, conceptually, you absolutely can do what I covered in my earlier post using managed identities, which was:

• Sign into Graph;
• Obtain an Azure Graph (as distinct from a Microsoft Graph, which didn't work in my limited testing and I didn't investigate why) token;
• Pass to MSOL via the -AdGraphAccessToken parameter.

Perhaps someone else with Azure resource access could test this, though again, this approach make not have a long lifetime ahead of it with the imminent deprecation of the Azure AD Graph endpoint.

Moving on from the MSOnline module topic...

Here's a basic script that pulls MFA data using the Microsoft.Graph (notably the "beta") modules - noting that each different type of MFA has its own property structure.

Note, you can also filter for explicit MFA types on the Get-MgUserAuthenticationMethod commandlet directly, which would be more efficient than client-side filtering (which is horribly inefficient).

The script will necessarily be wickedly slow in large environments for reasons I've explained in a previous post above, but you can always filter down the users on the first line through leveraging the server-side filtering provided by the -Filter parameter (rather than using the -All parameter as I have for this example).

Example

Get-MgBetaUser -All -Property id, userPrincipalName |
    ForEach-Object {
        $user = $_;

        $Hash = @{
            userId = $user.id;
            userPrincipalName = $user.UserPrincipalName;
            mfaEnabled = $false;
            authMethodId = $null;
            authMethod = $null;
        };

        if ($null -ne ($mfaData = (Get-MgBetaUserAuthenticationMethod -UserId $user.id | Where-Object { $_.id -ne "28c10230-6103-485e-b985-444c60001490"})))
        {
            $Hash["mfaEnabled"] = $true;

            $mfaData |
                ForEach-Object {
                    $HashCopy = $Hash.Clone();

                    $ap = $_.AdditionalProperties;
                    $HashCopy["authMethodId"] = $_.id;
                    $HashCopy["authMethod"] = $ap["@odata.type"].Split(".")[-1];
                    $null = $ap.Remove("@odata.type");
        
                    $ap.Keys.ForEach({
                        $null = $HashCopy.Add($_, $ap[$_]);
                    });
        
                    [PSCustomObject] $HashCopy;
                }
        }
        else
        {
            [PSCustomObject] $Hash;
        }
    };

Example output #1

This is from using Format-List and shows the extra, per-MFA type attributes available. Format-Table won't show them all since its heading is derived from the first returned result.

Example output #2

This is from the Format-Table appendage and only shows the properties common to all rows.

You wouldn't use Format-Table to generate a report but it does illustrate how a common format could look if you weren't interested in the additional data Graph provides.

Because I do not use MSOnline, I don't know to what extent the above examples compare to what you can achieve with MSOnline, and without a report sample to compare to, I can only make assumptions.

You can readily add more data from the user account but the purpose of these examples is to illustrate what kind of raw MFA data is currently available via Graph.

Cheers,

Lain