Disable all phone and text options for MFA

Impact of Removing SMS As an MFA Method In Azure AD

Posted on Leave a commentPosted in 2FA, Azure Active Directory, Azure AD, MFA, security, self-service password reset, smartphone, sms, text message

There are a number of general recommendations that SMS (text messages) as an MFA method is not a good idea (mainly to do with the ease of porting or moving devices the number is associated with). You should always be looking at MFA with an app (Microsoft Authenticator or other) or hardware device. But the default in Azure AD is to include SMS as an option – so if we turn off text messaging as a second factor what is the impact to our user base who might have already registered their phone number.

My previous article on MFA end user experiences covered the different options available for the different registration wizards (legacy and the new combined MFA/SSPR wizard), what happens if you have SSPR enabled (and what happens if you do not). Each of the scenarios in that article allowed the user to register a phone number and then to have a text message sent at login.

If the user registered with the legacy authentication wizard (which is the default setting as of the time of writing) then there are three options by default – authentication phone, office number (set by the admin and not by the user) and mobile app (and phone is the selected option). Using SMS for second factor is therefore automatically set up unless the user chooses “office number” or “mobile app” whilst registering. The registration page looks as follows:

Legacy Auth for MFA with Phone Selected

So in scenarios where the user followed the defaults they get an MFA prompt at login that looks like this:

MFA via Phonecall dialog

Notice that they have an option to “sign in another way” for scenarios where the user maybe cannot receive a phone call but would be able to receive a text message (if you are in a location where you can receive neither, then you need to register the app as well in advance). If the user clicks “sign in another way” then they see the following where they can choose to receive a text message as the second factor proof:

Second factor proof select phone or text

To disable SMS/text as an MFA method you need to be in the Azure AD portal > MFA > Additional cloud-based MFA settings (or click Multi-Factor Authentication in the Users page of the same portal). You will see the below once you click the Service Settings tab:

Classic MFA Service Settings

This dialog includes the “skip multi-factor authentication…” box which you only have if you have Azure AD P1 or P2 licence. The four options at the bottom include the “Text message to phone” – uncheck that to stop SMS as a second factor.

So if SMS/text is removed as an option – what changes for the users who has already got a phone number stored as a MFA method? First change is that “sign in another way” message is now missing. A user who previously got a phone call with the option to change to another option will find that they cannot change options anymore (unless they have also registered a different method such as office number or mobile app:

MFA by Phone with SMS disabled

Therefore if there is not enough mobile signal to manage a call (and there might be for a text message) then the user cannot authenticate.

What about users who when they registered for MFA set SMS as their default? Setting text message as a default is not a obvious setting – but the default is whatever you initially choose to register with – so in the registration wizard if you select “send me a code by text message” then your default is SMS:

SMS as default MFA method

Once the admin disables SMS as a valid second factor, those users with phone as their default (or app) are not impacted – but users who set text message as their default are required to re-register. In the registration they are told their organization needs further information, that “call me” is the only available option, but their previously registered telephone number is shown in the registration wizard. This is shown in the following series of images:

More information required
Registration for MFA - Call only as a phone option
Registration for MFA steps
Registration for MFA steps 2

Once the users settings are saved, the user clicks Finish and their registration for phone authentication is updated to remove text message as a valid option. Enabling texts again in the admin portal does not allow this user to use texts again unless they register again or they update their additional security verification settings (Office 365 browser app > click photo > My account > Manage security & privacy > Additional security verification > Update your phone numbers used for account security (go to https://aka.ms/mfasetup as a shortcut to avoid all these steps)

If you remove both phone and text as a registration option as shown then users who previously only had phone and/or text registered will be required to register again.

Disable all phone and text options for MFA

This time registration will default to “mobile app” – where the user can select “code” or “notification” as their new default:

MFA Registration - phone and text disabled

In scenarios where you have enabled the new registration wizard (see my previous article on MFA end user experiences for more on this) then the default registration option is to use the app and not phone or text, though phone numbers are collected if you also turn on two or more options for requiring a password reset with SSPR. So in these scenarios you will probably find that the user has lots of registered options and so turning off SMS is not an issue.

So to disable SMS is only a problem in Azure AD for the user – and it means that at the next login they need to register again (so not a real problem). I had previously seen in 2018 that if the admin disabled text messages then users could not login if this was their only method! So that issue is clearly fixed now.

So as a call to action from this article – consider turning off text messages as a second factor and noting that the only impact is some users will either need to register again or you can ask them to go to https://aka.ms/mfasetup beforehand to change their default setting.

Exchange OWA and Multi-Factor Authentication

Posted on 21 CommentsPosted in 2010, 2013, Azure, exchange, IAmMEC, MFA, MVP, owa, smartphone

Multi-factor authentication (MFA), that is the need to have a username, password and something else to pass authentication is possible with on-premises servers using a service from Windows Azure and the Multi-Factor Authentication Server (an on-premises piece of software).

The Multi-Factor Authentication Server intercepts login request to OWA, if the request is valid (that is the username and password work) then the mobile phone of the user is called or texted (or an app starts automatically on the phone) and the user validates their login. This is typically done by pressing # (if a phone call) or clicking Verify in the app, but can require the entry of a PIN as well. Note that when the MFA server intercepts the login request in OWA, there is no user interface in OWA to tell you what is happening. This can result in user disconnect and stops the use of two-way MFA (receive number by text, type number into web application type scenario). Therefore to that end, MFA directly on the OWA application is not supported by the Microsoft Exchange team. Steps for setting up ADFS for Exchange Server 2013 SP1 or later are at https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx. Once this is in place, you need to enable MFA for ADFS rather than MFA for OWA. I have covered this in a separate post at http://c7solutions.com/2016/04/installing-azure-multi-factor-authentication-and-adfs.

To configure Multi-Factor Authentication Server for OWA (unsupported) you need to complete the following steps:

Some of these steps are the same regardless of which service you are adding MFA to and some slightly different. I wrote a blog on MFA and VPN at http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication and this contains the general setup steps and so these are not repeated here. Just what you need to do differently

Step 1

See http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication

Step 2: Install MFA Server on-premises

This is covered in http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication, but the difference with OWA is that it needs to be installed on the Exchange CAS server where the authentication takes place.

Ensure you have .NET 3.5 installed via Server Manager > Features. This will install the .NET 2.0 feature that is required by MFA server. If the installation of the download fails, this is the most likely reason for the failure, so install .NET 3.5 and then try the MFA Server install again.

The install of the MFA server does not take very long. After a few minutes the install will complete and then you need to run the Multi-Factor Authentication Server admin tools. These are on the Start Screen in More Apps or the Start Menu. Note that it will start the software itself if given time:

image

image

Do not skip the wizard, but click Next. You will be asked to activate the server. Activating the server is linking it to your Azure MFA instance. The email address and password you need are obtained from the Azure multi-factor auth provider that was configured in Step 1. Click the Generate Activation Credentials on the Downloads page of the Azure MFA provider auth management page.

image

The credentials are valid for ten minutes, so your will differ from mine. Enter them into the MFA Server configuration wizard and click Next.

MFA Server will attempt to reach Azure over TCP 443.

Select the group of servers that the configuration should replicate around. For example, if you where installing this software on each Exchange CAS server, then you might enter “Exchange Servers” as the group name in the first install and then select it during the install on the remaining servers. This config will be shared amongst all servers with the same group name. If you already have a config set up with users in it and set up a new group here, then it will be different settings for the users. For example you might have a phone call to authenticate a VPN connection but use the app for OWA logins. This would require two configs and different groups of servers. If you want the same settings for all users in the entire company, then one group (the default group) should be configured.

image

Next choose if you want to replicate your settings. If you have more than one MFA Server instance in the same group select yes.

Then choose what you want to authenticate. Here I have chosen OWA:

image

Then I need to choose the type of authentication I have in place. In my OWA installation I am using the default of Forms Based Authentication, but if you select Forms-based authentication here, the example URL for forms based authentication shown on the next page is from Exchange Server 2003 (not 2007 or later). Therefore I select HTTP authentication

Next I need to provide the URL to OWA. I can get this by browsing the OWA site over https. The MFA install will also use HTTPS, so you will need a certificate and have this trusted by a third party if you want to support user managed devices. Users managing their own MFA settings (such as telephone numbers and form of authentication) reduces the support requirement. That needs the User Portal, the SDK and the Mobile App webservice installed as well. These are outside the scope of this blog. For here I am going to use https://servername/owa.

image

Finish the installation at this time and wait for the admin application to appear.

Step 3: Configure Users for MFA

Here we need to import the users who will be authenticated with MFA. Select the Users area and click Import from Active Directory. Browse the settings to imports group members, or OUs or a search to add your user account. Once you have it working for yourself, add others. Users not listed here will not see any change in their authentication method.

Ensure that your test user has a mobile number imported from the Active Directory. If not add one, choosing the correct country code as well. The default authentication for the user is that they will get a phone call to this number and need to press # before they can be logged in. Ensure that the user is set to Enabled as well in the users area of the management program.

Step 4: Configure OWA for MFA (additional steps)

On the IIS Authentication node you can adjust the default configuration for HTTP. Here you need to set Require Multi-Factor Authentication user match. This ensures that each auth attempt is matched to a user in the users list. If the user exists and is enabled, then do MFA for them. If disabled, then the setting for Succeed Authentication on the advanced tab comes into play. If the user is not listed, authentication passes through without MFA.

image

Change to the Native Module tab and select OWA under Default Web Site only. Do not set authentication on the Backend Web Site. Also enable the native module on ECP on the Default Web Site as well:

image

Then I can attempt a login to OWA or ECP. Once I successfully authenticate my phone rings and I am prompted to press #. Once I press # I am allowed into Exchange!

Can’t Update Media Player Library on Windows SmartPhone

Posted on Leave a commentPosted in media player, smartphone, storage card, windows mobile

I have found for a while now that I could not view the Windows Media Player library on my phone, and everytime I viewed the library I got a dialog saying “An unexpected error occured”. But now I have fixed it. It must have been a corrupt copy of the libary database on the SDCard in my phone.

To fix:

Delete the MSMETADATA folder in the root of the Storage Card.

If using File Explorer on your device note that it’s not visible by default. You have to select the “Show All Files” option in File Explorer. Once deleted rebuild your library using Media Player, and see if that helps.