Since the great announcement of Office 365 Multi-Factor Authentication (MFA) (sometimes called 2FA or 2 Factor Authentication) being made available to (nearly) all Office 365 subscribers for FREE, we have been working with some of our clients on achieving the right balance of security versus usability and practicality.
This post covers some of the implications in adopting an MFA strategy, for end users and for administrators.
If you want to know more about what MFA is, this technet article is a good start.
Setting up MFA
This is covered in the above link and also well-documented in this technet guide so no need to repeat here.
There is a lot of other good information about the various options in the above article e.g. the SKU’s to which MFA is applicable (generally Enterprise, Academic and Nonprofit plans).
Implications
Client Limitations
The main thing to consider about the setup of MFA is that your users, whether standard users or administrators, will be affected and need to enter a 3rd piece of information (in addition to username/password) to authenticate themselves via the web.
This fundamental MFA element means that as many client applications (almost all!) have only been designed for a traditional username/password scenario, they have have no possibility of entering this key 3rd piece of information.
To get around this issue, Microsoft has introduced App Passwords:
Non-browser apps, such as Microsoft Outlook and Microsoft Lync, currently do not support multi-factor authentication. Multi-factor authentication is enabled per user. This means that if a user has been enabled for multi-factor authentication and they are attempting to use non-browser clients, such as Outlook 2013 with Office 365, they will be unable to do so. An app password allows this to occur. An app password, is a password that is created within the Azure portal that allows the user to by-pass the multi-factor authentication and continue to use their application.
Some clients which exhibit this problem include:
Microsoft Office
Yes, even Outlook, Word, Excel, Lync etc. only have support for a username/password.
Users will need to have an App password for Office to work.
iOS & Other ActiveSync/Email Clients
To authenticate against Office 365 an App password is required.
PowerShell and Global Administrator Implications
This is an important consideration for Global Administrators; you cannot get PowerShell access to Office 365 with an account that has MFA enabled.
The App Password solution is likely not sufficient for your global administrators as it bypasses MFA so is not as secure.
I would recommend that Global Administrators have no App Passwords (e.g. using a privileged account, which is separate from their standard account).
To get around the PowerShell issue, the Global Administrator would need to have a second Global Admin account just for PowerShell, which is ordinarily disabled, and only enabled when performing administrative tasks. Also as already mentioned the MFA-enabled administrator account should have NO app passwords.
App Passwords
As described above, many apps simply can’t cope with MFA hence the App Password “solution” – this has some interesting implications:
Multiple Passwords
For end users (probably the only users that should have app passwords) they will need to have at least one and maybe more passwords; the auto-generated app passwords are also not user-friendly.
It is possible to have up to 40 app passwords… although quite why you would need that many is beyond me!
Password Reset
Imagine if you did have 40 App Passwords (I’ll give this a go for my devices: Outlook, Office (Word/Excel/etc.), Windows Phone, iPhone, iPad, Nexus 7, 2nd PC with Outlook, Office… ok that’s 8 for me…) and your information security team is insisting on a 14 day password expiry policy… you have to change all passwords on all devices and they are all different… nightmare!!
Or not… actually, what happens is every time your main password is updated, the list of your app passwords gets a new “Date Created” stamp, without actually changing it!!!
Before main password change (I had just enabled MFA on 5/13/2014 – US date format):
After main password change (note the date!):
This presents another dilemma in terms of security – increased security via the web, but apparently reduced security for client applications and peripheral devices having the same password. Forever. Even if you forget your main password and need to have it reset, the app passwords do not get reset.
I have to assume that the assumption behind this is that needing to change ALL your auto-generated App Passwords periodically along with your main password would have prevented this from being a practical solution, and that it has been assumed (lots of assumptions here!!) that if you are logging in to change your main password, that you would be able to delete an app password for any missing or compromised devices or apps at the same time… big assumption (again) that users would be actually do this.
Another implication is that if you have a short password expiry period, MFA is probably a good thing from an end user’s perspective – as they don’t need to change their app/device passwords (ever!) however with MFA in place, you likely don’t need to enforce a short password expiry due to MFA itself!
Any end users with multiple devices will appreciate the fact that they don’t need to update all those devices and clients with their new password each time it changes as the App Password doesn’t expire.
Summary
It’s far from a no-brainer; the balance of usability and security that is right for your organisation should take into account the implications listed above.
Another minor implication is cost – it’s free as far as Microsoft is concerned but some of our clients with travelling/roaming employees have incurred roaming SMS charges.
Hope this helps clarify to some extent – happy to continue the discussion in the comments below, let me know how it’s worked for you (especially if you have a PhD in Risk Analysis 
)
Gus
Leave a Reply