Tag Archives: azure mfa

Common questions using Office 365 with ADFS and Azure MFA

Azure Multi Factor Authentication (MFA) is a great service that has been included in Office 365 for almost 2,5 years. The adoption has really been great – at least from an admin user perspective where 99% of my customers admins have it enabled (I usually force them).
From an end user perspective we have more technical and informational challenges, which means that the adoption has not been as great as on the admin side. Hopefully the new shiny Conditional access policies for specific workloads will boost the adoption a bit.

The purpose of this post is to share the most common questions I get from customers about using Azure MFA included in Office 365 (in most cases in combination with ADFS).

Q: Can we pre-stage the MFA authentication methods so the end user doesn’t have to enroll after being enabled for MFA?
A: As of now, unfortunately no – I tried to build a PowerShell function to pre-populate the authentication methods if the user already had a mobile phone number. I was fooled and thought it worked, but when I tried on a user that never had enrolled MFA before, it failed. Troubleshooting further, the required MFA property “StrongAuthenticationUserDetails” is not possible to pre-populate programmaticly, yet. Maybe the new AzureAD module can help here in the future.
Conclusion – we have to instruct our users to enroll for MFA.

Q: Can we prevent MFA from kicking in when authenticating from our internal network?
A: Absolutely – There are some options depending on if you have Azure AD Premium or not.

With Azure AD Premium
Here you can choose to “white list” your external IP addresses (which of course works with or without ADFS), or check the “Skip multi-factor authentication for requests from federated users on my intranet” checkbox. This will make Azure AD decide about MFA based on the insidecorporatenetwork claims issued by your own ADFS.
The following PowerShell rows will add the required Issuance Transform Rules to your Azure AD RP.

$ByPassMFAClaims = @"
@RuleName = "Passtrough - InsideCorporateNetwork"
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"]
 => issue(claim = c);

@RuleName = "Passtrough - PSSO"
c:[Type == "http://schemas.microsoft.com/2014/03/psso"]
 => issue(claim = c);
$AzureADRP = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform" 
Set-AdfsRelyingPartyTrust -TargetName $AzureADRP.Name `
                          -IssuanceTransformRules ($AzureADRP.IssuanceTransformRules + $ByPassMFAClaims)

Without Azure AD Premium
Without Azure AD Premium we don’t have the same choices in service settings.
We can however achieve the same result, but instead of passing through the insidecorporatenetwork claims, we use it in ADFS and “tell” Azure AD that MFA is already taken care of. This can be done with the claim rules as below.

$ByPassMFAClaims = @"
@RuleName = "Bypass MFA from inside - Without Azure AD Premium"
EXISTS([Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"])
 => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsreferences", Value = "http://schemas.microsoft.com/claims/multipleauthn");

@RuleName = "Passtrough - PSSO"
c:[Type == "http://schemas.microsoft.com/2014/03/psso"]
 => issue(claim = c);
$AzureADRP = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform" 
Set-AdfsRelyingPartyTrust -TargetName $AzureADRP.Name `
                          -IssuanceTransformRules ($AzureADRP.IssuanceTransformRules + $ByPassMFAClaims)

Q: Do we really need to use the f****** app passwords?
A: Not really anymore, at least not if you are using ADFS. I usually turn it off.
First of all most rich clients (Including Outlook/SfB on mobile devices) do now support Modern Authentication (ADAL), which means they can handle MFA out of the box. So as long as you have updated clients, you most often only need to handle ActiveSync (native mail clients in all kinds of devices). My approach here is usually to exclude them from MFA to get rid of the app password need, but enable conditional access in order to control the devices.

Below you find a claims rule for the ActiveSync protocol that issues the multipleauthn claim which Azure AD will honor by skipping MFA for the request.

$Claims = @"
@Claims= "Bypass MFA for ActiveSync"
EXISTS([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value=="/adfs/services/trust/2005/usernamemixed"]) && 
EXISTS([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~"^(Microsoft.Exchange.(Autodiscover|ActiveSync))$"]) 
=> Issue(Type = "http://schemas.microsoft.com/claims/authnmethodsreferences", Value = "http://schemas.microsoft.com/claims/multipleauthn"); 
$AzureADRP = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform" 
Set-AdfsRelyingPartyTrust -TargetName $AzureADRP.Name `
                          -IssuanceTransformRules ($AzureADRP.IssuanceTransformRules + $Claims)

Please note that additional rules may be needed depending on if you have an Exchange or Skype for Business Hybrid environment.

Q: Can we combine Azure MFA with our already implemented on-premises MFA solution?
A: It works fine to combine Azure MFA with any MFA solution that integrates with ADFS. The only thing you need to do is issue the authnmethodsreferences on the Azure AD RP to prevent users from getting “Double MFA” like SmartCard + Azure MFA. 🙂 For example, if I have Cert Auth as an enabled MFA provider as below, I only have to authenticate with my VSM/SmartCard even if MFA is enabled on the user.
The needed claims rule looks like this:

$Claims= @"
@RuleName = "Passthrough - MFA"
c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"]
 => issue(claim = c);
$AzureADRP = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform" 
Set-AdfsRelyingPartyTrust -TargetName $AzureADRP.Name `
                          -IssuanceTransformRules ($AzureADRP.IssuanceTransformRules + $Claims)

The above also works with the new Conditional Access policies for Exchange and SharePoint online.

Wrap up
Hopefully this post has given you some good insights what to think about implementing Azure MFA for Office 365. It is not a complete walk in the park, but it’s definately doable for most organizations.
As always, there are lots of if’s and but’s in all different environments. If I have missed something or if you have other, more specific questions, let me know!



Switch usage model in Azure Multi-Factor Authentication Server

Azure Multi-Factor Authentication is a really great service that helps you secure both cloud apps and on premise apps with easy means. Setting it up on premise requires you to create a multi-factor authentication provider in the Azure portal.

The first thing you need to choose creating a provider is the usage model (Per user/Per authentication) and as seen in the screenshot below, you cannot change the usage model after creating the provider.

So what to do if having deployed the MFA server with a per user usage model and later the conditions are changing and the per auth usage model would be a better fit?
Since it is not possible to change the usage model of an existing provider as it is right now, you have to create a new one and reactivate your existing server with activation credentials from the new provider.

This is a pretty simple task to do still keeping all users and settings that have been done on the server, but unfortunately it comes with a pretty big caveat if you’ve enrolled a lot of users with the MFA Mobile App. That means your users will have to re-enroll the mobile app in the user portal after you have done the usage model change. As a workaround to avoid interruption doing the change, you can of course change the mobile app users to Text or Phone verification instead.

1. Identify users that have the mobile app activated and inform them about the change.
2. Make a backup copy of the data folder in the Azure MFA installation path. (in most cases, C:\Program Files\Multi-Factor Authentication Server\Data)
3. Generate activation credentials for your new auth provider with the target usage model. (You have 10 minutes before you need to generate a new set of credentials)
4. If you have the Azure MFA Server UI running, exit that and then rename the licenseKey file in the installation folder.
5. Starting the MFA Server UI again, you will now get the first run wizard where you can activate the server again. Since you won’t make any configuration changes, you can check the “Skip the Authentication Configuration Wizard” and just activate the server instead.
6. The server has now been activated against your new provider and all settings have been preserved. Do however make sure to verify all services that depend on the MFA server after the change has been done.
Also remember that the Mobile App-enabled users will get the following error when authenticating until they have re-enrolled their account with the app or changed the verification model.

As you’ve seen in the post, it is not very hard to switch the usage model, even though it can be a bit painful if you have a lot of users utilizing the mobile app. Let me know if you have questions!


Windows Azure Multi Factor Authentication in Office 365

Windows Azure Multi Factor Authentication is a great service/Product that gives you a complete MFA solution both on premise and in the cloud. The best thing is that as of yesterday, it’s free for all accounts and not just for admin accounts.

Now you don’t have any excuses to not secure your admin accounts that have potentially access to multiple thousands of email accounts and other sensitive information.

One thing that I have not been testing until today, was to activate MFA for a Federated Administrator(DirSynced account with global administrator rights).
It works completely transparent for the user/admin, they just log on as they normally do to the ADFS server, and then the Azure MFA will kick in and require additional authentication.
How awesome is that?

Here’s how to activate MFA for an admin user (regardless if you’re using ADFS or not):

1. Logon to the O365-portal, under users and groups, find the “Set Multi-factor authentication requirements” row and click “Set up”.
2014-02-10 19-17-06

2. Choose the account(s) that you want to enable MFA for and click enable and then enable MFA.
2014-02-10 19-22-30
2014-02-10 19-27-38

3. After activated MFA, at next logon, the admin have to put in additional info about the second factor of authentication preferred. See the process to enroll devices as follows.
2014-02-10 19-37-24
Personally, I prefer using the mobile app as a second factor of authentication since its the easiest method, but it’s also possible to use text messages and phone for that.
2014-02-10 19-42-52
After verifying the activation with the Multi Factor Authentication app in my phone, I’m almost set, apart from one thing.
If you indend to use this account to connect to Office 365 with Outlook or ActiveSync, you will also need to create one or more app passwords that will be static passwords that can be used in cases where MFA doesn’t work.
2014-02-10 19-54-14

After creating eventual app passwords, you have now configured the specific account for multi factor authentication. Note that Microsoft is planning to add native multi-factor authentication for applications such as Outlook, Lync, Word, Excel, PowerPoint, PowerShell, and OneDrive for Business, with a release date planned for later in 2014.

Was it Hard? – No!
Should you use it whenever possible? – Yes!

Now, what’s your excuse to not activate Windows Azure Multi Factor Authentication for your Admin accounts?