For months, admins wanting to create and manage their on-premises Azure Multi-factor Authentication Server settings had to resort to the old Azure Portal, based on the Azure Service Management (ASM) model, and the PhoneFactor Web (PFWeb) portal, while the rest of Azure Active Directory moved and improved in the new Azure Portal, based on Azure Resource Manager (ARM).
Today, this divide ends.
What you needed the old portal for
Previously, you’d use the old Azure Portal, if you’d wanted to:
MFA Provider MANAGEMENT
- Create an Azure Multi-Factor Authentication Provider, specifying a name, usage model (per enabled user or per authentication), subscription and (optionally) a directory link. These providers let you enable additional security for directory users and applications that use the Multi-Factor Authentication libraries.
- Delete an Azure Multi-Factor Authentication Provider
Ironically, these actions were all performed on the MULTI-FACTOR AUTH PROVIDERS tab of the ACTIVE DIRECTORY category.
Manage service settings
Additionally, when you’d select the Azure Active Directory in the old Azure Portal, and then go to the CONFIGURE tab and under multi-factor authentication followed the Manage service settings link, you had the opportunity to:
- Allow users to create app passwords to sign in to non-browser apps
- Make specific authentication methods (Call to phone, Text message to phone, Notification through mobile app and Verification code from mobile app) available or unavailable to end-users.
- Allow users to remember multi-factor authentication on devices they trust, and specify the Days before a device must re-authenticate, between 1 and 60 days.
When performing any of the above actions in the old Azure portal, a message would appear on the bottom of the screen warning you that Azure Active Directory management is only possible from the new portal starting November 30, 2017…
To add to the injury, the old Azure Portal was not readily accessible for CSP and DreamSpark customers. They were confronted with the dreaded No subscriptions found. message, that forced them to sign up for an Azure AD-only subscription.
What you needed PFWeb for
In the old Azure Portal, when you’d click the MANAGE button in the bottom pane, you would be directed to the PhoneFactor Web (PFWeb) portal and be automatically signed into the correct MFA Provider. Here you can:
- View reports, on usage, blocked user history, bypassed user history, fraud alerts and queued requests. However, these reports are not accessible using an API.
- View server status
- Configure general settings, like the number of attempts to try for an MFA call, the time-out for two-way text messages and the Caller ID used
- Configure authentication caching settings
- Configure custom voice messages to override the default messages played during an MFA call
- Configure notifications for fraud alerts, account lockouts and one-time bypasses
- View the release notes for the latest on-premises Multi-Factor Authentication Server
- Download the latest version of the on-premises Multi-Factor Authentication Server
- Generate activation credentials to connect on-premises Multi-factor Authentication Server installations to the MFA Provider.
- Download Multi-Factor Authentication Software Development Kits (SDKs) for Perl, Ruby, PHP, Java and several versions of ASP.NET (1.1 C#, 1.1 VB, 2.0 C# and 2.0 VB)
On the left side, a pane would allow you to chose between Azure (Default) settings and MFA Server (Default) settings to divide between the two types of authentication.
Now in the new Azure Portal (in Public Preview)
All of the above functionality is now available in the new Azure Portal.
The preview Multi-Factor Authentication settings are located per Azure Active Directory. To go there, simply sign in to the Azure portal as an administrator, select Azure Active Directory from the left navigation pane and then select MFA Server. in the Security section.
However, there are some things that you need to be aware of:
- When you create a new MFA Provider, the tenant drop-down list displays tenant IDs, not the tenant name labels.
- Newly created MFA Providers that you’ve created in the New Azure Portal show up in the Old Azure Portal, and MFA Providers created in the Old Azure Portal show up in the new Azure Portal (as Providers in the MFA Server of Azure Active Directory).
- The new Azure Portal points to the Microsoft Download Center to get the on-premises MFA Server bits. It specifically points to aka.ms/mfadownload.
- Just like in the old portal, when you click on the MFA Provider, you can manage its settings, download the bits and generate activation keys. However, the following functionality is currently missing:
- View the release notes for the latest on-premises Multi-Factor Authentication Server.
- Currently, there is one field to enter e-mail addresses for notifications. In PFWeb, notification could be sent to different e-mail addresses for fraud alerts, account lockouts and one-time bypasses used.
- A couple of new settings have been introduced:
- For users who enter a PIN to authenticate, admins can now set lockout settings (Minutes until account lockout counter is reset and Minutes until account is automatically unblocked) besides the Number of MFA denials to trigger account lockout.
- Authentication caching is now governed through cache levels (User, Application or IP address) and authentication type.
- Fraud Alerts are now configurable through an additional setting: Automatically block users who report fraud. This setting is turned on by default. The Allow users to submit fraud alerts is turned off by default (just like in PFWeb), though. Additionally, a code to report fraud during initial greeting can be customized.
- You can’t download the MFA Server SDK through the new portal.
- The MFA Service settings have been and still are available through various links in the portals, pointing towards the account.activedirectory.windowsazure.com website. The easiest way to go there, I found, is by signing in to the Azure portal as an administrator, selecting Azure Active Directory from the left navigation pane and then selecting Conditional Access in the Security section. Select Named locations in the navigation blade and click the Configure MFA Trusted IPs, which will take you there. There you’ll be able to:
- assign MFA status to individual user accounts
- Allow users to create app passwords to sign in to non-browser apps.
- Enable Skip multi-factor authentication for requests from federated users on my intranet and specify to Skip multi-factor authentication for requests from following range of IP address subnets.
- Make specific authentication methods (Call to phone,
Text message to phone, Notification through mobile
app and Verification code from mobile app) available
or unavailable to end-users. - Allow users to remember multi-factor authentication on devices they
trust, and specify the Days before a device must
re-authenticate, between 1 and 60 days.
Unfortunately, the link at the end of this page to manage advanced settings and view reports, still points to PFWeb…
Concluding
It’s good to see the public preview of Azure Multi-Factor Authentication in the new Azure Portal. Unfortunately, some settings () are missing, because we would love to use the new and improved settings as soon as possible and leave the old Azure Portal behind.
Another good thing is that MFA Providers that you might have created earlier are migrated over to the new Azure Portal and are available for management there. This avoids having to migrate previously deployed on-premises MFA Servers from one ASM-based MFA Provider to a new ARM-based MFA Provider.
Related blogposts
Ten Things you need to know about Azure Multi-Factor Authentication Server
Azure Multi-Factor Authentication Server 7.3.0.3 with lots of improvements
Azure Multi-Factor Authentication features per license and implementation
Azure Multi-Factor Authentication Methods per Supported Protocol
Choosing the right Azure MFA authentication methods
Creating an MFA Provider when you have CSP or DreamSpark
Things to know about Billing for Azure MFA and Azure MFA Server
Login