Originally posted on Lucian’s blog: clouduccino.com
Welcome to part 2 of this 4 part series on Multi-Factor Authentication (MFA). In this post i’ll go into some of the different types of MFA available to federated users with either Office 365, Azure AD and hybrid configuration Active Directory Federation Services (ADFS) v3.0; as well as some use cases for each of these.
Quick recap – Multi-factor authentication (MFA) is a means of access control whereby during the logon process, there is more than one claim to grant you access to the cloud service, server application or even workstation. As with any information technology infrastructure, there is always more than one way to do something which is both a positive and a negative. To explain that oxymoron (and no that’s not me) sometimes having choice is not always a good thing in that it can create headaches for infrastructure consultants or system admins as choosing the correct implementation, in this case MFA, to achieve your end goal can be one of two or several choices. So lets compare the options and go through the 3 main MFA options, as well as a 4th that’s technically available, but not relevant to what this blog series is intending to achieve.
Azure Administrative MFA
The first service offered by the Microsoft Cloud is Azure AD Administrative MFA. This MFA service is available to the Azure AD administrator(s) and only the administrators not general users. It allows your core Azure admin account or accounts to be more secure by way of enabling MFA at no additional charge to your subscription. This is highly recommended, as you would imagine, because Microsoft have your credit card details. Spinning up tens or hundreds of services will potentially cause a massive bill for the unsecured. Protecting the core admin account(s) at all times is a must and should be part of your Azure administrative strategy along with things like admin roles and/or RBAC etc.
Azure AD MFA
The second piece of the Microsoft Cloud MFA puzzle is similar to administrative MFA for Azure. However, where administrative MFA for the admin accounts / roles in Azure, the Azure AD MFA service is available to all Azure AD users. This is one of the main benefits in upgrading your Azure AD subscription from basic to Premium. Azure AD Premium is an additional monthly charge but offers additional features and benefits not just MFA. In addition to the Azure AD Premium upgrade, there is also a fee for the MFA service itself. Optional in two flavours, charged per user or per authentication, securing your cloud resource can incur quite a bit of OPEX if not analysed carefully. Azure AD MFA additionally features an MFA server (role) that can be deployed on an on-premises Windows Server 2012 instance or optionally in Azure IaaS that facilitates the MFA requests.
Office 365 MFA
As most customers of the Microsoft Cloud utilise Office 365, Microsoft have enabled MFA as an included service to Office 365 SKUs. Similar in service functionality as Azure AD MFA, only that theres no server role, Office 365 MFA can in most cases by the first introduction to MFA to most organisations. Its enabled with a couple of optional changes on a per user basis as its globally available on your tenant.
Active Directory Federation Services (ADFS) v3.0 MFA
Finally, we have an MFA option that when talking Microsoft Cloud most don’t consider but can be quite powerful especially in a certain use case (i’ll get to later). With the introduction of ADFS v3, MFA is available to be configured on a per user, per security group, per inbound, per outbound, per internal or per external connected user; meaning lots of options and lots of configuration to meet various requirements. This type of MFA is what the remaining 2 parts of this post series discusses as from a recent engagement I’ve found it ADFSv3 MFA is a great solution when used in conjunction with some in-preview Microsoft services to Office 365 / Azure AD (again i’ll explain shortly).
Use cases: which MFA suits what purpose
Below is a brief outline of some of the possible use cases for the different types of MFA in a little more detail compared to some of the overview mentioned above.
Azure Admin MFA
The use case of MFA for your Azure administrator roles is more or less a given. Its a best practice that should be adopted by anyone that has an Azure subscription. Enabling it simply and only provides additional security for your highest level accounts who have the potential as administrators of the subscription to not only spin up and down services but to also add and remove administrator accounts.
Azure AD MFA
Azure AD MFA extends the security of the Azure subscription to any users added / enabled in Azure AD Premium. When dealing with Azure AD Premium, most often than not the customer size is a large enterprise. Security and data integrity at enterprise scale is of the utmost concern with competitors wanting that information, users accessing services with passwords like “password”, and a whole raft of vulnerabilities.
Enabling MFA on Azure AD Premium enforces MFA for any service residing on or authenticating to Azure ADP. Office 365’s backend AD is Azure AD, so enabling this feature extends MFA not only to accessing services in Azure, but to Office 365 as well. As you can see this is quite powerful.
Implementation is likely ideal for an organisation wanting to secure all services in the Microsoft Cloud with MFA with granular administrative policy and governance. As Azure AD MFA utilises a server role, theres many options and settings for astute administrators to ensure high levels of security.
Office 365 MFA
What i’m tipping to be the most commonly implemented form of MFA is simply enabling MFA on your Office 365 tenant and use accounts. Following on from the in-preview ADAL enabled Office 2013 clients, Office 365 MFA is one of the quickest to implement and lowest administrative overhead MFA solutions available in the Microsoft Cloud. The use case is a simple one and by the end of 2015 most if not all Office 365 customers will likely implement as the days of passwords keeping out the bad guys are long gone.
Active Directory Federation Services (ADFS) v3.0 MFA
Finally the dark hose, the underdog and likely the most overlooked means of MFA is ADFSv3 MFA. While it still is a new feature enabled in ADFS v3, many administrators have overlooked its potential as other aspects required to fully utilise this have not been made available from Microsoft.
Come November 2014 when updated authentication enabling MFA was introduced into Office 2013, many a infrastructure consultant and Kloud (where I work) thought of interesting ways this could come into play. Interesting solutions that can leverage the MFA types. Once such use case is with ADFSv3 MFA (this was what i was referring to when i mentioned “ill explain shortly“).
During a recent engagement for a large customer, their “MFA practice” consisted of enforcing users that access any cloud resources and/or any corporate resources to VPN connect to the corporate network. While this doesn’t align with the core principles of MFA, it does provide a level of additional security while also providing additional headaches and frustrations for users.
What i’ll discuss in part 3 is how to leverage ADFSv3 MFA and specifically X.509 certificates issued from an internal enterprise certificate authority to provide users with MFA capabilities. There are a number of “moving parts” and requirements but the end result provides a seamless and functional MFA solution that doesn’t impact as much as say Office 365 of Azure AD Premium MFA whereby a physical act of authentication is required: text message, phone call etc.
MFA implementation Prologue
So part 3 is a deep dive, as much as possible, in how to use ADFSv3 MFA with Office 2013 ADAL updates. However, part of (the ADAL piece) what i’ll discuss in more detail is restricted by an NDA from Microsoft. I’ll explore in as much detail as possible how to leverage this fantastic solution for MFA that gets little fanfare but but overall can provide a streamlined (I won’t say seamless) experience for users completing multi-factor authentication.
Check out the original article at Lucian’s blog here: clouduccino.com