Forum Discussion
How can I use a System Managed Identity with Connect-MsolService
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.
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
This endpoint is remarkably good - so much so that I can leverage it in the identity management space,.
Where the previous approach of having to fetch a user before fetching their MFA details (using Get-MgBetaUserAuthenticationEmailMethod) was prohibitively slow, the speed from using this endpoint is blindingly fast.
I've never run the former approach over a large tenant, as even in a small tenant it takes minutes just to get a thousand people's MFA details. However, using the userRegistrationDetails endpoint, 117k accounts were enumerated in 3min 30 sec, which is incomparably faster.
This allows an IDM to make access and authorisation decisions that incorporate granular MFA settings, which is something not achievable using Azure dynamic groups (as one example).
Cheers,
Lain
Hi, Jack.
Having a read of the per user endpoint (doco below), it's implied that only enabled methods are returned:
I ran a quick test against my account using the "authenticationMethods" endpoint by adding, checking, removing and re-checking (waiting a couple of minutes between checks as things don't update instantly) the Microsoft Authenticator method via the user interface located under avatar > Settings > Security Info, and that does indeed seem to be the case.
Considering the notion of what constitutes "MFA strength" (doco below) is fluid, it seems to me (with the usual disclaimer that I am no longer familiar with MSOnline and therefore may well be wrong) that there is enough data there for you to make the determination of whether strong authentication is enabled, it's just that unlike what you're describing in MSOnline, you have to do that coding yourself rather than leveraging the convenient MSOnline-provided rollup contained within StrongAuthentication.
The top result is after I added MS Authenticator as a sign-in method and the bottom is after I removed it again.
Cheers,
Lain
- Hey Lain,
Once again, I want to seriously thank you for your commitment to this post!
I am currently using the last approach (ListUserRegistrationDetails), but it has been deemed insufficient in comparison to the report that we used to use where a specific property of "Enabled", "Disabled" or "Enforced" can be found using the StrongAuthentication.State property.
Without that property, or anything similar in MSGraph, I'm currently unable to report on user MFA status within our organisation, which has again been deemed insufficient. As MSOnline is being deprecated, my hope is that this kind of information will eventually be available in MSGraph.
The previous method you mentioned around assuming a person's MFA status based on registered methods is also insufficient, as it's reporting on the tokens used. In our case, we need to specifically check whether a user CURRENTLY has MFA enabled, not whether they have EVER had it enabled in the past. My only solution to that problem is that we delete the token history everytime these situations of users having new devices and needing to re-register, etc. Do you have any thoughts on this?
