If your Modern Workforce uses only passwords to get access to company resources, kiss your data goodbye
(and maybe your job).
In the previous blog, I quickly went over the evolution of passwords to multi-factor authentication, yet passwords are still the most common method of authenticating. Despite that, they are also the most vulnerable and get exploited every day. Most end-users choose easy passwords and use the same passwords for multiple sign-ins to different devices and services. To provide an additional level of security for your company’s data and resources, you must require your end-users to utilize multi-factor authentication. Traditionally, multi-factor authentication uses both a password, which should be strong, and an additional verification method. The verification method should be based on something that is not easily duplicated, like a smartphone or something uniquely biological, such as fingerprints.
Azure Multi-Factor Authentication
Deploying and using Azure Multi-Factor Authentication is one of the easiest and most effective ways to increase the security of your company. For your end-users, it sounds like a complicated process, but as IT professionals, we know that it is easier than it sounds. When your end-users attempt to log in to a device or service with their password, they will get a request for a code, that code will be sent to their mobile phone via SMS or voice call. They then type that code into the prompt they received after typing their password, and now they have access to all your company’s resources, including Azure servers and Microsoft 365 services. With the uniquely biological option, users will be prompted for a fingerprint rather than a code. The third option is a combination of the two methodologies we already talked about. This Microsoft centric method employs an app called Microsoft Authenticator, which is published in both the Android and Apple stores.
Azure Multi-Factor Authentication works with the Microsoft Authenticator app in three different ways, notifications, verification code, and passwordless login. With notifications, your end-user types their username and password into the device they are logging into, and then the Microsoft Authenticator app sends a notification asking them to approve the login. The end-user chooses to approve if they invoked the login attempt otherwise, they choose to deny. If they choose to deny, they can mark the request as fraudulent. The verification code option, end-users will type their username and password into the device they are logging into and they will be prompted to enter a verification code. A verification code is sent to Microsoft Authenticator installed on the end-user’s mobile phone. The end-user just needs to enter that verification code into the prompt on the device they are logging into and they will be granted access. The verification code is also known as one-time passcode (OTP) authentication. The passwordless login has the same procedure as the previous two, but instead of approving the login or typing a code, your end-user uses their mobile phone to verify it is them by using their fingerprint, face, or PIN. Let’s shift the conversation to how these authentication options get enabled on the back end of Azure Multi-Factor Authentication.
There are multiple ways in which you can enable Azure Multi-Factor Authentication that is included in Microsoft 365—utilizing the Security Defaults, creating Conditional Access Policies, or managing Azure MFA for each user account. The latter is highly discouraged because of high end-user frustration, and it is extremely hard for the IT teams to manage. For those reasons, I will only discuss the first two options.
Security Defaults is a new feature in Microsoft 365 under the paid or trial subscriptions. This option is exactly what it sounds like, Microsoft 365 comes with the Azure MFA Security Defaults turned on. With the Security Defaults turned on, it requires all your end-users to use Azure MFA with the Microsoft Authenticator app and blocks all legacy authentication. Your end-users have 14 days to register for Azure MFA with the Microsoft Authenticator app from their smartphones, which begins from the first time they sign in after security defaults have been enabled. After 14 days have passed, the end-user won’t be able to sign in until Azure MFA registration is completed. Security defaults ensure that all organizations have a basic level of security for user sign-in that is enabled by default. You can disable security defaults in favor of Azure MFA with Conditional Access Policies.
Conditional Access Policies
Conditional Access Policies are a set of rules that specify the conditions under which sign-ins are evaluated and allowed. As an example, end-user accounts that are members of a group that are assigned the Exchange, user, password, security, SharePoint, or global administrator roles, the end-user is required to authenticate using Azure MFA before being allowed access to company resources. This type of policy will enable your IT team to require Azure MFA based on group membership, rather than trying to configure individual user accounts for Azure MFA when they are assigned or unassigned from different roles. You can also use Conditional Access Policies for more advanced capabilities, such as requiring Azure MFA for specific apps or that the sign-in is done from a compliant device, such as a laptop running Windows 10.
When I started this series of blogs, I mentioned that there were five reasons to transition your Modern Workforce from Office 365 to Microsoft 365. Well, this has been a high-level description of reason number 2, Azure Multi-Factor Authentication. Microsoft has significantly invested in securing their products and ecosystem, so much so they were named a leader in five different security categories of the Gartner Magic Quadrant. I have been around Microsoft for over 20 years in many various capacities, and I have to say Microsoft has stepped up its security game in a big way. Even though this is reason number 2, this should be the most compelling reason for you to transition your Modern Workforce. Next week we will go over reason number 3, Device and App Management. Until then, stay green.
Click here for more information.
Click here to read about Microsoft and Gartner’s Magic Quadrant.
- Do you support persistent and non-persistent WVD?
- Can we move from a traditional Microsoft Client Server environment to Windows Server?
- Can we get rid of our on-premise domain controllers and move to Azure Domain Services?
- Does WVD support MAC OS, either Virtual Mac OS or Remote Mac OS?
- Students need to connect with both Windows and Mac computer Labs remotely. How do we do this?