Why you need to enable Multi Admin Approval in Intune

Intune has a new feature called Multi Admin Approval (MAA) which is extremely important to enable because it reduces the risk that an attacker who compromises an Intune Admin can use that privilege to distribute ransomware to all endpoints. A memory trick to always remember this is imagine your sibling shouting “MAAAAA!” when you are doing something wrong. That is like what should happen when an admin account is taken over, goes rogue and tries to distribute ransomware in your environment – someone should be shouting MAA!!! Lol!

You can navigate to this important control here:

To create an access policy, your account must be assigned the Intune Service Administrator or Azure Global Administrator role.


You will need to create two separate access policies, one for Apps and one for Scripts.


Select the group containing the members who can approve requests for create, edit, assign, and delete scripts.


When any Intune admin attempts to create or change a script/app that is protected by an MAA access policy, Intune will queue the request after the user enters a business justification as shown here:


Intune won’t apply the change until a different account explicitly approves it.
Approvers can see the requests in Intune Tenant Admin > Multi Admin Approval
Only administrators who are members of an approval group that’s assigned a protected resource in an access protection policy can approve changes. Approvers can also reject change requests.

This feature is in public preview, but it is pretty awesome!!

To learn more about what happens next, such as what the requestor and approval experience, check out the Microsoft documentation here:


Microsoft Entra Authentication Methods Policy Convergence

“Complexity is the worst enemy of security, and our systems are getting more complex all the time.” – Bruce Schneier (@schneierblog)

Microsoft recently launched “Authentication Methods Policy Convergence” (Public Preview). This is so very exciting because it exponentially reduces the complexity of multifactor authentication. I was part of the private preview program, and I’m very happy to see this feature going public.

In my book, “Securing Microsoft 365 (2nd Edition) (2022)” I write about the imperative of Zero Trust and how to configure multiple factors of authentication to prevent unauthorized access to Microsoft 365. Three years ago, I wrote about the most common MFA myths and misconfigurations that I have seen in customer environments.

As of the fall of 2022, only 25% of all authentications are protected by MFA in Microsoft Entra (Azure Active Directory). So this new simplified experience of configuring MFA is such an incredibly welcome improvement. I believe we will see a significant improvement in MFA adoption over the next two years. The reason it will take some time is because the policy convergence is not yet a forced experience, meaning we will still see customers configuring MFA in multiple portals until they learn about policy convergence. And that is why I am writing this blog article, to get the word out! In January 2024, the legacy multifactor authentication methods portal and SSPR authentication methods will be deprecated. Until then, it is very important to note that the new Authentication methods are evaluated in addition to the legacy MFA and SSPR policies.

One of the biggest improvements that I like about policy convergence is that not only do we get a single place to configure MFA authentication methods, but we also get the ability to target individuals and groups. Previously, if you wanted some users to have the ability to use SMS/TEXT or Voice then you had to enable it for the entire tenant. With policy convergence, we now have the ability to be more selective!

You can migrate your existing policies to the new blade at your own pace. Make sure to follow the latest Microsoft Documentation: “Migrate MFA and SSPR policy settings to the Authentication methods policy for Azure AD” and “ Manage authentication methods for Azure AD

Support for Hardware OATH tokens and Security Questions is coming soon. If you’re using hardware OATH tokens or Security Questions (for SSPR), do not proceed further. 

After you capture available authentication methods from the policies you’re currently using, you can start the migration.Open the Authentication methods policy, click Manage migration, and click Migration in progress. You’ll want to set this option before you make any changes as it will apply your new policy to both sign-in and password reset scenarios.

Screenshot of Migration in progress.

Then, update the new auth methods to match the methods you are currently using, or take this as an opportunity to eliminate the less secure methods. If you do that, just be aware that the user will be forced to register for the more secure methods at their next sign-in (so it would be wise to inform your helpdesk and send an email to your users about what they are going to expect!).

After you update the Authentication methods policy, go through the legacy MFA and SSPR policies and remove each authentication method one-by-one. Test and validate the changes for each method. Then go back to the migration process and mark the migration as complete.

Screenshot of Migration complete.

Be aware that it can take up to 15 minutes before changes are reflected.

After reviewing Jan Bakker’s (@janbakker_) blog post on this same subject, I realized that I could not improve upon it any further, so I just want to direct my readers there because he did such a good job on describing the experience in such great detail: https://janbakker.tech/goodbye-legacy-sspr-and-mfa-settings-hello-authentication-methods-policies/

For example, Jan points out “Ensure you have also enabled the combined registration portal for SSPR and MFA before using the new policies. Microsoft should have already enabled this feature, starting Sept. 30th, 2022, but I still see tenants where this is disabled.”  I too have seen customers with that disabled, so here is the setting that Jan shared on his post:

CISA Minimum Viable Secure Configuration Baseline for Microsoft 365

The Cybersecurity and Infrastructure Agency (CISA) in the United States of America is responsible for providing guidance to all United States government agencies and critical infrastructure.

On October 17th 2022 an initial draft (version 0.1) was released (here) for the minimum security configuration that “SHALL” or “SHOULD” be applied to Microsoft 365 Defender. 

The draft guideline states:

“Generally, use of Microsoft Defender is not required by the baselines of core Microsoft 365 products (Exchange Online, Teams, etc.); however, some of the controls in the core baselines require the use of a dedicated security tool, such as Defender. This baseline should not be considered a requirement to use Defender, but instead used as guidance for how these requirements could be met using Defender, should an agency elect to use Defender as their tool of choice. In addition to these controls, agencies should consider using a Cloud Access Security Broker to secure their environments as they adopt zero trust principles”

So in other words, if you are going to use Defender to secure Microsoft 365, then CISA has provided guidance on minimum security.

After reviewing the recommendations, my first suggestion to CISA is to update the title of this document to reference the specific product name that they are issuing guidance for. For example, the cover page states “Microsoft 365 Defender” which refers to a suite of many products, whereas the baseline recommendations included in the document seem to only reference one single Microsoft product: Microsoft Defender for Office.

In other words, if CISA intends to issue security baseline recommendations for the entire suite of M365 Defender, then this initial baseline is lacking recommendations for Defender for Endpoint, Defender for Identity, and Defender for Cloud Apps.

Let’s review each of their recommendations for a MDO security baseline.

Baseline 2.1 “Preset Security Profiles SHOULD NOT Be Used”

The very first recommendation is that you “SHOULD NOT” use the preset email security profiles in Microsoft Defender for Office (MDO) (Standard or Strict) which means you must instead customize each EOP + MDO setting.

CISA states “the preset security profiles are inflexible.“

Fortunately, they did not use the “SHALL” language because many organizations would benefit from the Standard and Strict preset profiles. These profiles will be adjusted over time by Microsoft to respond to threats on behalf of organizations.

For organizations that lack experience administering Office 365 then the preset policies will be less risky than untrained administrators attempting to customize each and every setting, because complexity is the enemy of security. The preset policies are very good in my opinion and they can greatly simplify the administration of email security policies if an organization decides to use Defender for Office.

So I recommend that CISA change this to the opposite, so that Preset Profiles SHOULD Be Used. Otherwise, CISA is going to have to come up with guidance on dozens of individual settings, and their guidance will quickly become obsolete as Microsoft continuously innovates and develops new features and old settings are deprecated.

Another reason that CISA should recommend to use the Preset Profiles is because the US Federal Government should have a clear standard that all email security settings are based on. If they are going to say “don’t use the preset configuration” then they need to exhaustively list a recommended configuration for each setting that has security implications. 

If CISA does not agree with the recommendations in the Strict or Standard policies, they should at least state which specific recommendations they disagree with.

Baseline 2.2 Data Loss Prevention

This recommendation is more strongly worded, that DLP “SHALL” be enabled. In other words, you don’t have a choice, get ‘er done!

However, it does not specify which confidence level should be used to block PII (Credit Card, TIN or SSN). For example, a high confidence block of SSN requires a strongly formatted SSN (xxx-xx-xxxx) and a keyword like “SSN” within 300 characters of proximity, whereas a low confidence block of SSN is an unformatted string of numbers like xxxxxxxxx (resulting in higher false positives, but provides a lower risk of data leakage). Presumably this nuance is left to the individual agency to decide but that should be made more clear in this document.

Two of the bulleted requirements require Endpoint DLP to be configured:

  • “A list of apps that are not allowed to access files protected by DLP policy SHOULD be defined”
  • “A list of browsers that are not allowed to access files protected by DLP policy SHOULD be defined.”

I recommend that the document call out that these two bulleted items require the Endpoint DLP product because it has the higher M365 E5 or G5 license. Endpoint DLP is considered a ‘Suite Feature’ included when the M365 E5 package is owned. As far as I know it is not possible to license Endpoint DLP separately.

The section 2.2.4 Implementation neglects a very important step of onboarding computers into Endpoint DLP. This should be added in order for the two bulleted items above to work properly.

Section 2.3 Common Attachment Filter Policy incorrectly states that a MDO Plan 1 or Plan 2 license is required. That is not correct, the common attachment filter is freely included in all EOP license plans (any license plan bundled with Exchange Online). Basically, just mirror the language used in section 2.6.3

Section 2.4 – the Zero Hour Auto Purge for malware should be changed so that it reflects the stronger “SHALL” language because when a file signature matches Malware, it is bad and in my experience Microsoft has a very low false positive rate for malware. Also later in section 2.6.1 the ZAP feature is listed as having the SHALL language, so section 2.4 should be updated to match the 2.6.1 policy recommendation for consistency.
Also, it incorrectly states that a MDO Plan 1 or Plan 2 license is required. That is not correct, the ZAP feature is freely included in all EOP license plans (any license plan bundled with Exchange Online). Basically, just mirror the language used in section 2.6.3

Section 2.7 – I recommend Safe Link policies use the stronger “SHALL” language rather than the current “SHOULD” language, effectively for the same reason why Safe Attachments in Section 2.8 have the “SHALL” language.

What is the value of moving file servers to SharePoint Online or OneDrive?

I was recently asked “How can I help convince my leadership that moving files from on-premises file servers to M365 (SharePoint, OneDrive, Teams) is the right move to make?”

In my opinion, migrating files to the cloud will improve both compliance and security, productivity, and IT Operations.

Compliance benefits

  • eDiscovery – search everything – emails, files in SharePoint, files in OneDrive, files in teams, etc – all from one search interface. How do you accomplish that today with file shares? 
  • DLP – protect everything – in a single DLP policy! Audit, Encrypt, Block, Policy Tips, etc.
  • Retention – Retain or Delete, how easy is that to do in a file share? In the cloud, it is a few mouse clicks to enable retention.

Security benefits

  • Ransomware rollback protection. If ransomware encrypts a file, you can roll back to the previous version. While this is possible with on-premises SAN/NAS technology, those on-premises solutions are vulnerable to cyberattack – if the attacker can sign into the SAN or NAS they can (and have often) deleted those snapshots and backups. Whereas in the cloud, the versions are essentially ‘immutable’ when a retention policy is in place, which allows you to restore to a prior version of the file.
  • Auditing. Who changed that file? Who shared that file? Who deleted that file? Who moved that file? Who has accessed that file? How easy is it for you to answer these questions on a file share today?  M365 provides a web interface to search audit logs, whereas in on-premises you need a way to scrape that from event viewer. Event viewer can be purged whereas the audit logs in M365 are immutable. 
  • Patching – who is patching your file shares? Do you do it immediately when security updates are released? What if Microsoft handled that for you when you move your files into the cloud? You get your nights and weekends back!  Let Microsoft be responsible for patching their servers!

User Productivity benefits

  • Collaboration – your users can simultaneously edit files with a dozen people changing the spreadsheet at the same time. You can’t do that on a file share today.
  • Mobility. Users can access their documents on the go from their mobile phones! Can’t do that with file shares today.
  • External sharing. Users can more easily share large documents, whereas today when they try to share a file, if it is too large, the email bounces back and the user will then often use their personal DropBox account to send large files.

IT Benefits

  • Storage doubles every 18 months. Instead of purchasing more SAN storage next year, just move it to the cloud. EACH USER gets 5 Terabytes in OneDrive – PER USER!! That’s an incredible amount of scalability. 
  • Laptop Backups. Similar to above, if you are not backing up a laptop today, and the user loses it or it is stolen, or the hard drive crashes, then this can be improved by moving the data to the cloud and then configuring synchronization to the laptop, so that files are continuously backed up. For example, the user’s “U:\ Drive” or wherever they store files on a file share today – those should be moved to OneDrive and then synced to laptops for continuous backups.
  • Disaster Recovery, High Availability – BUILT IN. How do you do this today? Do you replicate your SAN storage off site? That means your storage costs are DOUBLE, or TRIPLE if you do an offline backup. In the cloud, all that is handled for you – replicated to multiple data centers, backed up, etc
  • Upgrades. No more worries about expensive upgrades from 2008 R2 to 2012, then a few years later, upgrading again to 2016… to 2019.. it’s endless!  All that goes away.

Those are just a few of the benefits of migrating file shares to SharePoint Online, OneDrive for Business or Teams. I did not do any research, those are literally off the top of my head. I am sure I could come up with a lot more if I had the time!

I recommend checking out Alex Field’s article “The File Rules of Fields” or File Server Migrations to Microsoft 365. https://www.itpromentor.com/five-rules-of-fields/

Microsoft increases email security market share 18%

Back in 2019, I wrote a blog post (here) explaining how to identify the primary DNS MX records used by the Fortune 500 and then use that to identify email security vendor market share. Then in 2020, I wrote a post that Microsoft had dipped 12% while others gained.

So when I ran the analysis again today, I was surprised to see that Microsoft had gained 14 new clients since the last time I had run the report two years ago. During that same time ProofPoint and Cisco also gained while Symantec and others lost market share amongst the Fortune 500.


I am asked all the time by customers “Is Microsoft “good enough?” Yes, but you don’t have to take my word for it. Microsoft just received the “AAA Protection Award” from SE labs—a testing lab focused on assessing the efficacy of security solutions. They evaluated email security vendors against a range of real-world email attack scenarios. They found 97 percent of emails that contained threats were blocked. That’s pretty good! Read more about Microsoft’s results here.

At the 2019 Microsoft Ignite Conference, there was a presentation (available on YouTube here) given where Microsoft made a pretty compelling case: since they sit behind other email security vendors (when mailboxes are hosted in Exchange Online) they can see when they could have blocked threats that others missed. In the graphic below, they claim to catch 400% more things than competitors!

MSFT misses 0.002% whereas competitors are missing 0.01% and 0.012% (that is a difference of 400%). To be sure, the competitors will make similar claims since Microsoft is unaware of their unique catch rates.

Industry analysts such as Forrester have named Microsoft a leader in email security (read the announcement here)


10 Reasons why I recommend Microsoft for Email Security

There are ten reasons why I recommend Microsoft email security to my clients:

  1. Automatic signal sharing with Microsoft Defender for Endpoint
  2. Protect malicious links in SharePoint, OneDrive, Teams, Office on the Web, and Microsoft 365 Apps for Enterprise
  3. Safe Documents
  4. Lateral Phishing Protection
  5. Native Link Rendering
  6. Anti-Phishing (prevent Business Email Compromise)
  7. Automatic Investigation and Response
  8. Threat Explorer
  9. Threat Hunting & XDR Integration
  10. Performance

Automatic signal sharing with Microsoft Defender for Endpoint

Whereas most other email security vendors create a silo of malicious file hashes when threats are detonated, Microsoft is able to share this information with Defender for Endpoint within milliseconds because they share a common back-end “the Intelligent Security Graph (PPT Download link).”


Protect malicious links in SharePoint, OneDrive, Teams, Office on the Web, and Microsoft 365 Apps for Enterprise

Whereas other email security products are typically limited to scanning only external emails, Microsoft is able to scan hyperlinks and attachments throughout the productivity applications. This is important because hackers often like to hide their malware in trusted locations such as OneDrive or SharePoint because most organizations cannot afford to block these root URLs since they are also used for business productivity.

Safe Documents

Safe Documents uses the cloud backend of Microsoft Defender for Endpoint (MDE) to scan documents opened in Microsoft Office. Users do not need to have MDE installed for this to work.

License Requirements: M365 E5 Security or full M365 E5. It is not included in the EOP or MDO license plans, you need the E5 Security step-up license (added to M365 E3) or the full M365 E5 suite.

Enable with PowerShell here:
Set-AtpPolicyForO365 -EnableSafeDocs $true –AllowSafeDocsOpen –$false

Learn more about Safe Documents in the Microsoft Documentation (here).

Lateral Phishing Protection

When mailboxes are hosted in Exchange Online, Microsoft is able scan internal emails, whereas other security vendors are usually limited to only when emails are external. Microsoft uses its advantage of hosting the email platform to perform this internal email scanning. This is valuable because if a hacker compromises an account, they will often use that to attack other internal accounts since it will look more trust worthy.

Learn how to configure safe link policies in the Microsoft Documentation (here)

Native Link Rendering

When email security vendors re-write the URL back to their service, they do so because they want to examine the hyperlink at the time of click for threats. Since Microsoft ‘owns’ the Outlook clients (mobile, web, desktop) then they can render the original URL when the user hovers over the link. This is helpful so that the user can use their security awareness training to better judge if the link appears suspicious. Other vendors cannot achieve this since they do not own the most popular email client used in the enterprise.

Read about the announcement of Native Link Rendering back in 2018 (here)

Anti-Impersonation in Anti-Phishing Policy to prevent Business Email Compromise


You can configure anti-impersonation for up to 350 users in a single policy (multiple policies are permitted). The idea is to protect your top executives from having their Display Name impersonated, or domain names that look similar to the domains you own. 

Learn more about how to enable Anti-Phishing in the Microsoft Documentation (here)

Automatic Investigation and Response

After a potentially malicious URL click is detected in email, or is manually reported by a User or Admin, or a SOC analyst who integrates AIR with their SIEM uses the Office 365 Management Activity API, then an automated playbook is launched to perform a deep investigation of these 13 steps:

1.Analyze user activity anomalies in Microsoft Cloud App Security, and check the attachment against Defender for Endpoint

2.On-demand check of domain reputation from Microsoft’s ISG and external threat intelligence sources

3.Detect anomalies based on historical mail flow sending patterns for users in your organization

4.Extract indicators from header, body and content of the email for investigation

5.Investigate mail delegation access for user mailboxes related to this investigation

6.Investigate any violations detected by Office 365 Data Loss Prevention (DLP)

7.Detect intra-org and outbound malware or phish originating from users in your organization

8.Investigate any mail forwarding rules for user mailboxes related to this investigation

9.Email cluster analysis based on (1) header, (2) body, (3) content and (4) URLs

10.On-demand check on URL reputation from Microsoft’s ISG and external threat intelligence sources

11.On-demand check of IP reputation from Microsoft’s ISG and external threat intelligence sources

12.Email cluster analysis based on outbound mail flow volume patterns

13.On-demand detonation triggered with Defender for Office 365 for emails, attachments and URLs

Then an Administrator is presented with an option to soft delete the emails:


Learn more (here).

Threat Explorer

Assuming you have permissions and licensing, you can navigate to Threat Explorer directly here: https://security.microsoft.com/threatexplorer

Threat Explorer is very powerful. You can:

  • See malware detected by Microsoft 365 security features
  • View phishing URL and click verdict data
  • Start an automated investigation and response process from a view in Explorer
  • Investigate malicious email, and more

Learn more about Threat Explorer (here).

Also the “Email Entity Page” is also helpful in investigations. Check it out (here). The Microsoft documentation is very good (much better than competitor products).

Threat Hunting & XDR Integration

If you know Kusto Query Language (KQL) then you can construct queries across inboxes, devices, identities, etc. You can also integrate with a SIEM such as Sentinel for true XDR. Sample queries:

  • Finds PowerShell activities that occurred right after an email was received from a malicious sender
  • Find the first appearance of files sent by a malicious sender among all devices or inboxes
  • Find emails containing open redirect URLs, for example:


| where Url matches regex @”s?\:\/\/(?:www\.)?t\.(?:[\w\-\.]+\/+)+(?:r|redirect)\/?\?”

  • Logons to a device after a malicious email was received, for example:


| where Timestamp > ago(7d)

| where ThreatTypes has_cs “Malware”

| project EmailReceivedTime = Timestamp, Subject, SenderFromAddress, AccountName = tostring(split(RecipientEmailAddress, “@”)[0])

| join (


| where Timestamp > ago(7d)

| project LogonTime = Timestamp, AccountName, DeviceName

) on AccountName

| where (LogonTime – EmailReceivedTime) between (0min .. 30min)

Learn more about advanced hunting (here)


The speed at which Microsoft can detonate attachments is impressive.

Most emails are detonated for threats within 5 to 12 seconds.


Can you imagine what it would take for you to build enough virtual machine capacity in your on-premises network to open every single email attachment received in a separate virtual machine to analyze behavior?

Here is a report you can use to analyze the latency introduced by Microsoft’s email security: https://security.microsoft.com/mailLatencyReport

Try it out

If you are using a 3rd party email security solution, you can begin to evaluate Microsoft Defender for Office now. You will need an E5 Trial subscription and you need to be a member of the Security Administrator and Exchange Administrator roles to set up the evaluation.
Learn more here: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/try-microsoft-defender-for-office-365?view=o365-worldwide

Make the switch!

Already convinced? You can plan to make the switch from a 3rd party email security vendor to Microsoft by following the excellent documentation (here) or contacting a Microsoft Partner (such as Patriot! (My company!) – contact us at [email protected] for a quote!).

Azure AD Combined Registration (SSPR + MFA) is rolling out by October 2022

I’m starting to get questions from my customers about what to expect when the Azure AD “Combined Registration” feature is enabled beginning October 2022 and completing January 2023. On March 29th 2022 Microsoft published MC348869 in Message Center.

A bit of background: In April 2020, the combined security information registration experience for registering both multi-factor authentication (MFA) and self-service password reset (SSPR) was made available as an Opt-in feature but otherwise disabled by default.

We quickly encouraged everyone to enable it, for two primary reasons:

1. It simplifies the user experience so they register once instead of twice (when both MFA and SSPR are both used)

2. FIDO2 Security Key registration requires that the combined registration feature is first enabled. this is required if you want to go passwordless, as FIDO2 has use cases that augment WH4B and Authenticator app such as shared workstations or when employees don’t want to use their personal phones for authentication. It also adds URL binding so that users don’t get phished. But this isn’t a blog about FIDO2, I just can’t help use every opportunity to evangelize it – go use it now!

As you can see, even if you don’t use SSPR, it’s still valuable to enable the FIDO2 passwordless experience.

So does this change impact me?

Did you create your tenant after August 15th 2020? Then no, this change won’t impact you because any tenant created after that date already has Combined Registration enabled.

You can go check out to see if you have it enabled by following these instructions:

1. Sign into the Azure portal (portal.azure.com) with a privileged role such as “user administrator” or “global administrator.”
2. Go to Azure Active Directory > User settings > Manage user feature settings.
3. Under “Users can use the combined security information registration experience” – record the setting.

If it is not enabled for all users, then you can select an option to enable it for a pilot group so that you can record the new user experience , and then decide if you want to update your onboarding documentation.
Microsoft provides screen shots of the new experience here:

Will there be any user impact?

Another customer recently asked me: “I use ADFS, and I do not have SSPR enabled, will this change impact me?”

Potentially yes. If your tenant currently does not have combined registration enabled, and you do not have SSPR registration currently required, then it is possible that if your SSPR authentication factors are not aligned to your MFA factors then I could imagine a scenario where users would be required to register for the SSPR factors when this change rolls out in October.

So my advice for everyone is to go into your SSPR authentication factors and try to align those with your MFA factors.

What makes this a confusing time (June 2022) is that there are three separate areas to configure factors.

1. Legacy MFA portal


2. SSPR Portal
Authentication methods selection in the Azure portal

3. Azure AD Portal – Authentication Methods


Eventually I expect these portals to be consolidated into the 3rd portal. Until then, sometimes users are not aware of all these locations to configure the authentication experience.

And recently, one of my customers was confused by the 3rd portal, thinking that “text message” had to do with using SMS as 2FA


No – remember this list of options are for passwordless authentication methods. So this text message option is for using your phone number instead of username, then you type in the code on your phone instead of a password (useful for retail environments where there is high employee turnover). Learn more about SMS-based authentication as an alternative to usernames/passwords in the Microsoft documentation here. Just because it is there, does *not* mean you should turn it on! Remember, SMS based authentication is weak! See Alex Weinert’s article “It’s Time to Hang Up on Phone Transports for Authentication.

Pre-registering MFA in M365

This article describes how to make the user onboarding experience into MFA as smooth as possible by pre-registering MFA methods.

Disclaimer: This article only applies to organizations that have decided to use Phone Number for verification. This is not recommended but in some organizations, they are unable to avoid this for a variety of reasons. If you want to learn why phone number verification is weak, check out the Microsoft Article: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/it-s-time-to-hang-up-on-phone-transports-for-authentication/ba-p/1751752

The most ideal scenario would be to deploy Passwordless MFA, such as Windows Hello for Business, Authenticator App, FIDO2 Keys, or Certificate (Preview). You might issue a Temporary Access Pass to allow users to register passwordless methods without knowing the password to the account.

For more information on planning a passwordless deployment, click here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-deployment

Ever wonder what is required to pre-register a user for Phone or Email?

The “Authentication Methods” page displayed in Portal.Azure.com > Azure Active Directory > Users, allows you to pre-define the phone number that would be used for MFA.


If you use Always ON MFA, then you can set the user to Enforced. This can be automated with a GUI or PowerShell, or the preferred method would be to use a Conditional Access Policy (if you have Azure AD P1 or EMS E3 or M365 E3).


Their very first sign-in experience would be:


Otherwise, if you only populate the Mobile Phone field (such as in on-premises Active Directory, and then it synchronizes to Azure AD) then the user’s first sign-in experience will be to verify that the number shown is correct.



To populate the mobile phone using PowerShell, you can use PowerShell as described here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-authenticationdata

But if you want to populate the Authentication Phone Number (so that the user can skip the registration page) then the PowerShell gets a little bit more involved.

Method 1 – Using PowerShell version 1 as described here: bulk Pre-registration for Azure MFA for more Seamless Single Sign on and smooth for MFA roll out – Microsoft Tech Community

Method 2 – Using MS Graph as described here: Pre-configure Authentication Methods for end users in Azure AD – Identity Man (identity-man.eu)

At this point I would strongly encourage you to enable number matching notifications and then enable the registration campaign.

Note: After September 30th 2022, the Combined Registration feature will be enabled in all tenants worldwide. This means that if you are using Self Service Password Reset, then the registration experience for users will be combined.
Therefore, instead of waiting until September, I would enable that feature now so that you can update your end-user facing documentation and user communications once rather than twice.
Learn more about Combined Registration here: Combined registration for SSPR and Azure AD Multi-Factor Authentication – Azure Active Directory | Microsoft Docs

Lapsus$ gains access to OKTA and Microsoft

Today (3/22/2022) both OKTA and Microsoft released statements about a threat actor named LAPSUS$ (Microsoft tracks as DEV-0537) who gained access to both organizations. In the last 90 days, this same threat actor has claimed victims including Impresa, NVIDIA, Samsung, Mercado Libre, Vodafone, and most recently Ubisoft.

In the case of Microsoft, the attack appears to be limited to portions of source code related to Microsoft’s Bing, Bing Maps, and Cortana.

“This week, the actor made public claims that they had gained access to Microsoft and exfiltrated portions of source code. No customer code or data was involved in the observed activities. Our investigation has found a single account had been compromised, granting limited access. Our cybersecurity response teams quickly engaged to remediate the compromised account and prevent further activity. Microsoft does not rely on the secrecy of code as a security measure and viewing source code does not lead to elevation of risk. The tactics DEV-0537 used in this intrusion reflect the tactics and techniques discussed in this blog. Our team was already investigating the compromised account based on threat intelligence when the actor publicly disclosed their intrusion. This public disclosure escalated our action allowing our team to intervene and interrupt the actor mid-operation, limiting broader impact.”

I recommend reading Microsoft’s write-up on this incident as it gives a detailed glimpse at the threat actor’s TTPs. For example, the threat actor is paying employees to gain access to victim networks.

However, in the case of OKTA, it appears the attack was more substantial based upon the 8 screen shots that LAPSUS$ made public (here).

The original official statement from OKTA seems to contradict what the hacking group is claiming.

“In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provide”


The laptop of a support engineer appears to have been compromised. The attacker would have the ability to reset passwords and Multi Factor Authentication for users.

Then Zack Whittaker reported that OKTA reported 366 corporate customers were impacted.


Brian Krebs reported that the ringleader of LAPSUS may be a 17-year-old from the city of London, England, who goes by the handle WhiteDoxbin with a net work of $14 million (300 BTC).


The BBC is quoting that seven people between the ages of 16 to 21 have been arrested.

OKTA Recommendations

1. If you are an OKTA customer, active Incident Response Plans, assume compromise happened between January 16 to 21

2. Collect and retain related logs. Okta System Logs are only available for a limited time (90 days) so you should download those immediately.

3. Hunt for evidence of suspicious password resets or changes to MFA on or around 1/16 to 1/21

4. Rotate Okta privileged passwords.

5. Look at the Okta Admin Console app in particular

legacyEventType eq “app.generic.provision.assign_user_to_app”

the “app.generic.provision” event type

and to identify any users granted access to other apps.

Another event worth checking on is “security.threat.configuration.update” to see any changes to Okta’s behavioral threat detection.

SIEM rules



PowerPoint Rehearse with Coach

Today I discovered a PowerPoint feature called Rehearse with Coach.

Since I do lot of customer facing presentations, I thought I would give this a try and see what this feature is all about.

You can find it inside PowerPoint’s Slide Show Menu.


After clicking Record, then just talk to yourself a bit as if you were presenting to an audience. When you are done it will give you several tips for improvement, or in my case, validate that I am nailing it! j/k


– Pace is VERY important! 130 words per minute is just about right. Too fast, people can’t follow you. Too slow, then you’re boring!

– Fillers. This is something I struggle with a LOT. I often will use filler words like “ummmm” or “you know” without even thinking about it!

– Repetitive Language. I used to work with an employee who would say the phrase “business outcome” in every other sentence. It started to lose meaning because not everything has a business outcome!

– Inclusiveness. I sometimes catch myself saying “You Guys!”  This is a bad habit I am still trying to break and I look forward to improving in this area.image

– Pitch! Avoid being monotone! As you can see the longer I spoke, the more I drifted to the dreaded monotone!

– Originality.  Don’t just read the text on the slide, but instead use this as a guide for story telling!

Pretty cool stuff. I really appreciate how Microsoft continuously adds cool features like this into PowerPoint and other Office products.

Availability: Microsoft Apps for Enterprise Version 2012 (January 5 2021) https://docs.microsoft.com/en-us/officeupdates/current-channel#version-2012-january-05

More Information https://support.microsoft.com/en-us/office/rehearse-your-slide-show-with-presenter-coach-cd7fc941-5c3b-498c-a225-83ef3f64f07b

How to use Intune Device Enrollment Restrictions to block “Second Wave Phishing”

Microsoft recently published an article (here) describing a new phishing attack where attackers will attempt to bypass Azure AD Conditional Access Policies configured for ‘Require Compliant Device.”


When an attacker obtains the 1st factor credentials (username and password) they will be greeted by a warning message that informs them that they cannot sign-in due to a conditional access policy. But here is the irony,  the warning message informs the hacker exactly how to bypass the block, step by step! (To be fair, the warning message was designed to help users enroll their devices.. but still.. in this day and age, we don’t need to be giving novice hackers free advice on how to bypass our security controls!)


So after the attacker realizes that Conditional Access has been configured to require Intune Compliance, now all the hacker has to do is find a device to enroll into Intune. The attack consists of a hacker logging into a virtual machine they control somewhere, and then they Azure AD Join it to the target organization (with MDM Auto Enrollment), or Azure AD Register with Device Management (Intune) because they have obtained the username and password of the user. Perhaps the user had MFA enabled on their account, but the user has  accidentally authorized the attacker to logon via MFA Push Notification or Phone Call (this happens a lot actually, so you should switch users to Code Match, or wait for Microsoft to roll it out which is coming soon).

It’s worth noting that the way the article was originally written, it made it seem like the registration or Azure AD join itself would be a security concern, but it is not, because as soon as you reset the password of the user, then the primary refresh token is invalidated. Applications with Continuous Access Evaluation will be revoked within 15 minutes (at most) and legacy apps may take up to 60 minutes. You can also create an Azure AD Conditional Access Session policy to limit session lifetime too.

The other issue I had with the article is that it said the problem happens when MFA is not enabled for Device Registration or Azure AD Join. While this can help reduce the risk of it happening, it doesn’t prevent it. There is a better setting in my opinion that does a better job of preventing it which is blocking device registration of personal devices into Intune.

Endpoint.Microsoft.com > Devices > Enroll Devices > Enrollment Device Platform Restrictions


This is a setting that you can apply to All Devices, All Users, or you can scope to selected groups (devices or users). It will prevent the hacker from joining a device to Azure AD and then becoming auto-enrolled. The setting is called Enrollment Restrictions and you set it to block personally owned devices from enrolling into Intune (Ideally you would do this for all device types, not just Windows). This is what I recommend unless you have not yet configured Autopilot or other methods of enrolling devices into Intune. Otherwise, then you must follow the recommendation from the Microsoft article which is to require MFA for enrollment https://portal.azure.com/#blade/Microsoft_AAD_Devices/DevicesMenuBlade/DeviceSettings/menuId/


In my opinion, blocking personal device enrollment into Intune is by far the most secure way to go because it really cuts at the heart of what the attacker is trying to do which is to bypass the CA Policy that requires Intune Compliance. Remember: A rogue device that is AAD Registered or AAD Joined is not a threat to your organization, it’s better to think of it as an extension of the user’s identity that enables that user to achieve SSO. When there is no network transport to the internal network (no VPN) then it’s equally fragile to a password reset of the user’s credentials. Think of it this way: without Intune enrollment, these other device states cannot move laterally into the target network to perform the ‘second wave phishing campaign’ described in the Microsoft article. Or to be more verbose, since a Conditional Access Policy Grant Control cannot factor Registered Device or AAD Join device status, it can only filter based on Intune Compliance or Hybrid Domain Join.

The second option is to limit MDM auto enrollment is to scope specific groups rather than ALL users.


I don’t recommend this because it will have unintended side effects for things like Windows 365 or Autopilot.

What is Device Identity

One of the most confusing things about all of this is what is Device Identity in Azure AD?

Devices that are Azure AD registered are typically personally owned or mobile devices and are signed in with a personal Microsoft account or another local account.

Azure AD Joined
Devices that are Azure AD joined are usually owned by an organization and are signed in with an Azure AD account belonging to that organization. They exist only in the cloud. By default, nothing would prevent a user from being able to Join their personal machine in this manner (and that is why I believe Enrollment Restrictions to block “Personal Devices” are important to consider, as it would block people from Azure AD Joining their devices).

Hybrid Joined
Devices that are hybrid Azure AD joined are owned by an organization and are signed in with an on-premises Active Directory Domain user account belonging to that organization. This account is then in an OU that is synced to the Cloud, and Conditional Access Policies can then use this to device state as a Grant Control.


See also https://o365blog.com/post/devices/

What prevents a rogue user from categorizing their personal device as corporate owned to bypass policy?

Or what if someone has no problem with their personal device being managed by their corporation? Maybe their organization pays them a stipend (this is becoming more and more common as a pseudo-BYOD or hybrid BYOD). In these scenarios, if you configured Device Enrollment Restriction then you will block an individual user from enrolling ANY device into Intune, since it will always default to personal. So then how would a user enroll a device? Short answer, by themselves they wouldn’t – they will need someone to pre-register it for them such as AutoPilot or an AD GPO to enroll Windows device as a corporate device. Other device types like iOS, Android, or macOS allow you to enter a serial number or IMEI but that option is not available for Windows.

Important Side Note: This forum post illustrates what happens when you configure enrollment restrictions to block Personally owned devices to Block but then neglect to manually change Autopilot devices to Corporate. They will get error 80180014 because they forgot to set the Autopilot devices to Corporate. https://techcommunity.microsoft.com/t5/microsoft-intune/error-80180014-due-to-device-restrictions-for-windows-autopilot/m-p/1155809

Seeing Device Enrollment Restriction in Action

If you attempt to enroll a device when Enrollment Restrictions are configured to block personal devices then there is no way I could find to circumvent this control, which is AMAZING because that is what we want to achieve to prevent a hacker from enrolling a device into Intune and bypassing Conditional Access Policies that limit authentication to only compliant devices.


Then in the Event Viewer Log Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin you will get Event ID 52

“MDM Enroll: Server Returned Fault/Code/Subcode/Value=(DeviceNotSupported) Fault/Reason/Text=(Device Identifier not preregistered).”

Require MFA for Device Registration

The Microsoft article states that enabling MFA for device registration would prevent this attack. The reason I don’t like this as the *only* control is because users can still accidentally approve a push notification, or they might have a man-in-the-middle phishing attack like EvilGinx. So keep this ON, but don’t rely on this as the *only* control.


If you want more granularity you can set the setting above to No and then configure it in Conditional Access Policy to force MFA when registering or joining


The Microsoft article also correctly points out that Intune enrollment can be restricted to an IP range via Conditional Access Policy. This would only work if remote users already have a VPN established with force-tunnel (whereas split-tunnel is much more common).


Relying on conditional access policies to requires compliant devices without also restricting enrollment into Intune through the various methods described in this article can lead to the attacker bypassing Conditional Access Policies that require Intune Compliance, leading to unauthorized access to SaaS apps or network resources. For example, in the worst case scenario, “Second Wave Phishing” would happen if Auto MDM Enrollment happens after an AAD Join or Device Reg (‘enroll only in device management”) setting, then a VPN configuration is automatically pushed down to the device, and then the AAD Joined machine is able to connect to other network resources. Ouch!


I should also point out that Microsoft recently created a Conditional Access Overview page that can help you spot other misconfigurations.



Get Help

Head over to the Microsoft Technical Communities to ask questions and get free peer support:


I am always interested in feedback. If you feel I got it wrong or if you would do it differently please DM me on Twitter at @ITGuySocal