다음을 통해 공유

Azure Multi-Factor Authentication – On Premise

  • 아티클

Microsoft is smart when offering such multi-factor cloud service. The MFA service is planned to work and integrate with most if not all of your applications on premises. The way to achieve that is to introduce a level of abstraction between the application that requires multi factor authentication and the Azure cloud services. This abstraction is achieved by deploying a small server role called the Azure Multi Factor Authentication On Premise Server [ I will refer to this server as the MFA server]

​

Think of the MFA server as an end point that listen from one side to your applications, and communicate from the other side with Azure multi factor authentication services using https. On premise applications can communicate with the MFA server using many protocols and ways. For example, you can configure your VPN server to use the MFA server as the RADIUS server, and in this way, you would have a multi factor authentication to your VPN clients right away. MFA server usually connect to your Active Directory to pull the mobile number for your users, or you can supply this info manually. The MFA  server will then communicate with the Azure services and supply the mobile number along with the user name.

Note: Typically, MFA server is joined to your domain, but it does not need to be.

MFA server acts as a proxy between your applications that need two factor authentication, and the Azure multi factor authentication services. It also contains two portals:

  • Mobile App Portal, that is used to enable mobile app authentication.
  • Self Service Portal, that is used by users and administrators to manage their multi factor authentication profiles.

So what really happens here? Your application will use the MFA server as the authentication server using for example RADIUS or LDAP, the MFA server will connect to your AD to verify that the username and password are correct. The MFA server does not store user passwords. If and only if the username and password are correct, then the MFA server will try the second factor authentication by connecting to the cloud server, passing the information needed to perform the second factor authentication. MFA passes these information to the cloud service each time and every time during the second factor authentication. This is because Microsoft does not store the phone numbers and users in the cloud. In the case, Microsoft does not know or store anything about your users or their info, neither their passwords.

Azure cloud services only uses the information passed by the MFA server ( example is user phone number), and they place the phone call, send the SMS or send the push notification to the mobile app, and then send a rejection or acceptance response back to the on premise MFA server.

If the MFA server is used as a RADIUS server, it can act as a RADIUS server, where it will check the username and password with a directory service like AD, or it can act as a RADIUS proxy, where is proxy the request to another RADIUS to do the primary or first authentication.

If the MFA server is used as LDAP server, then it acts as an LDAP proxy completely by redirecting the LDAP query to a backend LDAP server for the primary authentication phase.

If you have IIS server you want to secure, there is IIS plugins where the request to the web page is intercepted by the MFA plugins. The plugin will authenticate the user using multi-factor authentication. If the authentication did not work, the plugins will send a denial page back to the requester. I guess that for this to work, you have to install the MFA server in the IIS server itself.

Another option would be integrating with RDS and VDI, although at the time of writing this blog, there is some issues with Windows 2012 R2 RDS integration with MFA. You can always hock up MFA to the RDS gateway as a workaround and everything will work fine.

When the MFA server sends a request to the Azure services for a second factor authentication, the following options are available:

  • If the user is configured with MFA profile with a phone call preference, then the MFA on premise server will send the mobile number of the user to Azure cloud services. MFA on premise knows about the user mobile number either by going to Active Directory, or by the administrator configuring a one to one mapping between each user and his mobile number inside the MFA console.  Now Azure will take this mobile number and try to call the user, asking him to press the # key, finishing by that the authentication cycle.
  • Same applies if the user is configure with MFA profile with SMS preference. Instead of a phone call, the user will receive an SMS with a code that he needs to reply to.
  • If the user is configured with MFA profile with a mobile app preference, then the MFA server will send some information to the cloud service that will send a notification to the user’s mobile app. The mobile app then will connect to the on premise MFA published services to complete the verification cycle.

Cloud Apps?!
What if you have a cloud apps that are federating to on premise federation service?  Well, if you are using anything beside Microsoft ADFS, then RADIUS or LDAP can be used to integrate to the on premise federation services.
On the other hand, if you are using ADFS 2.0, the MFA can integrate on the federation proxy as IIS plugins by installing the MFA on the federation proxy, and the plugins will intercept the request coming in and perform the two factor authentication.
If you are using ADFS 3.0 and higher, there is the extensible MFA available. MFA has an adaptor that can be installed on ADFS and configure the policy in ADFS to use that adapter.