All right, it’s time for some mandatory fun! Chad here again – ready to talk about some FAQ’s. I’m taking on a different approach than before (we previously talked about Azure MFA and Azure AD Connect). In this Mailbag we will be shifting focus on something that should be near and dear to many folks – “Organizations who operate in multiple countries”. There are many questions that come up around localization, supportability, performance, data compliance, and flexibility when customers are looking to deploy across multiple countries/regions. This concept is not new to Azure Active Directory – I’ve captured some common questions that comes up during these discussions. I hope you enjoy!
I’m looking to deploy Self Service Password Reset (SSPR) but I’m concerned the Security Questions that I configure might not be supported for all the different languages that I support for my users. How does Azure AD accommodate this requirement?
We call these questions “Knowledge based security questions” which are localized based off the user’s browser locale. These are pre-canned security questions that have been vetted and used by multiple Azure AD customers and signed off by Microsoft’s internal security review process; users may choose these questions for both registering for password reset and resetting their passwords based on how you have configured it in Azure AD.
When one my users receives a phone call or SMS from resetting a password (SSPR), what language will it be? How do I configure this?
Hey, good news! There’s no configuration required. Azure AD Password Reset is localized into the full Office language set. SSPR uses the user’s browser locale when choosing how to localize the SSPR page and all of its communication (SMS, voice, question languages). If a browser locale is not configured, it will use the user’s usage location. You can also pass the mkt parameter directly to the page if you want to force a specific locale for your users, like this: https://passwordreset.microsoftonline.com?mkt=es-es
I want to limit access based on country for my third-party applications (SaaS) and licenses for Azure AD Premium/EMS. How can I do this successfully?
Azure AD Premium/EMS licenses and SaaS applications can be managed by security groups – this doesn’t work with DL’s. These groups can be either synced from on-premises, cloud static security groups, or dynamic security groups in Azure AD.
The best approach would be to create a dynamic group based on attribute, such as an extensionAttribute 1-15, extension_GUID_attributeName (this is an attribute that you added through Azure AD Connect), or even something like usageLocation.
In this example, usage location can be changed in the Azure Portal under the user object:
Other ways to change usageLocation:
- PowerShell: Set-MsolUser -UserPrincipalName email@example.com -UsageLocation US
- Azure AD Connect maps msExchUsageLocation to usageLocation – attribute list
Another common rule that I’ve seen customers create is based on domain from the UPN (e.g. Brands that exist only in a certain country or brands that are acquisition can be targeted):
Assuming that contosoFrance.com exists in France, then you could make an Advanced Rule that contains both France and Germany
You could do the same type of function on-premises and sync the membership. Just note that Azure AD Connect has a limitation of 50k user membership per group.
I use a VPN service and it’s not uncommon for me to connect from Russia and then 30 minutes later connect from Canada or the United States. How do I reduce false positives from Microsoft’s Advance Reporting?
Under the “Configure” tab from the Azure Portal within your Azure AD, you will see an option called your organization’s public ip address ranges. If you configure your corporate network IP ranges here, it reduces those false positives in your advance reporting.
Note: You must configure both initial and ending IP range. (e.g. the IP range in the US and Canada in your question, for example).
I’m deploying Azure MFA to 70 countries and it must support 8 different languages for phone calls. I want to configure my own message in the local language – where do I go to configure this?
Log into Azure Portal -> Choose Active Directory icon (bottom left) -> Choose your directory -> Click Configure -> multi-factor authentication/Manage service settings -> advance settings at the bottom Go to the portal -> Voice Messages -> And….. You’re there! 🙂
Here you can add the different languages you want by clicking “New” and upload your .mp3 or .wav file. You will be required to map the file to the appropriate greeting/language. This overrides the default configurations
Most of our greetings are linked to high-level cultures such as “fr” so that more specific cultures such as “fr-FR” and “fr-CA” will all get an appropriate greeting. There are a few exceptions where dialects are different enough that there are specific greetings. For example, we have “pt-PT” and “pt-BR” for Portuguese and a variety for Chinese. Some of the Chinese greetings are duplicates, but older MFA Servers use older language codes that existed in .NET 2.0 (e.g. zh-CN) and the Azure MFA and newer MFA Servers use newer codes (e.g. zh-HANS). Here is the full list of the languages that we have greetings mapped to:
ar, bg, ca, cs, da, de, el, en, en-GB, es, es-ES, et, eu, fi, fr, gl, he, hi, hr, hu, id, it, ja, kk, ko, lt, lv, ms, nl, no, pl, pt-BR, pt-PT, ro, ru, sk, sl, sr, sv, th, tr, uk, vi, zh-CN, zh-HANS, zh-HANT, zh-HK, zh-TW
In MFA Server, the voice call language is a setting defined in the user’s profile that exists within MFA Server. If an admin set it to some language that we don’t have a greeting for such as “fo” or “ff”, those users would hear English greetings since we use English as the default backup.
Thanks for following our Mailbag! As a little bonus for those that read all the way to the end, the Customer Success Team also leads webinars available free to our customers that focuses on many aspects of Azure AD. Join the conversation! I look forward to meeting with ya’ll in our live presentation.
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, Shawn Bishop, Yossi Banai, and Adam Steenwyk