Surface/expose Azure MFA (Phone Factor) attribute data in GRAPH to facilitate API-based manipulation and mitigate some of the current limitations in RBAC within "cloud only" deployments of the Azure MFA service.
StrongAuthentication data can be read via PowerShell, but StrongAuthenticationUserDetails can’t be set via PowerShell. It is planned to expose the StrongAuthentication data via Graph, but no ETA to provide yet.
is there any hope this is being developed?
This is a putting a major project on hold as we are scrambling to find workarounds.
The ability to pre-populate SSPR/MFA mobile/email is critical to using AD SSPR for initial password creation by end users. This is in fact unlocks a perhaps unconsidered side capability of Azure AD if Product team recognises the potential here.
Ross Currie commented
Am currently working with a client who is facing a similar situation to some of the others here - need to set the Authentication Email and Authentication Phone attributes using data that has to be hidden from other members of the organisation.
The fact that you can't pre-register these fields is somewhat mind-boggling, since MIM SSPR provided this capability out of the box.
Any update on when this feature (set StrongAuthenticationUserDetails) will be made available?
We too need this feature to roll out SSPR.
We are interested in this feature as we do not want users to be able to view other users mobile numbers which is currently the only way to bulk upload contacts from extended AD attributes to Azure.
Because of GPDR we have users' phonenumbers in AD ia an extendedAttribute. We would like to sync these numbers to the authenticationPhone attribute but tat can not be done. This is something we need to start using SSPR.
This is something we need in order to start using SSPR. We have the users' phone numbers in AD in a hidden attribute (because some numbers may not be shown to other users). We would like to sync these numbers to the authenticationPhone attribute, but as that cannot be done we will need to deploy an alternative product for SSPR that has this capability.
just hit this issue too, we need to set PhoneNumber in StrongAuthenticationUserDetails to automate MFA deployment in our scenario, mobile phone and office phone may not be always the correct choice
This is a feature that will significantly improve our adoption of MFA. Please expose a way to do this ASAP. We are waiting very patiently...
Chris Zenzano commented
From a helpdesk perspective, We really require the ability to modify the Authentication phone # or set and enable Alternate authentication phone in the event a customer has lost or having issue with their mobile device.
We really require the ability to modify the phone number under authentication contact information for On-Premises Synced user in a bulk fashion, not just via GUI. Cant believe this has been released without these capabilities
Tre`Von McKay commented
Please let us know if there are any updates to share or an estimated timeline. This has a huge impact on our decision to select a new Identity Management solution.
Pierre Minnis commented
please review this, we need to be able to pre-register users for SSPR and the only option for this is to set the mobile phone number. This works as a password reset option but then the mobile phone attribute is visible in office 365. Come on please give us programmatic access to strong auth data
Scott Snyder commented
When are we going to get the ability to update StrongAuthenticationUserDetails via PowerShell? We have a bunch of executive level staff that have to walk through the enrollment process. That wouldn't be necessary if we could automate it.
Currently, the only available option to automate Azure MFA administration appears to be the MSOnline PowerShell module, released back in 2015.
MSOnline's Set-MsolUser and Get-MsolUser cmdlets allow administrators to enable and disable MFA on a user object using PowerShell scripts.
Alas, the MSOnline module itself does not support MFA when connecting to Azure AD. Administrators hoping to make use of the MSOnline module cannot have MFA enabled on their accounts. In short, for an admin to manage MFA with PowerShell, the admin's account can't be protected by MFA.
The new AzureAD and AzureaDPreview module do not expose any StrongAuthentication data.
The new Graph API does not expose any StrongAuthentication data. The old Azure AD Graph API doesn't, either.
Please fix this, or provide an update as to when it will be fixed.
Chris Wallace commented
Note: this was actually opened as SR 116033113904325 where it was suggested to post this request here for review and possible action. #AzureMFA #PhoneFactor #Office365