In this video, Pete Zerger explains Multi-Factor Authentication (MFA) in the federated identity model with Active Directory Federation Services. Learn the authentication process flow and additional MFA features that come in the federated identity model.
- [Instructor] Let's talk about multi-factor authentication in the Federated Identity model. In this scenario, the model requires a synchronized identity but with one major difference, the user password is verified by the on-premises identity provider, Windows Server Active Directory. Federated Identity requires Active Directory Federation Services or ADFS. ADFS also brings support for additional factors of authentication to MFA that we don't see in the synchronized module, such as the addition of certificate based authentication or use of hardware tokens.
In the Federated model, the ADFS server is called the Secure Token Service. The active directory server is the identity provider, and in this example Office 365 is known as the relying party. The relying party, Office 365 in this example, receives tokens for identification and authorization. Both internal and external client will access the ADFS server by the same name, in our case, fed.kinetecoinc.com which means we'll use split brain DNS so internal and external clients resolve the address correctly.
However, internal clients access the ADFS server directly whereas external clients access the web application proxy which securely proxies the request to ADFS from the external client. This is a simplified diagram, your ADFS farm, as it's called, will have two or more servers as will your lab configuration for high availability. The ADFS server will then, contact an AD domain controller which authenticates the request and then sends the token back to the internal user directly, or to the external user via the web app proxy.
Let's look at a common example like Office 365 request. So, step one, the user enters their user printable name, the email address format we talked about in the Office 365 portal log on page. These credentials exist in the Azure AD tenant because they were synchronized by Azure AD Connect. Office 365 queries Azure AD for sign in settings for the users domain, Azure AD checks the HTTP headers for any defined whitelist of organizational domains, and if the UPN suffix is in the list, it precedes to the next step.
Azure AD then redirects the user to our ADFS DNS name to obtain authentication from the ADFS proxy form. ADFS validates log on hours and credentials and then returns the authentication token to Azure AD, the token is valid for whatever period for which ADFS is configured at this point, the user goes back to Azure AD via Office 365. Azure AD then evaluates application and user conditional access rules, for example is the user configured for MFA? And if so it will evaluate conditional access rules if they're in place.
Is the user allowed to access from this location? And does this location require MFA? Is the user accessing from a compliant device? Is the application assigned to this user? Is this a risky sign in? Remember risk analysis comes with Azure AD Premium Plan two. And, the step up authentication for the user via Azure MFA is complete, if MFA fails, access to the ampere service is denied, but if MFA is successful, Azure AD grants an access or authorization token for the application and the access token is valid for one hour.
The refresh token is valid for 90 days, at which point the application asks Azure AD for a refresh token. At which point the application asks Azure AD for a refresh token, if the user status has not changed, not blocked, the group hasn't changed and the authentication token is still valid, the authorization token is silently refreshed. So just to recap the key points for ADFS with MFA. Both internal clients and external clients resolve the same name.
The federation server generates the tokens and the claims. On-premises Active Directory Domain Controllers validate user credentials not Azure AD. Token and claims are sent via SAML or Java Web Tokens, OAUTH in the background. And the relying party, Office 365 in this example, receives tokens for identification and authorization and ultimately enables additional factors of authentication we don't see in the synchronized model like certificate authentication or hardware tokens enabling arcs to maintain the identity provider in their on-premises active directory when necessary.
In this course—the first in the series—Microsoft MVP Pete Zerger takes you through the basics of setting up endpoint protection. He begins by explaining how to set up Azure Active Directory Premium. Next, he goes into enabling multi-factor authentication, followed by setting conditions for secure access. To wrap up, Pete covers managing mobile devices with Intune, and publishing applications with Azure AD App Proxy.
- Setting up Azure Active Directory for an organization
- Enabling user-level and application-level multi-factor authentication
- Setting conditions for secure access
- Planning a mobile device management (MDM) strategy
- How Intune (standalone) MDM works
- How Intune mobile application management works
- Publishing applications with Azure AD App Proxy
- Assigning users and groups