Identity as a security perimeter
When using services available from anywhere, like cloud services, the security risk associated with user credentials increases drastically. In an on-premise infrastructure, companies are protected by the physical perimeter and attackers are forced to either physically connect to the on-premises network or overcome obstacles like firewalls. But when it comes to cloud-based services, attacks can be performed from outside the company’s perimeter, lowering the risk for the attacker.
This fact means that companies thinking about moving parts of their services or infrastructure to the cloud, needs to increase focus on user credentials and authentication mechanisms. We believe that one of the first considerations should concern the implementation of 2 factor authentication.
Multi Factor Authentication – cloud managed
Microsofts 2 factor authentication service is called Multi Factor Authentication and is built in to Azure and Office365. For most common scenarios, MFA can compete with any 3rd party vendor when it comes to Azure or Office365 logins. MFA is a requirement for Global Administrators – due to the high risk associated if these privileges are compromised but for all other user types it needs to be activated. Although not a requirement, Mindcore recommends enabling MFA for all accounts as “enforced” and configure the service so that the end-user impact is reduced. Enabling the service on all users and NOT configuring the options will require users to perform MFA at every login (see figure 1.)
 |
| Figure 1 – User that are set to “enforced” are required to perform MFA unless they are exempt by other configurations. |
For instance, a login to Skype for Business and Exchange online on the same device will require the user to perform MFA 2 times. This lowers the user experience and reduces the risk that users will use other services to do day to day tasks, a risk that needs to be taken into consideration.
Reducing MFA prompts
There are 2 options available to reduce the amount of MFA prompts for users – time delay and trusted locations.
Time delay is configured by enabling the service to remember users MFA logins and when configured, Every MFA login will prompt users if they want to wait 1-60 days to next MFA prompt. The amount of days is centrally configured for all users. Flow is described in see figure 2.
It is strongly recommended that this option is only enabled, if users are informed that they should only save credentials on trusted devices.
 |
| Figure 2 – If configured – users can delay MFA prompts for 1-60 days, reducing the number of prompts. |
The other way to reduce the number of MFA prompts, is by configuring trusted locations. This is done by adding the external IP addresses for the company’s locations to the configuration of MFA. Every login that the MFA service receives, comes with information on where the login comes from (based on the external IP address) and if the IP is on the trusted locations list, it accepts the login without prompting the end-user for MFA (see figure 3.) Only exception is if the user holds the Global Administrator privilege – Global Administrators are always prompted for MFA.
 |
|
Figure 3 – Logins from trusted locations are not required to perform MFA authentication
|
Modern Authentication
Implementing MFA as a secondary authentication method, requires clients to be able to handle Modern Authentication methods. Modern Authentication is an authentication type that is based on ADAL (Active Directory Authentication Library) and amongst other features enables the use of MFA.
Microsoft´s Office suite has supported Modern Authentication from version 2013 and most browsers support it, but in a lot of commonly used mobile mail applications it is not supported. Which means that for example mail synchronization could break in some scenarios. For example, a user on an android device using the native mail client, could be able to download mail when in the office on the corporate connection but as soon as the device disconnects from the corporate connection, the mail stops synchronizing. Because the corporate connection is a trusted location MFA was not required, but as soon as the device disconnects MFA is required.
So, implementation of MFA requires some analysis of use scenarios and should be taken into consideration.
MFA on-premise installation
In environments where 3rd party 2FA solutions are already in place, it is possible to replace the existing solution with an MFA Server or an MFA plugin for a Network Policy Server.
The difference between them is that MFA Server allows for local management and customization, while an MFA NPS plugin only handles the authentication and user management is done in Azure MFA. Which to choose depends on the scenario.
Azure MFA Server
An Azure MFA Server installation is fully capable of leveraging 2FA on-premise for most organizations. It provides central management connected services, multiple authentication protocols, central management of user settings, ability to customize registration webpage, supports high availability and much more. Because of this it is often the choice for advanced configurations.
Azure MFA NPS Plugin
For a company that does not need all the options provided with the Azure MFA Server and where all devices support using Radius as the second factor, an NPS Plugin could be the solution. While lacking some of the features, it requires substantially less to administer on-premise. All users are required to register to the MFA service in Azure, like they would do when using MFA for cloud-services. If they are already registered no other registration is required.
Authentication flow
For both services the Authentication flow is the same. Users are required to login to on-premise services like they are used to but will be requested to do a second authentication (see figure 4.)
As depicted, it is possible to forward first and second authentication to the MFA Server or NPS Server or handle the first authentication on the device (vpn concentrator, wifi, router etc) and forward the second authentication to the MFA Server or NPS Server.
 |
| Figure 4 – First AuthN will take place at either the device or be passed to MFA, second AuthN will be handled by MFA and if it succeeds, the MFA service (NPS or Server) will send Access Granted will be initiated. |
Licensing
MFA Server and NPS plugin becomes available with Azure AD Premium P1 or P2 licensed tenants.
Conclusion
Every organization planning on moving parts of their infrastructure or services to the cloud, needs to consider the increased threat to user identities and implement security features to meet these threats. Implementing 2 factor authentication is probably the most important decision and should be on top of any security agenda before enabling any cloud services.
When considering MFA, it is important to weigh in user satisfaction. Companies implementing security features and not considering how it is affecting their users, often experience that users start using 3rd party options for tasks they consider difficult or even impossible to achieve, using company services. For Microsoft cloud services, Mindcore recommends using Azure Conditional Access as a way to achieve a high level of security with a minimal impact on users.
