All right, it’s time for some more mandatory fun! Chad here back again for another round of Azure MFA Q/A’s! This Mailbag has a mixture of MFA Server, persistent cookie scenarios, sessions, and broker assistants. For those who have either deployed MFA, looking to deploy it, or in the process of deploying Azure MFA – this information should be useful.
I’m setting up RADIUS Authentication with my on-premises MFA server. If I wanted to use two different authentication types under the “Target” tab for RADIUS authentication, how do I do this? It will not let me. Am I missing something?
You can’t map different targets to different clients. The one target you select applies to all clients.
Do you have any idea if we can use Windows Auth for the RDGateway setup using RADIUS Auth?
The protocols used by RD Gateway can’t be processed by MFA Server natively, so you have to use MFA Server as a RADIUS proxy to NPS. That can be the instance of NPS running on the RD Gateway server or a centralized NPS. NPS then does the primary auth against AD. NPS should be able to perform the primary auth for all RADIUS clients against AD, so setting the MFA Server RADIUS target to “RADIUS server(s)” shouldn’t provide any restrictions over selecting “Windows domain” as the target. See https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-server-rdg/ for deployment guidance.
When signing in through Azure AD, how does the “Don’t ask again for X days” checkbox displayed from the Remember MFA feature affect the user’s device? Is it a persistent cookie in the browser? Is it a certificate on the device?
Today this is done through a persistent cookie stored on the device. The cookie expires after X days, thus requiring the user to perform MFA again at that time. See https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-whats-next/#remember-multi-factor-authentication-for-devices-users-trust.
How does the Remember MFA feature work with end-users using multiple browsers (e.g. Edge, IE, Chrome, Firefox)? Does the feature work across browsers when the user checks the “Don’t ask again for X days” checkbox?
The user must check the “Don’t ask again for X days” checkbox on each device/browser individually. Please note that IE and Edge browsers do not share the same persistent cookie. See https://blogs.technet.microsoft.com/enterprisemobility/2014/08/20/suspend-mfa-on-a-remembered-device-now-in-preview/ for a deeper dive.
How does it work when a user uses something such as OneNote? Will it work for all other browsers? Is there a browser that it is not compatible with?
We don’t show the “Don’t ask again for X days” checkbox for rich clients. We only show it for browsers since cookies only work for the different browsers (e.g. Firefox, Edge, IE, Chrome). See https://support.microsoft.com/en-us/kb/932118 for more information about cookies with Office vs. browsers.
Are there scenarios that prevent the Remember MFA feature from working?
If the cookie couldn’t be set or be read, it wouldn’t work.
I do not have ADAL enabled for my Outlook client but I have MFA enforced for my users. We use App Passwords for my Outlook clients but I’m still being prompt when accessing a document from Word that is saved on SharePoint online. Why is this?
There are a few variables that go into making this a smooth process.
- SharePoint Online is natively enabled for modern authentication using the Active Directory Authentication Library (ADAL). In order to have a better experience, your Outlook client should be enabled for modern authentication as well. The Outlook client doesn’t require App Passwords when using modern authentication.
- Depending on where the documentation is saved, will impact whether it is authenticating against SharePoint Online (SPO). If you go to SPO and open it here, then choose to open it locally – it will authenticate against SharePoint Online and require you to MFA. If you have already MFA’ed in your ADAL-enabled Outlook client then, SharePoint will leverage the existing refresh token to gain a new access token from SharePoint to give you access to the document. This flow will not prompt your end users to authenticate because they have an active session.
- See https://blogs.office.com/2015/11/19/updated-office-365-modern-authentication-public-preview/ for guidance on which clients currently support modern authentication, and how to enable modern authentication for Exchange Online and Skype for Business along with other information.
I have Windows, Android, and iOS devices in our corporate environment. Why do I have to download the Azure Authenticator application to gain SSO to Office for Android and iOS and not required for Windows phones?
iOS and Android require broker assisted logins. What does this mean? I’ll reference our documentation:
“Broker-assisted logins are login experiences that occur within the broker application and use the storage and security of the broker to share credentials across all applications on the device that leverage the Microsoft Identity platform. This means that your applications will rely on the broker in order to sign users in. On iOS and Android these are provided through downloadable applications that customers either install independently or can be pushed to the device by a company who manages the device for their user. An example of this type of application is the Azure Authenticator application on iOS.
“If a compatible broker is installed on the device, like the Azure Authenticator application, the Microsoft Identity SDKs will automatically do the work of invoking the broker for you when a user indicates they wish to log in using any account from the Microsoft Identity platform.”
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 and Shawn Bishop