First published on CloudBlogs on Jan 27, 2017 by Microsoft Azure Active Directory Team
Hey y’all,
Mark Morowczynski here with the second part of our two part MFA mailbag. To read part 1 click here . Also for those that haven't been reading these mailbags since the beginning you can read all the previous 21 posts using the ' mailbag ' tag. We are trying to make these Friday posts a regular thing and next week will cover App Proxy. If there are topics you'd like to see us discuss, even some that might require a much deeper dive let us know.
Now on to the questions.
Question 6: If you publish the on-prem MFA User Portal / MFA Server Mobile App Web Service with Azure AD Application Proxy, does this require a public cert? Can a private cert be used?
Answer 6: Technically, you can use a self-signed cert for MFA User Portal if you are willing to have users ignore the cert warnings/errors, but that isn’t recommended for an optimal end user experience. The MFA Server Mobile App Web Service on the other hand does in fact require a public certificate. Otherwise, the Microsoft Authenticator App will not be able to connect to the web service successfully, preventing the a successful activation.
Question 7: Is there any equivalent feature in the Azure MFA Server for " Allow users to remember multi-factor authentication on devices they trust " that is available in Azure MFA?
Answer 7: No, except when using IIS Authentication to secure IIS-based websites. In that case, a cookie can be set to only require MFA every X minutes but it isn’t something the end user opts into by checking a box. The cookie is set on whichever browser the user signs in from. When using RADIUS or LDAP, MFA is performed with every verification request. That’s typically desired because the verifications are generally for remote access. When securing ADFS, ADFS has full control over when MFA is required and when it isn’t.
Question 8: Can we use both Azure MFA Server to secure on-premises applications and Azure MFA for Office 365? How do /can they both these work together?
Answer 8: You can use Azure MFA Server to secure both on-premises applications and cloud applications that federate to ADFS, including O365 and other apps that federate to Azure AD. It is best to not use both Azure MFA Server and Azure MFA for the same set of users though because they would have to register and manage MFA enrollment data in both places. It make sense to utilize Azure MFA for your cloud-based users and Azure MFA Server for your federated sync'ed users. If you use both, it is best to control it with groups so that certain groups use on-prem MFA and everyone else uses cloud-based MFA. You’ll need to ensure that the SupportsMfa setting in the tenant DomainFederationSettings is set to False in this case. When AAD sends the user to ADFS for primary auth, ADFS will force users that are members of designated groups to perform MFA on-premises. So, ADFS will return the AuthMethodsReferences claim indicating that MFA was performed for those users, but not for the other users that aren’t members of those groups. Then Azure AD can perform cloud-based MFA for all of the other users. This design will apply to all auth flows on the reliant party trust (e.g. all applications that use Azure AD as the IdP).
Question 9: Is there a way for us to migrate users [from our Azure MFA Server] to Azure MFA so there is no action required from the user’s perspective?
Answer 9: We don’t have a way to migrate users today from Azure MFA Server to cloud-based Azure MFA. We have heard this feedback previously and it is something that we are discussing.
Question 10: We currently use TMG to proxy the ADFS front end to determine whether the user is coming from external. If they are external, the user is directed to Azure MFA Server to perform MFA. Any issues with this strategy ? We’d like to deprecate TMG over time, but not lose functionality.
Answer 10: No issues with that approach. ADFS should be returning the InsideCorporateNetwork claim to Azure AD when users are inside the network, and thus not going through TMG or WAP. InsideCorporateNetwork claim can also be sent to Azure AD to determine whether you are on or off the network as well.
Question 11: Can you/How do you secure on-prem OWA with MFA?
Answer 11: To secure on-prem OWA (not rich clients), you have the following options:
- Publish OWA using Azure AD App Proxy. This allows the customer to either use cloud-based Azure MFA ( https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-clo...) or to use Azure MFA Server with ADFS ( https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-adf...).
- Configure OWA for claims-based auth to ADFS. Use MFA Server to secure ADFS. This requires Exchange 2013 or higher.
If using a reverse proxy such as F5 in front of OWA that can do pre-authenticate via RADIUS or LDAP, you can point the RADIUS or LDAP authentication to MFA Server
Thanks for reading. Check back next week for more mailbag goodness. 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, Todd Gugler
