Quick recap on the blog series & high-level challenges:
This blog forms part of a series showcasing the impact SMC has had in securing our customer’s cloud-based identities. If you haven’t read the 1st blog, which covers the background to this series, I highly recommend you give it a read first. Link below:
How the Microsoft Mission Critical Team helped secure AAD
Below is a high-level overview of our customer’s challenges. (This is covered in more detail in the initial blog.)
- Hundreds of Risky Sign-ins have been reported every day.
- More than 1 million incorrect username and password attempts were made in just a month (Password Spray attacks).
- Numerous phishing emails were detected by the M365 team.
- Numerous impossible travel alerts were also detected.
- Numerous sign-in attempts were detected from legacy Browser using weak authentication.
Additionally, there has been several security related incidents reported in the environment.
Immediate business requirement to address some of the challenges above:
- Secure Identities accessing cloud-based resources from regions outside of the customers geographical business area.
- Mitigate credential and or identity theft as far as possible.
- Implement the use of a granular and specific policy-based solution.
- Automation of a user registration process.
Understanding the causes of the challenges:
At the time of the initial engagement the customer had a “per user” base MFA deployment with only admin staff included. This presented a few difficulties moving forward looking at the problem statement, namely:
- Administration: the admin page is separate to the Azure portal - making administration confusing and cumbersome.
- Troubleshooting: there is no sign-in log reference to verify MFA - causing troubleshooting to become a nightmare. (In order to understand this difficulty, you must understand user states please click the link here: Understanding User states: Docs)
- Non-flexible Per user: MFA will apply pretty much everywhere and there isn’t really any control or policy to dictate how its applied…
It is clear that Per User MFA would not suffice in this situation.
Solution to the challenges: Conditional Access to the rescue
Since the customer has an Azure Active Directory P2 licence we could leverage Conditional Access based MFA and Identity Protection for the MFA registration.
First the “Per user” MFA state had to be migrated to Conditional Access. The following steps can be taken to achieve this:
PowerShell can be used to query the user state e.g. below.
Get-msoluser -UserPrincipalName 'DKLopez@M365x529362.onmicrosoft.com' | Select-Object -ExpandProperty StrongAuthenticationRequirements
As can be seen the “State” is enforced. [Understanding User states: Docs]
To migrate, disable MFA. Sample scripts can be found here: Per-User MFA to Conditional Access.
Note: after the migration, the get-msoluser query should not retrieve any result.
MFA will be disabled.
Fig 1: Confirmation after migration.
Identity Protection
After all the target users were migrated, in order to enforce MFA registration we assisted in setting up our new Identity protection policy (Azure Active Directory > Security > Identity Protection > MFA registration policy).
The MFA registration policy was set to apply to newly created dynamic groups. These groups are populated dynamically based on a set of attributes that is created via MIM upon account creation.
As expected, our users were prompted for MFA registration upon interactive logon.
Users that had already registered will not be prompted for re-registration.
Fig 2: Security info (aka.ms/mfasetup or mysignins.microsoft.com)
Conditional Access & MFA
The same Dynamic groups as mentioned above were used with our Conditional Access policy (Azure Active Directory > Security > Conditional Access. Excluding Service and break glass accounts) to enforce MFA for all cloud apps along with a location-based condition excluding our “trusted” MFA IP’s.
Confirmation of conditional access policy being applied can be seen in the screenshot below. The User will be prompted for MFA.
Fig 3: Sign-ins Conditional Access
Education as a crucial part of the solution:
Education formed a crucial part in the success of this project. Before we embarked on a user enablement process with the customer an extensive education campaign was kicked off. This lasted several weeks before any non-admin or end user account was migrated to use the conditional access MFA policy or identity protection MFA registration.
Some great sample documentation can be found here to educate end users on the coming changes and process involved in MFA registration.
Useful Links:
https://www.microsoft.com/en-us/download/details.aspx?id=57600&WT.mc_id=rss_alldownloads_all
https://www.microsoft.com/en-us/security/business/identity/mfa
At this point I want to thank you for reading and please do keep an eye out for upcoming follow up posts.
NOTE: The features and guidelines implemented in this case was specific to this customer’s requirements and environment, this is not a “General” guideline to enable any of the above-mentioned features.
Mornè Naude
Customer Engineer
get-schwifty
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.