MSExchangeGuru.com

Some of you might have Azure MFA implementations and select few of you might have a requirement to deploy the Azure MFA server on your on-prem for multiple reasons. One such would be to use Azure MFA with AD FS – for instance you want to secure your Outlook WebApp behind AD FS and MFA.

If you haven’t heard about the features and functionalities of the new Windows Server 2016 is AD FS 4.0. A much needed refresh and revamp of one of the most popular technologies which is being adapted at many enterprises at blistering speed. Now, this AD FS 4.0 also introduces Azure MFA Adapter which do away with the requirement of having an on-prem Azure MFA server for first and second factor authentication.

I’m not going to detail on how you could deploy one in your organization (if you’re interested, find out how) but would happy to explain why not you need one at this point.

Recently, I was looking into enhancing the MFA capabilities of our on-prem AD FS server to secure applications federated with our Azure Directory using Conditional Access for MFA. We already have a third-party provider but was hoping

1. To integrate the third-party provider with AD FS authentication thereby securing our applications behind the third-party’s MFA and
2. To provide a seamless migration path from our current third-party provider to Azure MFA which comes as part of our subscription.

Options we had on the table were two;

1. On-prem Azure MFA server which can integrate with our existing on-prem AD FS 3.0 (running on Windows Server 2012 R2) or
2. Windows 2016 server with AD FS 4.0 with an inbuilt capability to use Azure for Second or even first factor authentication.

Option 1 was a tried and tested method – been around for what it appears to be for ages (I know…); build an on-prem Azure MFA server, install the MFA adapter on the AD FS server and find another box to deploy the user portal to publish it on the internet and integrate the whole thing with on-prem Active Directory (Again, not going to detail on how you can do that which is already explained here). Our 3rd party vendor also had their own version of MFA Plugin that we could install on our AD FS server. When a user attempts to access an application secured by Conditional Access, he/she will be directed to AD FS server for authentication (oh, and read a bit more on SupportsMFA switch for sure at this point). The AD FS server after performing the first level authentication with the directory, prompts the user to choose a MFA provider (if you have multiple adapters installed/enabled) or prompts for the MFA authentication (if you have only one of MFA adapter enabled). Easy peasy lemon squeezy right?

We attempted to venture into the unknown territory of AD FS 4.0. After spending hours of our time to deploy AD FS 4.0 and attempting to integrate it with Azure MFA, I thought I’m bound to say a few words on what you probably might have not heard yet…

1. For starters, it’s not clear if you could use the Azure MFA adapter unless all the servers in the AD FS farm are running AD FS 4.0. Turns out, not. What does it mean: If your infrastructure has AD FS 3.0 on the same farm, you can’t see the AD FS adapter. Logical isn’t it? It’s only fair to say that all servers should be at a minimum supported level for a new feature to work. But by mistake, if you happen to deploy your new AD FS 4.0 as a member of your new farm or not keen on spending more for a new certificate, lo-behold and you could still make it work your way!
   1. Add the AD FS role on your Windows Server 2016 and complete the configuration wizard like you’d normally do on a Windows Server 2012 R2 server when you want to add an additional server in the farm. If you want to add more Windows Server 2016 to your farm, do just that.
   2. Run the following command

      Set-ADFSSyncProperties -Role "PrimaryComputer"

      on one of your new Windows Server 2016.

   3. Run the following command on all the other servers in the farm

      Set-ADFSSyncProperties -Role "SecondaryComputer" -PrimaryComputerName "FQDN of your new Primary AD FS 4.0 Server"

      Do that on all your pre- AD FS 4.0 servers as well. A reboot is not essentially required but would speed up the sync process. And allow 15-30 minutes before proceeding to the next step. You could confirm if the sync is successful by running Get-ADFSSyncProperties on your secondary AD FS servers.

   4. At this point, you’d really want to add the IP addresses of your new servers to your NLB if you have any. And to the DNS resolution of your perimeter server (commonly done on DNS if it is a split DNS or at Hosts file) and remove the references to the old server
   5. Shut down all your Windows Server 2012 R2 servers – They are probably not required anymore but save them for a while before you decide to throw them away.
   6. Login to your new Primary AD FS server and run the following command:

      Invoke-ADFSFarmBehaviourLevelRaise

      This upgrades all the servers in the AD FS farm to native mode and kicks out any older AD FS 3.0 or below out of the farm. Your Windows Server 2012 R2s are not completely useless at this point; wait!!!

   7. (Optional) Really do it as the last step of your migration; if you want to upgrade all your AD FS WAP too, then wait till you finish reading the article. But if you can’t really be bothered, build new WAPs just like you normally do and run

      Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion

      But for some odd reasons if you decide to go back to your Windows Server 2012 R2 BEFORE you implement step 7, then all you got to do is run command on Step 2 on your old Windows 2012 R2 servers (they are powered off, remember?). And run the step 3 on your other servers in the infrastructure but be sure to replace the FQDN appropriately. Don’t forget to update your NLB configuration.

2. Most of the Windows Server 2016 AD FS 4.0 documentation is still a work-in-progress. For instance, you may be following this article that I already quoted earlier but might have hit the following page on AD FS login:

Additionally, you may also have an Event ID 364 in your AD FS Admin Logs (or your AD FS Roles)

Log Name:      AD FS/Admin

Source:        AD FS

Date:          00/00/2017 12:00:00 PM

Event ID:      364

Task Category: None

Level:         Error

Keywords:      AD FS

User:          CompanyAadfsServiceUserAccount

Computer:      ADFSName.CompanyA.com

Description:

Encountered error during federation passive request.

 

Additional Data

 

Protocol Name:

wsfed

 

Relying Party:

urn:federation:MicrosoftOnline

 

Exception details:

System.Exception: Exception calling SAS. —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)

   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)

   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)

   at System.Net.ConnectStream.WriteHeaders(Boolean async)

   — End of inner exception stack trace —

  

The key out of the whole geeky stuff is the underlined line. If you’ve been following the link, you would know that you are generating an Self-signed SSL certificate for communication. You might have logically expected it to be trusted but in reality, that doesn’t happen automatically. So, you’d have to manually export the certificate and import it into the Trusted Root authorities manually (without the private key) and you’ll be ready to hit by the next reality…

3. It doesn’t work the way you expect it would…

Sorry to keep your hopes so high and drag you all along. Now, the major flaw with the whole process is that the user enrollment/registration piece. You’d expect that to happen at Azure but when you set the SupportsMFA switch to $True, you’re effectively telling your Azure AD tenant that you have a server on-prem capable of doing MFA for them. But when you hit the AD FS server, you’ll pass the authentication with flying colours if the user is already registered. But if not, the user is going to get a sad page saying

 

 

This is because, according to Azure AD, the user is technically not registered for MFA (but is forced to) and AD FS does not know how to redirect the user to complete the registration. According to Microsoft, this is a know issue which is expected to be fixed in the future releases of MFA portal for the end users and Windows Server 2016 MFA Adapter. Until then, hold fire…

You see why I did ask you to leave your good old Windows Server 2012 R2? 🙂

But even if you have already deployed the 2016 servers, no harm in keeping them but just disable the MFA adapter until this is sorted.

4) There is certainly a 4th reason too. Many may not impacted but very handful few would – have you heard of AlternateLogonID? It is not supported on Azure AD FS MFA Adapter yet. Not sure if there would be a support in the future but you might be quite happy to know that it all works with an on-prem AD FS server.

And the good news is, Azure MFA server works with Windows Server 2016 too..

I’ll update this post in case if I hear anything positive at all, but until then chill and speak to you all soon 🙂

-Muthu

Edit 1: Microsoft’s article referenced above now carries the following disclaimer:

AD FS does not currently support inline proof up (registration) of Azure MFA security verification information. As a result, when a user who has not yet registered (configured verification information) in Azure AD tries to authenticate with Azure MFA at AD FS, they will get an error. While we are working to add inline proofing functionality, the following are the recommended configurations for enabling Azure MFA with AD FS.

Edit 2: Corrected few typos about the server versions (Sleepy me might have typed 2008 in few places instead of 2012  – honestly, was on short dosage of caffeine that day after a long day). One of our subscriber – Ivan pointed it out in the comments and I now stand corrected. Although the article is written on how to upgrade AD FS farm on Windows Server 2012 R2 to Windows Server 2016, the process is pretty much the same for a Windows Server 2008 R2 to Windows Server 2016.

Posted March 23rd, 2017 under Uncategorized. Tags: AD FS, AD FS 4.0, Azure, Azure AD, MFA, MFA Gotchas, Windows Server 2008 R2, Windows Server 2012, Windows Server 2016
RSS 2.0 feed. Leave a response, or trackback.