Home

MFA secondary call getting stuck in VOIP auto-receptionist

%3CLINGO-SUB%20id%3D%22lingo-sub-1069987%22%20slang%3D%22en-US%22%3EMFA%20secondary%20call%20getting%20stuck%20in%20VOIP%20auto-receptionist%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1069987%22%20slang%3D%22en-US%22%3E%3CP%3ECan%20we%20fix%20(so%20we%20can%20predict)%20the%20originating%20telephone%20number%20for%20MS%20authentication%20calls%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20our%20small%20office%2C%20I%20want%20to%20configure%20Office%20365%20MFA's%20secondary%20validation%20method%20as%20being%20a%20call%20into%20our%20office%20number.%20(I%20know%20we%20can%20use%20the%20authenticator%20app%20but%2C%20for%20one%20particular%20account%2C%20that%20isn't%20the%20best%20solution%20for%20us).%20However%2C%20we%20have%20an%20auto-receptionist%20on%20our%20VOIP%20system%20with%20the%20result%20that%20authentication%20calls%20from%20MS%20time-out%20whilst%20in%20the%20queue.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can%20create%20a%20rule%20on%20our%20VOIP%20system%20which%20will%20allow%20MS%20authentication%20calls%20to%20by-pass%20the%20auto-receptionist%3A%20inbound%20authe%20tication%20calls%20would%20be%20directed%20to%20a%20particular%20handset%20and%2C%20from%20MS'%20perspective%2C%20the%20call%20would%20only%20be%20%22answered%22%20when%20someone%20pickes%20up%20that%20handset%20(i.e.%20the%20auto-receptionsit%20would%20not%20intervene).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMy%20issue%20is%20that%20we%20need%20to%20specify%20the%20originating%20caller%20ID%2Fphone%20number%20in%20the%20rule.%20Our%20tests%20have%20shown%20that%20calls%20from%20MS%20originate%20from%20a%20range%20of%20numbers.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHence%2C%20my%20question%3A%20is%20there%20a%20way%20to%20fix%20the%20originating%20number%20MS%20will%20use%2C%20so%20that%20I%20can%20configure%20my%20VOIP%20rule%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1069987%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAuthentication%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Highlighted
Occasional Visitor

Can we fix (so we can predict) the originating telephone number for MS authentication calls?

 

For our small office, I want to configure Office 365 MFA's secondary validation method as being a call into our office number. (I know we can use the authenticator app but, for one particular account, that isn't the best solution for us). However, we have an auto-receptionist on our VOIP system with the result that authentication calls from MS time-out whilst in the queue.

 

I can create a rule on our VOIP system which will allow MS authentication calls to by-pass the auto-receptionist: inbound authe tication calls would be directed to a particular handset and, from MS' perspective, the call would only be "answered" when someone pickes up that handset (i.e. the auto-receptionsit would not intervene).

 

My issue is that we need to specify the originating caller ID/phone number in the rule. Our tests have shown that calls from MS originate from a range of numbers.

 

Hence, my question: is there a way to fix the originating number MS will use, so that I can configure my VOIP rule?

 

 

 

1 Reply
Highlighted
I had the same problem with some of my users who did not want to install company apps on their personal phones. I ended up purchasing a hardware-based MFA token because we also had an auto-receptionist that was not compatible (same as you).
There is a place to configure the source caller ID in Azure here:
https://portal.azure.com/#blade/Microsoft_AAD_IAM/MultifactorAuthenticationMenuBlade/PhoneCallSettin...
But I don't know if this is only for the older Azure MFA server product which is being retired or if it will also work for your Azure AD cloud user. Give it a try and let us know if it worked.
Otherwise, your last resort is the hardware token.
There are many options in the market. The one that I ended up selecting is called Token2, because it was only twenty dollars and is compatible with Azure AD so there is no local server to install.
https://www.token2.com/shop/product/token2-c301-programmable-keyfob-token-with-restricted-time-sync
And then the instructions are here:
https://www.token2.com/site/page/classic-hardware-tokens-for-office-365-azure-cloud-multi-factor-aut...
(The instructions above require Azure AD Premium P1).
If you don't have Azure AD Premium P1 then you need to purchase a USB NFC Burner so you can associate the random number seed on the token with azure as described in the instructions here:
https://www.token2.com/shop/page/hardware-tokens-for-azure-cloud-multi-factor-authentication

If this was helpful please mark as best answer, thanks!