ADFS 2016 changes the way Multi-Factor Authentication (MFA) is configured. With previous versions of ADFS, MFA Server was downloaded and the ADFS adapter installed to provide MFA for internal users. With windows Server 2016, the architecture has changed so that ADFS 2016 is integrated with Azure MFA. This means that the IT admin does not need to install any special software or adapter to get MFA working. In addition, MFA now can be used as a primary method of authentication―users don’t need to enter in their password to get access to resources, they can verify who they are using their phone (call, text) or by using the Microsoft Authenticator app.
Before ADFS 2016 MFA can be used, MFA servers need to be registered on your Azure AD tenant: This following needs to be done for each ADFS server in the farm. There is good documentation on how to get this done here: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa
In my lab environment, I installed ADFS 2016 and used the Export and Import scripts available in the Windows Server 2016 media to move over the settings from my 2012 R2 server. The scripts are located in the Support\ADFS folder of the OS media. The biggest key to making this work is to make sure you use the same service account.
FYI:You can easily add ADFS 2016 server into an existing 2012 farm seamlessly but I did not choose to go that route.
A certificate needs to be generated on the ADFS server which will be used for authentication against Azure AD.
After a certificate is generated, a new service principal needs to created and the certificate information associated with the service principal. This allows the ADFS servers to authenticate/communicate with the Azure MFA client successfully.
When executing the command to create the service principal ID, you are met with an error saying the end date is an invalid parameter. This seems to be a bug and I was able to get around this by omitting the start and end date altogether.
Now that I have MFA service registered with Azure AD, I can go ahead and enable MFA as an authentication method. With 2016, MFA is actually available as a primary method of authentication.
One of the prerequisites to get Azure MFA to work on-premise is that the “proof-up” or the setup of MFA information needs to happen in Azure AD. This means that multi-factor authentication needs to be enabled for the user.
To prevent double MFA prompts (one from Azure and one from ADFS) you will need to change your domain federation settings to the following:
Set-MsolDomainFederationSettings -DomainName -SupportsMFA $true
Once you set this property to true, MFA will happen on-premise and not Azure AD. Interestingly enough, once you set this property true, you won’t be able to “proof-up” in Azure which then won’t allow this feature to work. **I’ve raised this issue with Microsoft and am waiting for a response to how to avoid this issue/provide recommendations on the setup process.
When a user logs in for the first time to Office 365, they will be met with a prompt to setup MFA (I’ve set the SupportsMFA parameter to false and enabled MFA for the user in Azure AD)
I configured MFA to use mobile app notifications. Once you click on “Set up” you will receive a QR code which you can scan using the Microsoft Authenticator app (Work Account). One this is setup now we can configure ADFS 2016 for MFA as the primary method of authentication or secondary. Using MFA as a primary method of authentication is great news―this means you don’t have to use your password.
For my test environment, I’ve setup ADFS with the following configuration:
Now when I login to Office 365, I’m redirected to my ADFS server and you will notice an option at the bottom for MFA Authentication:
Once you click on Azure Multi-Factor Authentication, you will have to then use the verification code from the Microsoft Authenticator app to authenticate yourself to Office 365.
Recommendations:If you already have MFA server installed on your on-premise environment, you can continue to use that with ADFS 2016. I suspect more documentation on this topic will be published before Windows Server 2016 is available to corporate customers which might explain some of the caveats I’ve run into.
本文系统（windows）相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术