First published on CloudBlogs on May 06, 2016 by the Microsoft Azure Active Directory Team
All right, it's time for some more mandatory fun! Chad here back again for another round of Azure MFA Q/A's! Based on some earlier feedback from the previous blog , we dug deeper in adding more scenarios on auth flows for MFA. These questions are a mixture of both Azure MFA services and Azure MFA server.
Question 1: I have Azure MFA Server and I'm implementing PIN for my users. What is the max length of PIN?
Answer: The Max PIN Length in MFA Server is 20 digits.
Question 2: When you disable MFA for a user in Azure AD, what happens to the MFA data? Does it delete it? (for cloud-based Azure MFA services)
Answer: It clears the MFA state (StrongAuthenticationRequirements) and their MFA methods (StrongAuthenticationMethods) immediately. It does not clear their registered phone numbers (StrongAuthenticationUserDetails) or mobile app configuration at all.
Question 3: We have 1 Azure MFA master server and 3 Azure MFA slave servers on-premises. Am I able to make updates on the slave servers? Is there a recommendation?
Answer: Let's start with the second part of the question first. It is recommended that you make changes on the master Azure MFA server as it has the closest connection to the configuration. However, when you do use the configuration UI on a slave it's actually connecting to the master. So you can really do both but we recommend to just do it on the Master.
Question 4: Can you walk me through the scenario of a federated user accessing a SaaS app with Conditional Access and Azure MFA services?
Answer: Here you go!
Leg 1: User externally accessing a direct link to an application federated to Azure AD and gains an initial security token from AD FS.
1. User requests access to application
2. Application redirects to Azure AD for authentication
3. Azure AD redirects to AD FS
- Federated domain has been configured between AD FS and Azure A
- Microsoft loads logon page
- User inputs credentials which executes home realm discovery
- Home realm discovery uses suffix to determine federated trusts and redirects to your configured AD FS endpoint (AD FS Proxy)
4. AD FS validates the credential against on-premises Active Directory
5. AD authenticates user
6. Upon successful validation, AD FS/ AD FS Proxy executes issuance policy and generates a security token based on the claims and passes it to the Azure AD
Leg 2: Azure AD requires multifactor from Azure MFA cloud services. User successfully performs MFA and is now is allowed to gain access to Application.
7. Azure AD creates a new security token and then checks the conditional access policy configured in Azure AD for the targeted application. Azure AD notices that the client does not contain the MFA parameter and requests multifactor from Azure MFA services.
8. Conditional Access Policy on application requires MFA
9. Authentication information, policy, and admin configurations are all kept in Azure AD
10. At this point in time the user can move around freely to all applications federated with Azure AD that do not require for MFA
11. MFA service performs the call, text, or notification
12. Device returns result to MFA service
13. Azure AD receives authentication results from MFA cloud service and creates a new security token with the additional MFA claim parameter used in this active session
14. Azure AD creates another security token as the IdP and sends this security token to the application with the appropriate claims
15. User has gained access to Azure AD and is redirected to the application/service
Question 5: Can you walk me through the scenario of a federated user accessing a SaaS app with Conditional Access and on-premises MFA?
Answer: Very similar to above but we redirect to your on-premises environment.
Leg 1: User externally accessing a direct link to an application federated to Azure AD and gains an initial security token from AD FS.
1. User requests access to application
2. Application redirects to Azure AD for authentication
3. Azure AD redirects to AD FS
- Federated domain has been configured between AD FS and Azure AD
- Microsoft loads logon page
- User inputs credentials which executes home realm discovery
- Home realm discovery uses suffix to determine federated trusts and redirects to your configured AD FS endpoint (AD FS Proxy)
4. AD FS validates the credential against on-premises Active Directory
5. AD authenticates user
6. Upon successful validation, AD FS/ AD FS Proxy executes issuance policy and generates a security token based on the claims and passes it to the Azure AD
Leg 2: Azure AD requires multifactor from on-premises and redirects to AD FS. User successfully performs MFA and AD FS sends correct claim to Azure AD, allowing user to gain access to Application.
7. Azure AD creates a new security token and then checks the conditional access policy configured in Azure AD for the targeted application
- Conditional Access Policy on application requires MFA
- Azure AD acknowledges required step-up authentication and redirects to AD FS/AD FS Proxy with an additional MFA claim parameter request as required in token request
- You must configure this by domain through PS to redirect to on-premises Azure MFA server outlined here .
- At this point in time the user can move around freely to all applications federated with Azure AD that do not require for MFA
8. AD FS receives request, validates the cookie, and forwards to MFA server
- AD FS server validates the MFA policy and sees that MFA is required; AD FS loads the installed MFA adapter
- AD FS MFA adapter sends request to MFA server. MFA server finds that user in its data store, looks up user’s MFA settings
9. MFA server sends request to MFA Service
10. MFA service performs the call, text, or notification
11. Device returns result to MFA service
- 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
12. MFA server receives authentication result from MFA cloud service
13. MFA server returns result to AD FS MFA Adapter
14. Upon successful validation, AD FS/AD FS Proxy executes issuance policy and generates a security token based on the claims and passes it to the Azure AD
15. Azure AD creates a new security token as the IdP 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
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