First published on CloudBlogs on Mar 18, 2016
All right, it's time for some mandatory fun! Chad here back again for another round of Azure MFA Q/A's ! I'd like to call this the "Azure MFA Server Edition" as it is focused on primarily this scenario. I recently worked with our Premier Field Engineering (PFE) onsite with an Azure AD Premium customer deploying Azure MFA server and you know what, they had some awesome questions!
I think you will enjoy these:
Question 1: Some of my users are outside of the United States (e.g. United Kingdom, China, Russia) and I'm concerned about how Azure MFA works with these users. How does Microsoft manage the Caller ID and will my users get charged additionally for using the Azure MFA services on their devices?
Answer: Our call gateways are currently in the US only. We always send the caller ID that is configured in the MFA Management Portal, but caller ID (especially outside the US) is best effort delivery. In some cases, calls will be routed through several carriers between origin and destination and some phone carriers in between might not support customized caller id. So in some cases users might see a different caller id. Azure Authenticator App users either your mobile service provider's data or WIFI if connected. SMS and phone calls are not charged any additional surcharges from Microsoft for receiving these authentications outside the U.S.
Please check with your local provider to see if accepting long-distance calls/SMS accrue additional fees. When using 2-way SMS with Azure MFA Server, outgoing responses will occur additional charges due to the text message response back to Azure MFA Services located in the United States.
Question 2: We have deployed Azure MFA Server on-premises with load balanced Mobile App Web Service activation servers, User Portals, and even multiple MFA servers. We want to take extra steps in securing our configuration for Disaster Recovery. How can we do this?
Answer: We recommend it wise to store backups of the PhoneFactor.pfdata file periodically (this can be done at any time while the service is running) located by default at C:Program FilesMulti-Factor Authentication ServerDataPhoneFactor.pfdata. Frequency of this can be determined based on your own internal policy of DR. That way, if there were any issues with the MFA data file, you could replace the corrupt file with the last known good backup and lose very little if any data.
Question 3: I have Azure MFA Server and I want to import my users automatically into the Azure MFA Server database without having to manually uploading each user every time through direct or with CSV file. How do I do this?
Answer: We do this through our "Directory Integration" tab from the MFA Server main UI. We support syncing from either Active Directory or LDAP (but not both) which is selected under the "Settings" tab under Directory Integration. Select "Synchronization" tab and click at bottom left "Add….". In order to have your groups show up, select "Selected Security Group" under the Import tab. This will then populate the Security Groups and you can then select specific groups.
Question 4: My users have configured backup phone numbers as a second authentication mechanism in case their primary phone number either breaks or doesn't pick up the call. Some of my users are reporting that it is not forwarding to their backup phone number. How does this work?
Answer: From the MFA system’s perspective, if the user answers the phone but hangs up without pressing #, that is an intentional denial and we don’t roll over to the backup number. If the user answers but we time out without an action being taken by the user (hanging up, pressing #), then we will roll over to the backup number. This would be the case if voicemail answered the call. Our system waits for 10 seconds after the voice greeting finishes playing to time out before dialing the backup number (voice must complete its message and hang up before our greeting times out). There are other things that force the rollover as well such as getting tri-tones (number has been disconnected), getting a busy signal, or invalid phone number.
Question 5: I have Azure MFA Server on-premises configured but I want to provide Conditional Access with a second factor authentication to my published apps in Azure AD and SaaS apps (e.g. Salesforce, SuccessFactors, Box). Can I do this even though my MFA solution is on-premises?
Answer: In Azure AD we support this Conditional Access scenario with on-prem MFA. The following example shows how to enable on-premises MFA by using the Set-MsolDomainFederationSettings cmdlet on the contoso.com tenant: Set-MsolDomainFederationSettings -DomainName contoso.com -SupportsMFA $true
Please visit our other resources to learn more about how Azure Conditional Access can work for SaaS apps.
Question 6: I'm trying to understand the logic flow of AD FS and MFA Server as it works with Azure AD. Can you provide an end to end mapping on how it works?
Answer: Great question! It can be confusing on how the flow works so let's create a visual: 
2. Application redirects to Azure AD for authentication
3. Azure AD redirects to AD FS
- a. Federated domain has been configured between AD FS and Azure AD
- b. Microsoft loads logon page
- c. User inputs credentials which executes home realm discovery
- d. Home realm discovery uses suffix to determine federated trusts and redirects to your configured AD FS endpoint (AD FS Proxy)
4. AD FS Proxy receives and validates request and forwards to AD FS server
5. AD FS performs windows logon against on-premises Active Directory
6. AD authenticates user
- a. AD FS server validates the MFA policy and sees that MFA is required; AD FS loads the installed MFA adapter
7. AD FS MFA adapter sends request to MFA server. MFA server finds that user in its data store, looks up user’s MFA settings
8. MFA server sends request to MFA Service
9. MFA service performs the call, text, or notification
10. Device returns result to MFA service
- a. NOTE: For one-way SMS or OATH token, the MFA AD FS adapter displays a textbox to the user into which they will then enter their OTP
11. MFA server receives authentication result from MFA cloud service
12. MFA server returns result to AD FS MFA Adapter
13. Upon successful validation, AD FS executes issuance policy and generates a security token based on the claims and passes it to the AD FS proxy
14. AD FS proxy passes security token to Azure AD
15. Azure AD creates a new security token and sends this security token to the application with the appropriate claims
16. User has gained access to Azure AD and is redirected to the application/service And there it is - End to End with MFA, AD FS, and Azure AD. Shout out to Jack Stromberg and Ricky Pullan for collaborating on this one!
Question 7: I have MFA Server configured on-premises and I'm looking to enable PIN mode for my users - I want my users to receive their initial PIN via email automatically when they are imported from the directory. I've tried getting it to work but the emails aren’t being sent out. How can I configure this to automatically email the PIN to my users?
Answer: First you configure a SMTP server that allows emails to be sent to end users. There is an email template for “New Users” which is sent when a user configured for PIN mode is added to the system. This is typically done by configuring PIN mode in the directory synchronization item. The New User email sent to the user during import includes the PIN. There is a differences between New User and User Enrollment email templates . The difference is in the information imported from Active Directory such as user mobile number. When the user is imported with complete information, the New User email is sent and includes the PIN information. When the phone number does not exist, the User Enrollment email is sent and does not include the user’s PIN information.
- New Users - An email is sent to a user added that is enabled and complete (phone specified, mobile app activated, or OATH token secret key specified).
- User Enrollment - An email is sent to a user added/imported with incomplete enrollment (no phone specified, mobile app not activated, or no OATH token secret key specified). The email is only sent if Allow User Enrollment is checked in the User Portal section.
- Updated Users - An email is sent to an updated user that had their Phone or PIN changed.
The enrollment process does allow a New User to set their PIN during enrollment in the User Portal. Please note that PIN mode is not available for OATH Tokens.
We hope you’ve found this post and this series to be helpful. For any questions you can reach us at AskAzureADBlog@microsoft.com, the Microsoft Forums and on Twitter @AzureAD , @MarkMorow and @Alex_A_Simons
-Chad Hasbrook, Mark Morowczynski and Shawn Bishop