MFA and End User Impacts

Posted on 6 CommentsPosted in app password, ATP, Authentication, Azure, Azure Active Directory, Azure AD, Azure Information Protection, AzureAD, conditional access, EM+S, email, enterprise mobility + security, management, mcm, mcsm, MFA, microsoft, modern authentication, multi-factor auth, Multi-Factor Authentication, sspr

This article will look at the various different MFA settings found in Azure AD (which controls MFA for Office 365 and other SaaS services) and how those decisions impact users.

There is lots on the internet on enabling MFA, and lots on what that looks like for the user – but nothing I could see that directly laid out all the options and the impact of each option.

The options that the admin can set that I will cover in this article are:

  • Default settings for the MFA registration service
  • The enhanced registration service (now depreciated)
  • The refreshed enhanced registration service (MFA and Self-Service Password Reset registration combined)

The general impact to the user is that the user needs to provide a second factor to login. In this article I will not detail the above registration for each of the second factors and only cover the general process of registration – your exact experience on registration will depend upon what second factors (app notifications, app code, phone call and text message) you choose to implement.

This article will look mainly at the different between having no MFA and what happens from the users perspective as the admin turns on a requirement to have MFA. The various options that the admin can use to enable MFA are as follows:

  • Office 365 MFA (aka the legacy method) that is available to all users with or without a licence
  • Azure AD Conditional Access and setting a rule that requires MFA (when the user is not registered)
  • Azure AD Premium 2 licence and MFA Registration (register without requiring MFA to be enabled)
  • Azure AD Free fixed Conditional Access rules (MFA for all users) which is in preview at the time of writing (Aug 2019)

Terminology and Settings

This article refers back to a series of different settings in each of the following sections. To make the article avoid repeating itself, this section outlines each of the general settings, what I mean by the description I use and where I turn that setting on or off.

Office 365 MFA – This is the legacy MFA options set via https://admin.microsoft.com > User Management > Multi-Factor Authentication. This user experience turns on or off MFA for users regardless of app or location (unlike Conditional Access) and has settings for the different second factor methods (for example you can disable SMS from here).

Legacy MFA Admin Page

Conditional Access Based MFA – This is where you set rules for accessing cloud apps based on the user, the location, the risk (P2 licence required), the device (domain joined or compliant), the location (IP), the device risk (MDATP licence required), compliance (Intune required) etc. If you rule requires MFA and the logging in user passes the requirements for this rule (and is not otherwise blocked) then this is what I call Conditional Access Based MFA. This is set in https://portal.azure.com > Azure Active Directory > Enterprise Applications > Conditional Access

Conditional Access Based MFA

Azure AD Premium 2 MFA Registration – This is where you can get users to register before you turn on MFA via either of the above routes. Without the P2 licence you turn on MFA and at the next login the user needs to register. With P2 you can turn on registration at login without forcing MFA. You would then enable MFA later or you can have registration at next login (and defer that by 14 days) so that the user registers even if they never hit an endpoint that the need to do MFA on. For example, MFA when external and the user never works remotely. Therefore they will never have to do MFA and therefore never be required to register – which P2 licence you can get them to register independent of the requirement to do MFA. You access these settings via https://portal.azure.com > Azure AD Identity Protection > MFA Registration

Azure AD P2 MFA Registration

Self Service Password Reset Registration – This is shown if the user is in scope for SSPR and SSPR is enabled. This is not MFA registration – but if the user is in scope they will be asked to register for this as well. This therefore can result in two registrations at next login – one for SSPR and one for MFA. We will show this below, but it is best if you move to the combined MFA/SSPR registration wizard mentioned below.

SSPR Enablement

Enhanced Registration (Depreciated) – This was the new registration wizard in 2018 and have been replaced by the next option. If you still have users on this option you will see it, otherwise the option to enable this older wizard is now removed. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview

MFA Registration Wizard

Combined MFA and SSPR Registration – This is the current recommended MFA registration process and it includes self-service password reset registration as well. You should aim to move your settings to this. All the new MFA reporting and insights are based on this process. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview. Note that if you still have users on the previous “Enhanced Registration” shown above then this one is listed as “enhanced”. If not – if only one slider is shown – it is the new registration process. You can enable this for a group of users (for pilot) or all users:

Combined MFA and SSPR Registration Wizard

Office 365 MFA + Original Registration

This is not recommended to be used any more – use the Azure AD Free Conditional Access rules for all users or all admins instead. But for completion of the process to show all the options, you select a user(s) in the Office 365 MFA page and click Enable. In the below screenshot we can see that Cameron White is enabled for MFA. This means that it has been turned on for him, but he has not yet gone through the registration wizard:

Office 365 MFA for Single User

The video below shows the first run experience of this user – they login and are prompted to register for MFA. They register using the legacy experience and are then granted access to the application.

OFFICE 365 MFA + LEGACY REGISTRATION

Office 365 MFA + Enhanced Registration

For this scenario I have a user called Brian Johnson. He has been enabled for MFA as above (Office 365 method) but additionally has been added to a group that is configured to support the new MFA+SSPR combined registration process. Brian is not enabled for SSPR. The video shows the user experience. Note that the user needs a valid licence to be able to use this experience. If they do not have any licences they will get the old experience:

VIDEO OFFICE 365 MFA + ENHANCED REGISTRATION

Conditional Access MFA

The following video looks at the experience of two users who are enforced for MFA via Conditional Access. The login will trigger the registration for MFA as neither user is already registered. The first user (Christie) gets the old registration wizard and the second (Debra) gets the new registration wizard. The Conditional Access settings are basic – MFA in all circumstances for our two users:

Conditional Access Two Users
Conditional Access MFA Enabled
CONDITIONAL ACCESS WITH OLD AND NEW REGISTRATION

Impact of SSPR on MFA Registration and User Sign-In

When users are set up to register their password reset security methods and MFA, but using the old registration wizard the user needs to do two sets of registration. Again, it is recommended that the combined registration process is used instead of this process.

For this demostration, we are enabling SSPR for our test users. One with the old registration wizard and one with the new one:

SSPR WITH AND WITHOUT COMBINED REGISTRATION

Adding SSPR To Already Registered Users

Once a user has registered for MFA (old or new registration) it might come a time where you enable SSPR for them after that (and not at the time of original registration). In this scenario the users that registered with the old registration wizard are asked to register for SSPR, but users who went through the new wizard – though they did not specifically register for SSPR – there is enough details already available for them to use the service (as long as app notifications and codes is enabled for SSPR). If SSPR is left on the default of SMS and Email, then the new registration wizard does not have your alternative email and so SSPR is unavailable to you. The user process and flow is shown in the next video:

ENABLE SSPR AFTER REGISTRATION

Azure AD Identity Protection and MFA Registration

The Azure AD Premium 2 licensed feature called Identity Protection contains the ability to request that the user registers for MFA (and SSPR if via the new combined registration wizard) even if the user is not required to perform MFA for login – all our previous registrations only required registration because the user needed to do MFA. You can ask users to pre-register via https://aka.ms/mfasetup but Identity Protection adds this functionality with a 14 day option to defer. The video shows the settings and the user experience:

Azure AD IDENTITY PROTECTION WITH AND WITHOUT NEW REGISTRATION

Azure AD Free Conditional Access for All Users

Early Q2 2019 Microsoft rolled out new baseline policies for Azure AD Conditional Access. These are available even without the Azure AD P1 licence needed for Conditional Access – but as they are licence free they are heavily restricted – they apply to all users and need MFA if sign-in is risky. So though they do not require MFA on all logins (unlike the O365 MFA legacy settings) they do require registration. But they offer a 14 day deferral process if the user is not ready to register. But unlike Azure AD Identity Protection mentioned above, you cannot do this for some users – it is enabled for all users upon enabling the rule. Lets see the settings and the user experience in the video. The video will also enable the “all admins” baseline policy as well, as that should always be turned on.

BASELINE POLICY FOR ALL USERS WITH REGISTRATION

Getting Rid of Passwords in Azure AD / Office 365

Posted on 3 CommentsPosted in Authentication, Azure Active Directory, Azure AD, AzureAD, FIDO, modern authentication, Multi-Factor Authentication, password, yubikey

This article is based on the public preview of the use of hardware tokens/Microsoft Authenticator to do sign-in without passwords released in July 2019

Using Microsoft Authenticator for Passwordless Sign-in

You used to be able to do this by running the following in PowerShell for the last few years

New-AzureADPolicy -Type AuthenticatorAppSignInPolicy -Definition ‘{“AuthenticatorAppSignInPolicy”:{“Enabled”:true}}’ -isOrganizationDefault $true -DisplayName AuthenticatorAppSignIn

Interestingly, if you have done this in the past, the new Azure AD portal settings for doing this do not take this into consideration. So first, if you have run the above then you need to remove it with Remove-AzureADPolicy –Id <get the ID using Get-AzureADPolicy> before you implement the below, otherwise it is turned on for everyone even though Azure AD Portal says it is not enabled:

image

So to start, visit the Azure AD Portal at https://portal.azure.com and select Azure Active Directory. Then select Authentication Methods (under Security) and then Authentication Method Policy (Preview) or go directly there with https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/AuthenticationMethods.

Click Microsoft Authenticator passwordless sign-in and choose Enable and to pilot choose Select Users and the group you want to pilot with. Otherwise if you want to turn it on for all users, just leave the default. Note that nothing changes for the user – they need to do stuff before it works for them.

image which results in image

As the notice says, also ensure that you have MFA with push notifications enabled. This option has been available for a year or so now, and you will find it on Password Reset > Authentication Methods (or directly with https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/PasswordReset). This is not the same setting as the blue bar at the top of the page you are currently on.

For the user, from within Microsoft Authenticator, they need to go to the settings and register the device with their login. This is a one time process and once you have done the above and they have registered the device, they can choose to do password-less sign-in.

From a login perspective, it looks like this:

  1. Enter your username to an Azure AD login
  2. image
  3. On your phone, in the notification from the Microsoft Authenticator app, you select the displayed number (which changes number, and the position of the number each time)
  4. Screenshot_20190711-212252

Hardware Tokens Instead of Passwords (FIDO2)

This is the second option made available in Azure AD in July 2019. This allows the use of hardware tokens such as Windows Hello and FIDO2 devices (i.e. Yubikey and others) to authenticate to the platform. Note that this is not MFA – you have one factor, the hardware token. There is no requirement to implement a second factor with the hardware token as this replaces the password and is not storing a password. That is, if you do not have the token you do not have access – you cannot guess or intercept the token exchange.

To turn on this feature select the FIDO2 Security Key option under Authentication Methods (under Security) and then Authentication Method Policy (Preview).

As with the Microsoft Authenticator option above, Enable the feature and select All Users or Select Users.

Unlike the Microsoft Authenticator option, you now have the choice of Self Service and Key Restrictions

Self Service is useful when you have All Users selected, as the user registers their own security key. Without Self Service you need to configure a key for each user. Self Service requires the new registration service which is mentioned above and linked to at the top of the configuration page in Azure AD portal.

Enforce Attestation allows you to ensure that a specific model / device of hardware security key is used. Enforce Key Restrictions requires that you add the key by its AAGUID as shown:

image

From here you can also Restrict Specific Keys to only allow keys you have issued to be used. Block would allow you to have any key.

Enhanced Registration Preview

This preview has been available since early 2019, but now supports passwordless and security token as authentication methods. Click the link in the blue bar and ensure everyone whom you have enabled the new authentication policy for is included for the new registration preview. In the graphic below, this is the lower of the two options – your tenant might show only the lower option.

image

To direct users to the new preview experience visit http://aka.ms/mfasetup or if you have a Conditional Access login but you have not registered, you will be directed here anyway.

On the security info page, if you have already registered for MFA you will be shown your current authentication methods:

image

If you have not registered before you will be asked to register – either way, you get to pick the methods you want to use for authentication. These need to be:

image

  • Authenticator App – you can add up to five of these
  • Security Key

To add a new Security Key select this and follow the steps but make sure you are running Microsoft Edge on Windows 10 1903 or later or Firefox. On Chrome (which supports FIDO2 for Google Services) you get the below:

image

On a supported browser, you will see the following series of prompts:

image

image

The above is for a USB key. NFC keys and readers will have different prompts along the lines of holding the device near to the reader.

image

image

image

Then you need to name your key:

image

image

Signing In With A Security Key

Login to Office or your selected cloud app and enter your username and click next.

SNAGHTML2a9bd15

Now you can click “Sign in with Windows Hello or a security key”

image

As with registration, you now need to enter your PIN and press the button on the USB device, scan your fingerprint, look at your camera or hold your NFC device next to the reader – whatever your device requires you to do.

On your MFA registration page at https://aka.ms/mfasetup your security device is listed:

SNAGHTML2ac1742

Your login did not require a password – yippee!

Azure AD Single Sign-On Basic Auth Popup

Posted on Leave a commentPosted in AADConnect, AADSync, Azure Active Directory, Azure AD, AzureAD, conditional access, microsoft, modern authentication, SSO

When configuring Azure AD SSO as part of Pass-Through Authentication (PTA) or with Password Hash Authentication (PHA) you need now (since March 2018) to only configure a single URL in the Intranet Zone in Windows. That URL is https://autologon.microsoftazuread-sso.com and this can be rolled out as a registry preference via Group Policy. Before March 2018 there was a second URL that was needed in the intranet zone, but that is no longer required (see notes).

So this short blog post is how to fix SSO when you do see a popup for this second URL though it is no longer required. The popup looks like:

image

It has OK and Cancel on it as well, but my screengrab I made when I saw the issue was not brilliant, so I “fixed” the bottom of the image so its approx. correct!

The URL is aadg.windows.net.nsatc.net. Adding this to Local Intranet Zone even though it is not needed does not fix the issue. The issue is caused because on Windows 10 (version 1703 and maybe others) someone has enabled Enhanced Protected Mode. Azure SSO does not work when Enhanced Protected Mode is enabled. This is not a setting that is enabled on client machines by default.

Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running at least Windows 8, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.

It is probable that Enhanced Protected Mode is enabled via Group Policy. It will either have the value Isolation (or Isolation64bit) set to a value of PMEM at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main or the policy equivalent at  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main when set via GPO settings.

This issue is listed in the Azure AD SSO known issues page at https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso. The reason why Enhanced Protected Mode does not work with Azure AD SSO is that whilst Enhanced Protected Mode is enabled, Internet Explorer has no access to corporate domain credentials.