Azure multi-factor authentication (MFA) cheat sheet.

Originally posted on Lucian’s blog; read at clouduccino.com. Follow Lucian on Twitter @LucianFrango.


Last year I had the pleasure of possibly being one of the first in Australia to tinker with Azure multi-factor authentication tied into Office 365 and Office when ADAL was in private preview. That was a great proof of concept project at the time.

I’m currently working on a solution for a client that’s selecting from one of the Azure MFA options: either Azure MFA Cloud, Azure MFA Server or enabling certificate or token MFA strictly on AD FS 3.0 (the latter is what I had used last year in that private preview proof of concept project at Staples Australia).

Today I want to share two tables that outline information that I brought together from various Azure documentation pages and Office 365 documentation pages to review for the client that I’m working on an Azure MFA solution at the moment. In working out what the imperatives / inputs / requirements for the solution, I found it easier to put everything into a table to visually see what options I could look to for this solution.

Read More

Azure MFA Server – International Deployment

Hi all – this blog will cover off some information to assist with multilingual/international deployment of Azure MFA server. There are some nuances of the product that make ongoing management of language preferences a little challenging. Also some MFA Methods are preferable to others in international scenarios due to carrier variances.

Language Preferences

Ideally when a user is on-boarded, their language preferences for the various MFA Methods should be configured to their native language. This can easily be achieved using MFA Server, however there are some things to know:

  1. Language settings are defined in in Synchronisation Items.
  2. Synchronisation Items can be set in a hierarchy so that settings in the most precedent Synchronisation Item apply.
  3. Language settings set explicitly in Synchronisation Items apply at FIRST SYNC ONLY. Adding, removing or changing Sync Items with explicitly set language configurations will have no effect on existing MFA Server users.

I’ll cover off how to get around item 3 a bit later with non-explicitly configured language settings. To demonstrate hierarchical application of Sync items – first create two Sync Items with different explicitly set language settings as below. I’ve used Active directory OUs to differentiate user locations, however AD security groups can be used too, as can an LDAP filter:

Add Synchronization Item Dialog - Australia

Add Synchronization Item Dialog - Italy

Then set them in the required hierarchy, in this case our default language is English for the Aussies, then we have an overriding Sync Item for the Italians – easy:

Multi-Factor Authentication Server - Syncrhonization tab

The above is all well and good if you are 100% guaranteed that users will be in the correct OU, group, or have the user filter apply when MFA server synchronises. If they are subsequently modified and a different Sync Item now applies, their language settings will not be updated. I’ll now cover how to get around this next.

Use of Language Attributes to control Language Settings

MFA Server has the option to specify a language attribute in user accounts to contain the short code (e.g. en = English) for language preferences. When the account is imported, the user’s default language can be set based on this attribute. Also unlike explicitly configured language settings, when a Sync Item is configured to use language attributes it will update existing users if the language short code in their account changes.

To use this feature, first define an AD attribute that stores the language short code within the Attributes tab in the Directory Integration. Shown below I’m using an AD Extension attribute to store this code:

Multi-Factor Authentication Server - setting Attributes

Then create a Sync Item that covers all your users, and configure “(use language attribute)” instead of explicitly setting a language – it’s the last item on the list of languages so unless you’re Zulu it’s easy to miss. By the way, those are the short codes for the language attribute for each language listed in this drop down list. Once user accounts have been configured with the language short code in the specified attribute, on next sync their language will be updated.

Edit Synchronization Item Dialog

Other Stuff to Keep in Mind

When dealing with international phone carriers, not all are created equal. Unfortunately, Microsoft has little control over what happens to messages once they’re sent from Azure MFA Services. Some issues that have been experienced:

  1. Carriers not accepting two way SMS, thus MFA requests time out as user One Time Password responses are not processed.
  2. Carriers not accepting the keypad response for Phone call MFA, again resulting in MFA request time out.
  3. Carriers spamming users immediately after SMS MFA has been sent to users.
  4. Users being charged international SMS rates for two-way SMS (makes sense, but often forgotten).

In my experience SMS has proven to be the least reliable, unless the Mobile MFA App/OATH can be used Phone is the better method for International users.

Often overlooked is the ability to export and import user settings using the MFA Server Console. You can export by selecting File/Export within the console. The CSV can then be updated and re-imported – this will modify existing user accounts including MFA Method preference and language defaults.

One Last Thing

For Apple iPhone users, Notifications must be enabled for the MFA Mobile App as the App will fail to activate with a timeout error if Notifications are disabled. Notifications can be enabled in iOS via navigating to Settings/Notifications/Mulit-Factor and enabling “Allow Notifications”. Changing this setting can take a little while to apply, so if the Mobile App still does’t activate after enabling Notifications, wait a bit then try again.

How to implement Multi-Factor Authentication in Office 365 via ADFS, Part 5, the finale!

Originally posted in Lucians blog over @ clouduccino.com

I know what you’re thinking: does Lucian really have to create another part in this long MFA series? In short, probably not, but I’ll have saved your index finger the thousands of years or scrolling you would have done to read the entire brain dump in a one page post.

So to explain this ‘epilogue’, if you will, on MFA, using X.509 SSLs for your second factor of authentication is a powerful means to automate and manage a process for your mobile and external users. This blog post will explain how to leverage an on-prem Microsoft System Centre Configuration Manager (SCCM) 2012 R2 deployment linked to Microsoft InTune to deliver SSL’s to mobile and external devices to use in MFA.

Read More

How to implement Multi-Factor Authentication in Office 365 via ADFS – Part 4

Originally posted in Lucians blog over @ clouduccino.com

The final installment in the long series that’s taken me allot longer to get around to writing then initially I had thought. However, I hope it’s worth the wait and the solution that has been proven works well for you. Before I get into the technical aspects of the final piece of this MFA implementation puzzle, I’d like to make a quick shout out to all the awesome consultants at Kloud Solutions who helped both in the technical implementation but also with the initial design and work required to see this solution through- a big thank you!

In the previous blog post I went through essentially what an internal configuration of MFA would look like with everything ready for the ADAL component that was previously under NDA and preview only availability, is now generally available for testing. So let me quickly delve into that ADAL in Office 2013 and Office 365 component before an in-depth guide on how to utilize Microsoft InTune and System Centre Configuration Manager as a means to deliver SSL certificates to users and use those certificates as your second factor of authentication! Exciting as its been a long build up to get to this point with several moments where I was questioning whether this would work in the real world.. lets start..

Read More

How to implement Multi-Factor Authentication in Office 365 via ADFS – Part 3

Originally posted on Lucian’s blog over at clouduccino.com.

In this blog post I’ll go into the configuration and implementation of Active Directory Federation Services v3.0 Multi-Factor Authentication (MFA). This is in line with a recent proof-of-concept project I conducted for a large customer in the FMCG sector. ADFSv3 MFA coupled with some new functionality that Microsoft is working on in Office 365, MFA in Office 2013 which will be covered by part 4 of this series, offers a fantastic solution to organisations wanting to leverage MFA by way of adhering to company policy or simply to further secure their users accessing Office 365 cloud services.

The good we secure for ourselves is precarious and uncertain until it is secured for all of us and incorporated into our common life

-Jane Addams

Read More

How to implement Multi-Factor Authentication in Office 365 via ADFS – Part 2

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

How to implement Multi-Factor Authentication in Office 365 via ADFS – Part 1

Originally posted on Lucian’s blog: clouduccino.com

This is part 1 of a 4 part series put together exploring Multi-Factor Authentication (MFA). Recently I’m been working with a client on a project to implement MFA for Office 365 services as company policy mandates at least two factors of authentication (2FA) for accessing any corporate resources.

In part one I’ll put together my points of view around what MFA is, why its an important topic for organizations especially in 2015. In part two I’ll explain what the main MFA types are around Office 365 and Azure and their use cases as each has different features and each can impact different aspects of implementations. In part three i’ll explain how to implement MFA in organizations that utilise ADFSv3.0 integration with Office 365, and finally in part four provide an in depth how to for the latest currently “in preview” feature of Microsoft Office 2013- MFA utilising Active Directory Authentication Library (ADAL) that was only made available for preview in Q4 of 2014. This is exciting cutting edge stuff that will no doubt be a standard configuration item for existing and new Office 365 customers by the end of 2015.

Lets kick things off with the background of MFA and set the foundations of the posts to come…

What is multi-factor authentication (MFA)?

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.

What this means in a nutshell is when you logon to your Office 365 Outlook Web Mail web client, along with your username and password combination (something you know), you are required to also enter an additional means of authentication like a one time token (OTT) (something you have).

To finally expand upon that, we have the most basic of MFA concepts where everything can be summed up in three key scenarios of something you know, something you have and finally something you are. This philosophy of authentication ensures that its virtually impossible to beat the system when up to all 3 factors are enabled.

 Why does it matter to my organization?

More and more organizations are moving to the cloud. Key services like email through to line of business applications used by accounting are ending up in a cloud. With that comes some risk; of data being compromised and ever more likely: user credentials being compromised. Systems able to be implemented like CloudLink SecureVSA, available in Microsoft Azure, keeps data at rest encrypted and secure, meaning not any old user can access raw data and compromise corporate intellectual property. The most common way to compromise applications, cloud services or systems as I mentioned earlier is through user credentials. Your username and password have kept your work and your access to systems and applications secure for the most part since the invention of computer systems.

Fast forward through to modern day cloud centric IT. A world where you have an increasing amount of the workforce using any number of cloud service or cloud application. For the security conscious and those in the positions to make the decisions to keep the rest of the organisation secure, this was a headache. I say was because with an ever growing number of cloud users, cloud providers are coming up with better ways to secure thier services. In some ways Microsoft are leading the charge. Of Course other providers like Amazon Web Services (AWS) have MFA services of their own, the potential of MFA use in both Microsoft’s Office 365 and soon Office 2013 has much greater impact.

Why is 2015 going to be a big year for MFA?

Through various reading, Googling and background I have on the subject matter, it seems to me that coming off some strong development work in 2013 and 2014, the year 2015 will be the year that MFA goes mainstream: beyond just securing your bank account (through the use of SMS one time pass-codes (OTP)) and into virtually all enterprise and even standard cloud services as well as thick applications like Microsoft Office.

By far the most popular enterprise and business operating system is Microsoft Windows. Then the most popular workforce application suites are found in the Microsoft Office product stack. Why are these relevant in the cloud world and in the year 2015? Well, put simply, both are from Microsoft and both will feature strong MFA functionality with integration to key cloud services, again from Microsoft, Azure and Office 365.

Microsoft Windows 10

Microsoft announced that WIndows 10 will tie in with Azure Active Directory (AAD) allowing for organizations to be born in the cloud. This is big news especially in relation to MFA where Windows 10 will be the first operating system to feature MFA integration. This point isn’t that much of a talking point in this series, but definitely one of the reasons why 2015 is going to be a big year for MFA. Its something I’m definitely going to get stuck into once Windows 10 becomes generally available.

Microsoft Office 2013

Announced by Microsoft almost a year ago but not able to be publicly used or tested until late 2014, the Microsoft Office 2013 suite will feature MFA integration very soon. Currently available through the connect.microsoft.com in preview testing service, MFA in Office 2013 will likely be many organizations first step towards widespread MFA adoption.

The MFA integration of the Office 2013 suite centres around some key applications that will either talk to ADFS or Azure AD/Office 365: Microsoft Outlook, One Drive for Business and of course Lync. The process itself enables the Office 2013 clients to engage in browser-based authentication (also known as passive authentication). Again put simply, an authentication window will pop up during the logon process requiring the user to enter in additional authentication mechanisms that you as an administrators set.

2015-01-30-MFA-01

Outlook 2013 with ADAL MFA enabled and highlighted

Check out the original article at Lucian’s blog here: clouduccino.com