Allow Azure AD Sync to Prepopulate the Authentication Phone Number from an Onpremise AD Object, and prevent users from entering their own.
Allowing a User to set their own mobile number in MFA, completely negates the purpose of the Technology, in an Azure AD Connect environment.
For a Secure environment, The Administrator would set the Mobile Number as the source of Truth in Active Directory, and it should prevent a potential attacker, from changing the mobile number as they see fit.
If a user, who has not registered for Azure MFA yet, credentials are compromised, then an attacker could supply their own Authentication Number, and Azure MFA becomes ineffective.
We should have the ability to set the Authentication Number in AD, and have that Synced through to Azure AD. If the users number change, then they should contact their service desk to update their information in AD, or get an OTB.
Anonymous
shared this idea
12 comments
-
Anonymous
commented
If the option to just select 'authentication phone' in ADconnect would be available that would be great.
-
Karl Bean
commented
Agree.
-
Wijnand Kroes
commented
Agree
-
Richard Brooks
commented
We want to use our desk phone at the office for MFA. In fact it works, if we use the original (not the new SSPR and MFA combined) method. In that case, the AD field "telephoneNumber" gets propogated to the Office 365 "Office phone" field in the user's contact information. However, in Azure Active Directory > Authentication Methods, there is no field that picks up this number. When I paste the number (+1 905-544-5439 x219) into the "Alternate phone" field I get an "Invalid phone number format" error. This needs to be fixed, or we can't use the combined SSPR/MFA experience.
-
Anonymous
commented
There is also possibility to configure registration policy
-
jimmy
commented
Can we please have an update from @ms here? I've heard this feature is in private preview. Is it true?
-
Gary Bailey
commented
This should come from AD not user defined. Plain and simple. If a user can change it, so can an attacker. We need this feature enabled for Azure MFA to even be considered as a secondary authentication measure for our organization.
-
Techie 123
commented
I just discovered this whole when adding trusted locations for IP addresses to allow my service accounts to login from on premises. We need a Conditional Access policy along the lines of "Authenticator app registrations permitted from Trusted Locations Only" or similar.
I couldn't trust users to set strong passwords, and now I have to trust them to register for MFA?? Please fix this ASAP Microsoft.
-
G
commented
I agree with the need to be able to set the authentication details for users as an admin either bulk upload or manual however for regulated industries personal phone numbers often cannot be in the directory/published. How the MFA directory is separate from Azure AD now is something that needs to be retained or preserved as an option or NOT allow registration details to be tied to the AD fields.
-
Anonymous
commented
Completely agreed.
Although It is possible to set users' company phone numbers in on-premise AD and sync them through AAD Connect, you can't set company phone number as a way of OneWaySMS.
An Administrator should be able to do the same thing for users' authentication phone numbers.
That way MFA would be set before users actually start using their account, and users wouldn't be able to change it by themselves in the future. -
PieterRossouw
commented
Agreed Agreed Agreed. Azure MFA is not a Multifactor solution if it allows the user to specify their own Mobile Number. Whose dumb idea was that?
-
Anonymous
commented
If the above is not on the roadmap, or not possible, then we at least should have the ability to manually set the Authentication Number, and prevent the user from changing it themselves in future. That way we can read the Mobile Number from AD, translate it to the correct syntax +1 xxxx, and use Powershell to set the Authentication Number as an Administrator, preventing the user from changing the number themselves, or preventing an attacker from supplying a different mobile number when a user has not been registered for MFA in the past.