Export (0) Print
Expand All

Securing access to cloud services - Information for Administrators

Published: May 20, 2013

Updated: September 23, 2014

This section provides specific information that you, as an administrator, must be aware of when you are using Azure Multi-Factor Authentication. It also contains procedures for enabling and disabling Multi-Factor Authentication on user accounts. This section contains the following topics:

Before you set up and use Multi-Factor Authentication, be aware of the following information:

  • Multi-Factor Authentication is available at no additional cost for Microsoft Office 365 users and administrators of a Azure subscription.

  • The Multi-Factor Auth Provider will need an Azure Active Directory Tenant before it can be enabled for users or authentication. Also you can only have one Multi-Factor Auth provider per tenant.

  • If the Multi-Factor Auth provider is deleted, users will default back to single-factor authentication (.i.e passwords).

  • For browser-based clients, users must sign in by using user name, password, and phone-based second factor for passive flows.

  • For federated(SSO) customers there are additional requirements that should be reviewed prior to enabling multi-factor authentication. For these requirements see Federated(SSO) App Passwords.

  • App Passwords required for non-browser clients -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.. See App Passwords with Azure Multi-Factor Authentication.

  • Windows Intune does not fully support Multi-Factor Authentication - Once multi-factor authentication is enabled, non-browser clients such as the Company Portal App will not work. This may result in some users getting an error when attempting to enroll a Windows RT or Windows Phone device.

Please be aware that once multi-factor authentication is enabled on an administrator’s account, app passwords can be used with most non-browser clients such as Outlook and Lync, but administrative actions cannot be performed using app passwords through non-browser applications such as Windows PowerShell. Ensure you create a service account with a strong password to run Powershell scripts and do not enable that account for multi-factor authentication.

User accounts in Azure Multi-Factor Authentication have the following three distinct states:

 

State

Description

Notes

Disabled

The default state for a new user not enrolled in multi-factor authentication.

  • The user is currently not using multi-factor authentication.

  • Non-browser apps (such as …Outlook etc.) are not affected.

Enabled

The user has been enrolled in multi-factor authentication.

  • The user is enabled but has not completed the registration process. They will be prompted to complete the process at next sign-in.

  • Non-browser apps (such as …Outlook etc.) are not affected. They will continue to work with the current credentials until the registration process is complete.

Enforced

The user has been enrolled and has completed the registration process for using multi-factor authentication

  • The user may or may not have completed registration. If they have completed the registration process then they are using multi-factor authentication. Otherwise, the user will be prompted to completer the process at next sign-in

  • Non-browser apps (such as …Outlook etc.) will not work until app passwords are created and enterend into the non-browser apps.

Use the following procedure to enable Multi-Factor Authentication for a user account.

ImportantImportant
Please be aware that once multi-factor authentication is enabled on a user account, that user must complete the auto-enrollment when signing in. This will occur the first time the user signs in after the account has been enabled for multi-factor authentication. Until the user has done this, multi-factor authentication will not be enabled on the account.

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory for the user you wish to enable.

  4. At the top, click Users.

  5. At the bottom of the page, click Manage Multi-Factor Auth. This will open the multi-factor authentication page.

    noteNote
    If the page that pops up states that the Microsoft account is not supported, you need to sign in with an Organizational ID to manage Multi-Factor Authentication. You cannot manage Multi-Factor Authentication with a Microsoft Account.

  6. Find the user that you wish to enable for multi-factor authentication. You may need to change the view at the top. Ensure that the user’s status is disabled and place a check in the box next to their name.

  7. This will bring up two options on the right, Enable and Manage user settings. Click Enable. This will bring up a pop-up that will specify the next steps you need to take with your users. Click enable multi-factor auth.

  8. Once you have enabled your users, it is advised that you send your users an email that informs them how they can use their non-browser apps such as Outlook, Lync and not be locked out. The following is an email template that can be used which includes a link to a video that the users can watch.

To change the user's state to Enabled for Multi-Factor Authentication by using Windows PowerShell, use the following command.

$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = “Enabled”
$sta = @($st)
Set-MsolUser -UserPrincipalName bsimon@contoso.com -StrongAuthenticationRequirements $sta

Once you have enabled your users, it is advised that you send your users an email that informs them that they will need to provide there contact information. The following is an email template that can be used which includes a link to a video that the users can watch.

Subject: ACTION REQUIRED: Your password for Outlook and other apps needs updated

Body:

For added security, we have enabled multi-factor authentication for your account. 

Action Required: You will need to complete the enrollment steps below to make your account secure with multi-factor authentication.  

What to expect once MFA is enabled:

Multi-factor authentication requires a password that you know and a phone that you have in order to sign into browser applications and to access Office 365, Azure portals.

For Office 365 non-browser applications such as outlook, lync, a mail client on your mobile device etc, a special password called an app password is required instead of your account password to sign in. App passwords are different than your account password, and are generated during the multi-factor authentication set up process. 

Please follow these enrollment steps to avoid interruption of your Office 365 service:

1.  Sign in to the Office 365 Portal at http://portal.microsoftonline.com.
2.  Follow the instructions to set up your preferred multi-factor authentication method when signing into Office 365 using a web browser. 
3.  Create one app password for each device.
4.  Enter the same app password in all applicable apps on that device e.g. Outlook, Mail client, Lync, Word, Powerpoint, Excel, CRM etc. 
5.  Update your Office client applications or other mobile applications to use an app password.

You can visit http://aka.ms/mfasetup to create app passwords or change your MFA Setting.  Please bookmark this.

NOTE: Before entering an app password, you will need to clear the sign-in information (delete sign-in info), restart the application,   and sign-in with the username and app password. Follow the steps documented : http://technet.microsoft.com/en-us/library/dn270518.aspx#apppassword.


Watch a video showing these steps at http://g.microsoftonline.com/1AX00en/175.

Best Regards,
Your Administrator

Use the following procedure to disable Multi-Factor Authentication for a user account.

ImportantImportant
Upon disabling a user, the user will need to sign-in with his organizational password as App Passwords will no longer be applicable. Users will no longer be prompted for the phone based strong verification. Please educate the user about this prior to disabling to avoid lockouts.

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory for the user you wish to enable.

  4. At the top, click Users.

  5. At the bottom of the page, click Manage Multi-Factor Auth. This will open the multi-factor authentication page.

    WarningWarning
    If the page that pops up states that the Microsoft account is not supported, you need to sign in with an Organizational ID to manage Multi-Factor Authentication. You cannot manage Multi-Factor Authentication with a Microsoft Account.

  6. Find the user that you wish to disable for multi-factor authentication. You may need to change the view at the top. Place a check in the box next to their name.

  7. Depending on the state of the user account this will bring up either two or three options on the right. Click Disable. This will bring up a popup that will ask you to disable the multi-factor authentication. Click Yes.

To change the state to disabled for multi-factor authentication on a user using PowerShell use the following:

$sta = @()
Set-MsolUser -UserPrincipalName bsimon@contoso.com -StrongAuthenticationRequirements $sta

If you have a lot of users to enable or wish to only enable certain users, you can use the bulk update feature that is available on the multi-factor authentication page. This feature allows you to upload a csv file that contains the username and the multi-factor authentication status. The csv file must be formatted correctly with the Username and MFA Settings as the top header similar to the one below.

bulk update 1

Use the following procedure to upload a .csv file for bulk enabling.

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory for the user you wish to enable.

  4. At the top, click Users.

  5. At the bottom of the page, click Manage Multi-Factor Auth. This will open the multi-factor authentication page.

  6. At the top, click bulk update. This will bring up a window asking you to select a csv file.

    noteNote
    You can also download a sample cvs file from here by clicking Download a sample file.

    bulk update 2

  7. Click Browse for file, select your csv file, click open and then click the right arrow.

    bulk update 4

  8. The file will be verified and you will see a status similar to the one below. Click the right arrow. If you have a large file, this may take a few moments.

    bulk update 5

  9. You should now see the Done screen with a report of the number of users that were updated. Click the checkmark. The users status should now be updated.

    bulk update 6

Once a user account has been enabled for multi-factor authentication, the account will be in an enabled state. This means that the user will be prompted to complete registration for multi-factor authentication the next time they sign-in, but their non-browser apps (such as …Outlook etc.) will continue to work until they have registered. If you wish to force the user to register, you can change their status to enforced manually. This will mean that the user will be prompted to register the next time they sign-in and that their non-browser apps (such as …Outlook etc.) will not work until the user has created app passwords for them

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory for the user you wish to enable.

  4. At the top, click Users.

  5. At the bottom of the page, click Manage Multi-Factor Auth. This will open the multi-factor authentication page.

  6. Find the user that you wish to enforce for multi-factor authentication. You may need to change the view at the top. Ensure that the user’s status is enabled and place a check in the box next to their name.

  7. This will bring up two options on the right, Enable and Manage user settings. Click Enforce. This will bring up a pop-up that will specify the next steps you need to take with your users. Click enforce multi-factor auth.

To change the state to enforced for multi-factor authentication on a user using PowerShell use the following:

$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = “Enforced”
$sta = @($st)
Set-MsolUser -UserPrincipalName bsimon@contoso.com -StrongAuthenticationRequirements $sta

Administrators can manage the following user settings if a computer or device is lost or stolen:

  • Require selected users to provide contact methods again. Forces the user to complete the registration process again when he or she signs in. Non-browser apps will continue to work if the user has app passwords for them, unless the following setting is also selected.

  • Delete all existing app passwords generated by the selected users. Deletes all of the app passwords that the user created. Non-browser apps that were associated with these app passwords will cease to work until a new app password is created.

To change these settings for a user, use the following procedure.

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory for the user you wish to enable.

  4. At the top, click Users.

  5. At the bottom of the page, click Manage Multi-Factor Auth. This will open the multi-factor authentication page.

  6. Find the user that you wish to manage and place a check in the box located next to the name. You may need to change the view at the top.

  7. This will bring up two options on the right, Enable and Manage user settings. Click Manage User settings. This will bring up a pop-up allow you to select Require selected users to provide contact methods again and Delete all existing app passwords generated by the selected users.

  8. Place a check in the desired boxes and click Save.

Manage User Settings

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.

The following is a list of applications that support App Passwords.

  • Office 365

  • Outlook

  • Microsoft Exchange ActiveSync clients

  • Microsoft Lync

  • Microsoft Word, Excel, and PowerPoint on the desktop

  • Microsoft Word, Excel, and PowerPoint on mobile devices.

  • OneDrive

The following is important information that an organization should know about using app passwords.

 

Type of Users Federated(SSO) or Managed Non-browser apps (such as Outlook, etc.) will work with Multi-Factor Authentication enabled

Administrators

Federated(SSO)

Yes, with the use of app passwords

Non-Administrators

Federated(SSO)

Yes, with the use of app passwords

Administrators

Managed

Yes, with the use of app passwords

Non-Administrators

Managed

Yes, with the use of app passwords

noteNote
App Passwords will NOT be allowed to sign into browser apps.

Please be aware of the following:

  • Authentication Experience

    • For browser based apps:

      • The 1st factor of authentication is performed on-premises

      • The 2nd factor is a phone based method carried out by Cloud Identity.

    • For non-browser based apps:

      • Admins and users can use app passwords to sign-in.

  • Users can have multiple app passwords which increases the surface area for theft. Since app passwords are hard to remember, it might encourage people to write this down. This is not recommended and should be discouraged because only one factor is required to login with app password.

  • Apps which cache passwords and use it in on-premise scenarios might start failing since the app password will not be known outside of the organizational id. An example is Exchange emails that are on-premise but the archived mail is in the cloud. The same password will not work.

  • The actual password is automatically generated and is not supplied by the user. This is because the automatically generated password, is harder for an attacker to guess and is more secure.

  • Currently there is a limit of 40 passwords per user. You will be prompted to delete told to delete one of your existing app passwords in order to create a new one.

Naming Guidance for App Passwords – It is recommended that app password names should reflect the device on which they will be used. For instance, if you have a laptop that has non-browser apps such as Outlook, Word, and Excel, you only need to create one app password named Laptop and use that app password in all of these applications. Although you can create separate passwords for all of these applications, it is not recommended. The recommend way is to use one app password per device.

app password 2

app password 4

Azure AD supports federation with on-premises Windows Server Active Directory Domain Services (AD DS). If your organization is federated(SSO) with Azure AD and you are going to be using Azure Multi-Factor Authentication, then the following is important information that you should be aware when using app passwords. This applies only to federated(SSO) customers.

  • The App Password is verified by Azure AD and hence bypasses federation. Federation is only actively used when setting up App Password.

  • For federated(SSO) users, we will never go to the Identity Provider (IdP) unlike the passive flow. The passwords will be stored in the organizational id. If the user leaves the company, that info has to flow to organizational id using DirSync in real time. Account disable/deletion may take up to 3 hours to sync, delaying disable/deletion of App Password in Azure AD.

  • On-premises Client Access Control settings are not honored by App Password

  • No on-premises authentication logging / auditing capability is available for App Password

  • More end-user education is required for the Microsoft Lync 2013 client. For the required steps, see How to change the password in your email to the app password.

  • Certain advanced architectural designs may require using a combination of organizational username and passwords and app passwords when using multi-factor authentication with clients, depending on where they authenticate. For clients that authenticate against an on-premise infrastructure, you would use an organizational username and password. For clients that authenticate against Azure AD, you would use the app password.

    For example, suppose you have an architecture that consists of the following:

    • You are federating your on-premise instance of Active Directory with Azure AD

    • You are using Exchange online

    • You are using Lync that is specifically on-premise

    • You are using Azure Multi-Factor Authentication

Exchange online Lync onprem

In these instances, you must do the following:

  • When signing-in to Lync, use your organizations’ username and password.



    Lync login

  • When attempting to access the address book via an Outlook client that connects to Exchange online, use an app password.

To allow users the ability to create app passwords use the following procedure:

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory for the user you wish to enable.

  4. At the top, click Users.

  5. At the bottom of the page, click Manage Multi-Factor Auth. This will open the multi-factor authentication page.

  6. At the top of the multi-factor authentication page, click Service Settings.

  7. Ensure that the radio button next to Allow users to create app passwords to sign into non-browser applications is selected.

allow users

Multi-Factor Authentication for Office 365, powered by Azure Multi-Factor Authentication, works exclusively with Office 365 applications at no additional cost and is managed  from the Office 365 portal. Multi-Factor Authentication for Office 365 offers a subset of Azure Multi-Factor Authentication capabilities which include:

  • Administrators can Enable/Enforce MFA to end-users

  • Use Mobile app (online and OTP) as second authentication factor

  • Use Phone call as second authentication factor

  • Use SMS as second authentication factor

  • Application passwords for non-browser clients (e.g. Outlook, Lync)

  • Default Microsoft greetings during authentication phone calls

  • Default Microsoft greetings during authentication phone calls

Administrators and decision makers can use the following table to determine which version of multi-factor authentication is right for them.

 

Multi-Factor Authentication for Office 365

Multi-Factor Authentication for Azure Administrators

Azure Multi-Factor Authentication

Included in Azure Subscription

Yes

Included in Office 365 SKUs

Yes

Administrators can Enable/Enforce MFA to end-users

Yes

Yes - (Applies to only users who are Azure Administrators)

Yes

Use Mobile app (online and OTP) as second authentication factor

Yes

Yes

Yes

Use Phone call as second authentication factor

Yes

Yes

Yes

Use SMS as second authentication factor

Yes

Yes

Yes

Application passwords for non-browser clients (e.g. Outlook, Lync)

Yes

Yes

Yes

Default Microsoft greetings during authentication phone calls

Yes

Yes

Yes

Custom greetings during authentication phone calls

Yes

Fraud alert

Yes

MFA SDK

Yes

Security Reports

Yes

MFA for on-premises applications/ MFA Server.

Yes

One-Time Bypass

Yes

Block/Unblock Users

Yes

Customizable caller ID for authentication phone calls

Yes

Event Confirmation

Yes

Multi-Factor Authentication for Office 365 can be enabled via the Azure portal or the Office 365 Admin portal.

ImportantImportant
If you only want to use Multi-Factor Authentication for Office 365, do not create a Multi-Factor Authentication Provider in the Azure portal and link it to a directory. Doing so will take you from Multi-Factor Authentication for Office 365 to the paid version of multi-factor authentication.

To enable multi-factor authentication via the Azure portal, use the following procedure.

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory for the user you wish to enable.

  4. At the top, click Users.

  5. At the bottom of the page, click Manage Multi-Factor Auth. This will open the multi-factor authentication page.

    noteNote
    If the page that pops up states that the Microsoft account is not supported, you need to sign in with an Organizational ID to manage Multi-Factor Authentication. You cannot manage Multi-Factor Authentication with a Microsoft Account.

  6. Find the user that you wish to enable for multi-factor authentication. You may need to change the view at the top. Ensure that the user’s status is disabled and place a check in the box next to their name.

  7. This will bring up two options on the right, Enable and Manage user settings. Click Enable. This will bring up a pop-up that will specify the next steps you need to take with your users. Click enable multi-factor auth.

  8. Once you have enabled your users, it is recommended that you send your users an email that informs them how they can use their non-browser apps as Outlook, Lync and not be locked out. The following is an email template that can be used which includes a link to a video that the users can watch.

To enable multi-factor authentication via the Office 365 portal, use the following procedure.

  1. Sign-in to the Office 365 Portal.

  2. Navigate to the Office 365 admin center

  3. Select users and groups

  4. Next to Set Multi-Factor authentication requirements click Setup.

    Basic MFA for Office 365 1

  5. Find the user that you wish to enable for multi-factor authentication. You may need to change the view at the top. Ensure that the user’s status is disabled and place a check in the box next to their name.

    Basic MFA for Office 365 2

  6. This will bring up two options on the right, Enable and Manage user settings. Click Enable. This will bring up a pop-up that will specify the next steps you need to take with your users. Click enable multi-factor auth.

  7. Once you have enabled your users, it is advised that you send your users an email that informs them how they can use their non-browser apps as Outlook, Lync and not be locked out. The following is an email template that can be used which includes a link to a video that the users can watch.

Trusted IPs is a feature of multi-factor authentication that allows administrators of a managed or federated tenant the ability to bypass multi-factor authentication for users that are signing in from the company’s local intranet. The features are available for Azure AD tenants that have Azure AD Premium, Enterprise Mobility Suite or Azure Multi-Factor Authentication licenses.

 

Type of Azure AD Tenant

Available Trusted IPs options

Managed

  • Specific IP address ranges – Administrators can specify a range of IP addresses that can bypass multi-factor authentication for users that are signing in from the company’s intranet..

Federated

  • All Federated Users - All federated users who are signing-in from inside the organization will bypass multi-factor authentication using a claim issued by AD FS.

  • Specific IP address ranges – Administrators can specify a range of IP addresses that can bypass multi-factor authentication for users that are signing in from the company’s intranet..

This bypass only works from inside a company’s intranet. So for example, if you only selected all federated users, and a user signs in from outside the company’s intranet, that user will have to authenticate using multi-factor authentication even if the user presents an AD FS claim. The following table describes when multi-factor authentication and app passwords are required inside your corpnet and outside your corpnet when Trusted IPs is enabled.

 

Trusted IPs enabled

Trusted IPs disabled

Inside corpnet

For browser flows multi-factor authentication NOT required.

For rich client apps, regular passwords will work if the user has not created any app passwords. Once an app password has been created, app passwords are required.

For browser flows, multi-factor authentication required

For rich client apps, app passwords required

Outside Corpnet

For browser flows, multi-factor authentication required.

For rich client apps, app passwords required

For browser flows, multi-factor authentication required.

For rich client apps, app passwords required

Use the following procedure to enable Trusted IPs

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under, Directory click on the directory you wish to setup Trusted IPsing on.

  4. On the Directory you have selected, click Configure.

  5. In the multi-factor authentication section, click Manage service settings.

  6. On the Service Settings page, under Trusted IPs, select either

    • For requests from federated users originating from my intranet – All federated users who are signing in from the corporate network will bypass multi-factor authentication using a claim issued by AD FS. This may require some additional configuration steps depending on the version of AD FS that you are using.

      1. AD FS in Windows Server 2012 R2 guidance

      2. AD FS in Windows Server 2012 and AD FS 2.0

    • For requests from a specific range of public IPs – enter the IP addresses in the boxes provided using CIDR notation. For example: xxx.xxx.xxx.0/24 for IP addresses in the range xxx.xxx.xxx.1 – xxx.xxx.xxx.254, or xxx.xxx.xxx.xxx/32 for a single IP address. You can enter up to 12 IP address ranges.

  7. Click save.

  8. Once the updates have been applied, click close

Suspending Multi-Factor Authentication for remembered devices and browsers is a feature that allows administrators the ability to give their users the option to suspend Multi-Factor Authentication for a set number of days after performing a successful Multi-Factor Authentication. It is a free feature for all Multi-Factor Authentication users and enhances the usability for the users.

However since the users are allowed to suspend MFA, this feature may reduce account security. To ensure that the user accounts are secured, the users should restore Multi-Factor Authentication for your devices in case of either of the following scenarios:

  • If your corporate account has become compromised

  • If a remembered device is lost or stolen

ImportantImportant
This feature is implemented as a browser cookie cache. It will not work if your browser cookies are not enabled.

Use the following procedure to enable or disable Suspend Multi-Factor Authentication for remembered devices and to set the number of allowed days for the suspension.

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under Active Directory, click on the directory you wish to setup Suspend Multi-Factor Authentication for remembered devices on.

  4. On the Directory you have selected, click Configure.

  5. In the multi-factor authentication section, click Manage service settings.

  6. On the Service Settings page, under manage user device settings, select/unselect the Allow users to suspend Multi-Factor Authentication by remembering their devices option

    Remember PC1

  7. Set the number of days that you want to allow the suspension. The default is 14 days.

  8. Click save

  9. Once the updates have been applied, click close

Both administrators and users have the ability to reset Multi-Factor Authentication on their devices and browsers. This is done by restoring Multi-Factor Authentication for a user’s devices and browsers. When doing this, this will remove the suspension from all of the user’s devices and browsers.

The following procedure can be used by administrators to restore Multi-Factor Authentication on suspended devices and browsers. For information on how users can restore Multi-Factor Authentication on suspended devices see

  1. Sign-in to the Azure Management Portal.

  2. On the left, click Active Directory.

  3. Under Active Directory, click on the directory that contains the user that you want to restore suspended devices on.

  4. On the Directory you have selected, click Configure.

  5. In the multi-factor authentication section, click Manage service settings.

    Remember 2

  6. Select the users tab

  7. On the users page, select the user you want to restore Multi-Factor Authentication for.

  8. Click on the Manager User Settings link and in the popup window, select the Restore Multi-Factor Authentication on all suspended devices option.

    Remember 3

  9. Click save.

  10. Once the updates have been applied, click close.

The following table lists various scenarios and the types of multi-factor authentication that are required to support these scenarios.

Multi-factor Authentication various scenarios

Office 365 with Federated Id - ADFS

Office 365 with no Federation - Azure AD only

SaaS application via Access Panel

On-premises Apps

Custom Apps - SDK

MFA functionality available

Yes

Yes

Yes

Yes

Yes

Minimum Version of MFA required

MFA for Office 365

MFA for Office 365

Azure MFA

Azure MFA

Azure MFA

MFA available for Web client

Yes

Yes

Depends on Application

Depends on Application

Depends on Application

MFA available for Rich client

Yes (Application password)

Yes (Application password)

N/A

N/A

N/A

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

Show:
© 2014 Microsoft