Azure MFA – ADFS Infra Overview

This post is part of a series, for the series contents see: Azure MFA

Very quick post to set the scene of the ADFS environment I’ll be building up – nothing fancy just standard ADFS.

ADFS Infra Overview

Essentially the flow will be:

  1. An external user will hit an ADFS proxy server sitting in the DMZ to provide an extra layer of security as middleman between the outside world and the ADFS server itself.
  2. The login request will then be passed through to the ADFS server itself.
  3. The ADFS server will offload username/password authentication to the local AD server (this is the 1st factor of authentication)
  4. It will then offload to the cloud based MFA Auth Provider for the 2nd factor of authentication.

Steps 1-3 have been around for years with ADFS but step 4, the ability to offload MFA to the cloud, is new to ADFS 3.0 on Windows Server 2016.

That’s the simplistic view of what we’ll be achieving but in reality things are a little more complex, due to DNS and SSL cert considerations, which makes the real picture a bit more like this:

ADFS Detailed Infra Overview

The fundamentals you need are:

  • An SSL certificate to secure traffic to the ADFS proxy and to the ADFS server itself.  Usually the same cert on each.
  • Split brain DNS so that when an external user contacts sts.irankon.tk they hit the ADFS proxy whereas an internal user will hit the ADFS server directly.

The flow for an external user will be:

  1. Query external DNS for sts.irankon.tk
  2. That should take them to the ADFS proxy protected by a valid SSL certificate
  3. The user will enter their credentials and the proxy will pass the details to the ADFS server.
  4. The ADFS server then offloads the request to AD to authenticate the user with their username/password.
  5. Finally the ADFS server offloads to the Azure MFA Auth Provider to prompt the user to authenticate using their 2nd factor.  Usually this will be a smartphone app notification from the Microsoft Authenticator app or an SMS message with a code.

For an internal user that flow will be:

  1. Query internal DNS for sts.irankon.tk.  Usually this will be a query to the AD server.
  2. That should resolve and take them straight to the ADFS server protected by a valid SSL certificate.
  3. As the user is internal will have already authenticated against AD (assuming their machine is on the domain) then the first part of the authentication process against AD will happen transparently as single sign-on.
  4. Then, just as for the external user, the ADFS server will offload to the Azure MFA Auth Provider to prompt the user to authenticate using their 2nd factor.

All nice and easy!

A couple of things to note:

  1. For the single sign-on piece:
    • You’ll probably want to setup a proxy exception
    • You’ll also want to add your ADFS URL (sts.irankon.tk) to the local intranet zone in IE.  Group policy might be your friend here.
    • Single sign-on should then just work for browser based authentication but for some apps, such as PowerShell, you may also need to install the Microsoft Online Services Sign-in Assistant. Again Group Policy, or SCCM, will be your friend here.
  2. I’ve used the URL of sts.irankon.tk but you can choose anything you want.  The standard ones everyone tends to use are:
    • adfs.<domain>.<TLD>
    • sts.<domain>.<TLD>   (where sts stands for: “Security Token Service”)

In the next post I’ll get the SSL cert for my lab environment, for free!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: