This article is contributed. See the original author and article here.

 


Conditional Access Adoption


 


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


 


Morne1102_0-1603304050721.png


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.


 


Morne1102_1-1603304050730.png


 


Note: after the migration, the get-msoluser query should not retrieve any result.


MFA will be disabled. 


 


Morne1102_2-1603304050742.png


 


Morne1102_3-1603304050752.png


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.


 


Morne1102_4-1603304050756.png


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.


Morne1102_5-1603304050760.png


 


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://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-mfa-policy


 


https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-cloud-apps


 


https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-mfa-policy


 


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


 


https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates#convert-users-from-per-user-mfa-to-conditional-access


 


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

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: