Using Azure Multi-Factor Authentication With Azure Active Directory and SharePoint 2013
Today I’m going to look at one of the new and interesting security features the Azure team is providing called Multi Factor Authentication (MFA). What it enables you to do is to use a set of services provided by the Azure team for a second form of authentication when a user logs in. The most common example of this is using a text message sent to a mobile phone. When the user logs in, the text message is sent to the phone, and the authentication process is paused while it waits for the user to enter the text message code. This obviously prevents scenarios where a user’s password is compromised in some way – through hacking, theft, poor controls, etc. If the password is lost, access is still denied unless the person has the second form of authentication.
According to its service description, the MFA service is designed to be used with Office 365 tenants, custom apps and ADFS. For this posting, I’m going to describe using it with Azure Active Directory (AAD) and SharePoint 2013 that is hosted on-premises. In this scenario, SharePoint 2013 is like a “custom on-premises application” in the MFA world. I’m going to start where I left off in my SharePoint web app that is already configured to use AAD, as I described in these posts: https://blogs.technet.com/b/speschka/archive/2013/05/10/integrating-sharepoint-2013-with-azure-active-directory-part-1-configuration.aspx and https://blogs.technet.com/b/speschka/archive/2013/05/12/integrating-sharepoint-2013-with-azure-active-directory-part-2-the-custom-claims-provider.aspx. Since there isn’t a ton of documentation on this yet I’m going to try and include lots of pictures so you can see what this looks like in action.
Configuring MFA
So, to begin I’m going to assume you’ve completed the first phase as I described in the blog posts above – you have an AAD instance, and you have SharePoint 2013 already up and running on premise and are using AAD for authentication. The next step is to create a new Multi-Factor Auth provider in the Windows Azure portal. When you do this you will select the AAD instance that it should be associated with, as you see here:
I won’t go into the details of the usage model because you can find the best description of it on MSDN; in short though, the usage model is really about how you want to get billed for your use.
Once you have your provider created you can go in and start configuring which of your users (some of them – all of them – it’s up to you) are going to use MFA. Before you start walking your happy feet down the MFA path though you should be aware of this warning about using MFA that appears on https://technet.microsoft.com/en-us/library/dn394289.aspx:
(the first one) App Passwords required for non-browser clients that do not support second factor authentication: When you enable multi-factor authentication for a user account, a user will be able to use non-browser apps (such as …Outlook etc.) or other installed applications on their computer until they have completed multi-factor enrollment or their account status is set to enforced. The reason is that these clients do not support multi-factor authentication. In order to continue to use non-browser apps (such as …Outlook etc.), you must set up App Passwords for the clients.
(the second one) Please be aware that once multi-factor authentication is enabled for single-sign on (SSO) accounts (federated users), non-browser clients such as Outlook, Lync, Word will not work.
(the third one) Please be aware that once multi-factor authentication is enabled on an administrator account, non-browser clients such as Outlook, Lync, Word , Powershell will not work. For administrators the recommendation is to have an admin account for admin actions and a non-admin account that is used for day to day tasks. You can link your mailboxes for these accounts and use outlook thru the non-admin account. Ensure you create a service account with a very strong password to run PowerShell scripts and not enable that account for multi-factor authentication.
WOW - in its own little double-negative way (I had to read that a couple of times), what it’s really saying is as soon as the user completes the MFA enrollment, non-browser clients won’t work when they try and open secured content. So, you need to be careful and make sure you are just doing this for your browser only clients...and/or be ready to create App Passwords. What are App Passwords (and when do you REALLY need them)? I'll explain that a bit more below.
Now to continue our previous process of getting things set up, you’re now going to configure which users are going to use MFA. Navigating around the MFA administration really occurs in a couple of places and can be a little confusing so let me just call it out for you here:
- If you want to enable or disable users to use MFA: in the Windows Azure portal, click on your AAD instance, then click on the Users tab. When you do that you will see a link at the bottom of the page to Manage Mulit-Factor Auth. Click on that to get a list of users and manage their MFA settings.
- If you want to configure the MFA service itself: in the Windows Azure portal, click on your MFA instance. A Manage link appears on the bottom of the page, then click on it to configure your service, run usage reports, etc.
In this case since we’re working with users, use the first option I described above. One of the nice things about MFA is that you don’t get charged when your global administrators use it. Perhaps they knew that we’re most likely to do our testing with those accounts so they cut us a break. In any case, select whichever accounts you want to use MFA and click on the Enable link to turn on the MFA feature for those users, as shown here:
Once you do that you'll get a dialog informing you that MFA is enabled for all selected users:
Using MFA
Okay, so now what? Well, it's time to log on. The MFA status is currently "Enabled", where it will remain until that account actually tries to log and use their AAD credentials. The first time you log on, you'll be told that your admin requires you to set up the account for additional security verification. You need to start a wizard at that point to go through the process of setting up your second authentication factor.
In the wizard you'll have to select how you should be contacted. I chose mobile phone because it's easiest and what I'm used to, but you could use your office phone and it will use whatever office phone number you have in Active Directory (yet another reason to make sure your dirsync is configured and working correctly with AAD). Once you've authenticated using MFA your account status in the MFA management pages changes from "Enabled" to "Enforced". The only way to get the person out of the MFA feature is to change their status to "Disabled". Here’s the first step in the wizard where each user can decide what they want their second form of authentication to be:
You also have a third option, which is to use "mobile app". The MFA feature in Azure includes a mobile app that can be used with Windows, iPhone and Android phones. In order to use this option, you'll need to have the app installed and then click on the Configure button in the wizard to set up your app.
When you do that you'll get a dialog that appears and has the information you need to configure the mobile app. The easiest option it offers is to just have the app scan the bar code it displays on the screen. In my case it took me a couple of tries to get the dialog to appear, and then a couple of tries to get it to scan the bar code and work, but it amounted to something less than a minor nuisance. Once it's done then you can verify that everything is working and what you'll get is your app just popping up a dialog asking you to verify that you are trying to log in.
If you use the text message option, here’s how it looks as you progress through the wizard. After you’ve completed step 1, it will try and verify that everything is working (click on the picture to see the full image):
When you click the verify now button it sends a text message to your phone:
And then will let you know when it has received the correct response. When you try and log into the site then it will show you this standard UI:
The mobile app option though is by far the easiest and simplest way to respond in a MFA environment because there's no reading text messages and typing in codes - just a simple one click response. I also verified that I could have the app completely shut down, and then tried logging into the SharePoint site. When you do that you get the standard Windows Phone notification (by the way, that picture bottom right is of my most excellent #2 son – Jeremy! :-) ):
You can just click on the notification to launch the app and verify that you are logging in. Very simple, very easy, very nice. If by some chance you happen to miss hitting the notification in time or your phone is off, you can click on the AAD login page on the Other verification options link and then choose any of the methods it list there, including clicking on Notify me on my mobile device link to have it send out another message to your phone again.
One quick point to make about the mobile app. I was a little surprised when I went looking for it in the Windows Phone store because the publisher is NOT Microsoft – it is PhoneFactor, Inc. Just make sure you find the application that looks like this (I typed in azure multi factor in the store search box to find this):
Turning off MFA for a User
As I mentioned earlier, you can always go back in and take a person off using MFA. When you do that, for federated users (i.e. those that have local Active Directory accounts that are synchronized to AAD), the experience is exactly like it was before. When they log in, they authenticate just once to ADFS and they are done. For managed accounts (i.e. those that are created and live ONLY in Azure Active Directory), there seems to be a little confusion on what happens with them if you remove MFA. There has been some suggestion that their password gets reset or some such thing. Well, as it turns out, it's nothing that catastrophic - in fact it's the same experience as federated users have. Their password remains what it was before, but they sign in using only their password instead of having to provide a second factor.
What Are App Passwords?
You can get more details on what they are and the operational requirements for them at https://technet.microsoft.com/en-us/library/cf23280d-97e7-4aed-abbd-ed711ad9337f#apppassword. The summary version of them is this: 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 abled for multi-factor authentication that 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 Windows Azure portal that allows the user to by-pass the multi-factor authentication and continue to use their application.
So all this really means is that your users can get a system-generated app password (they cannot create it themselves) to use for these apps. When they use an app password they are back to using single factor authentication - it's the only thing they need to provide to authenticate. Since the password is static too, you also have a risk that if someone were to lose it somehow - write it down, email it, whatever - that app password could be reused by someone else.
I will also add another caveat here. The use of app passwords really seems more geared towards Office 365 tenants. The reason I say that is because despite the warnings that Office clients won't work when you're using MFA, it actually does in the default installation for an on-premises SharePoint farm. In an on-premises farm, by default, we use persistent cookies. As long as you are using Internet Explorer as your browser, your Office apps can use that same fedauth cookie and grab documents even when you've authenticated to the site using MFA. I've tried it, it works, so things aren't necessarily all bad here.
So, all that being said, if you still want to create an app password you can do so, and I'll defer to the online instructions for doing that at https://technet.microsoft.com/en-us/library/dn270518.aspx. One of the main reasons I'm deferring is because the screen shots it shows do not exist in my tenant at this time. I did have one of the App Password screens show up in a different location - once - so I'm not sure if the feature is still just in preview, the docs are wrong, all of the above, or something else. Here’s what the dialog looks like for your users:
I would say that it's probably not possible to follow all of their recommended practices - most notably not writing the password down. Because the password is system generated it's not likely to be something a user is going to remember WITHOUT it being written down. Here's a screenshot of the App Password that was generated for one of my test accounts; you can decide if your users can remember these without writing them down:
You may notice, ironically that it includes a "copy password to clipboard" option, which makes the whole "don't write it down" thing even more dubious.
Reporting
If you’ve gone this far, users are now using MFA when authenticating and you may wonder how you figure out who’s using it, how much is it being used, and most importantly, how much is it going to cost me? Well the good news is that there are out of the box reports to help you figure these things out. I’ll show screen shots here of a couple of different reports to give you an idea of what you can do; there are actually a number of variables you can plug into each report, as shown here:
Here are samples of the actual reports:
(click on the picture to see the full image)
Wrap-Up
That wraps up this post on using MFA with your on-premises SharePoint 2013 farm. Overall the solution is pretty simple to use and easy to implement. When you get into the documents you will see options for installing the MFA server on-premises and some other more advanced options. The one point I wanted to make is that for all of the functionality I described in this post and showed in the screen shots, I did not have to install anything on my local servers. The only software I installed – because I wanted to try it, not because it was required – was the Windows Phone mobile app for use with MFA. Overall this is really a pretty nice solution, turnkey and ready to go if you need MFA for your on-premises SharePoint farm.
I’m hopeful but not certain that I can dig up an Office 365 tenant I can test and go through this same process with as well. If I can pull that off then I’ll put together another post describing that process and experience.