Microsoft recently documented phishing campaigns abusing OAuth redirect behavior in identity platforms such as Microsoft Entra ID.

The technique does not exploit a vulnerability. Instead, attackers abuse legitimate OAuth redirection logic to deliver phishing pages or malware payloads.

The attack typically begins with a phishing email containing a crafted OAuth authorization URL. The link triggers a login flow against a legitimate identity provider such as Microsoft Entra ID.

Instead of completing the authentication process, the attacker intentionally manipulates parameters in the request (for example by using invalid scopes or manipulated redirect URIs). This causes the OAuth flow to redirect the user to a malicious endpoint controlled by the attacker.

Because the flow starts on a trusted Microsoft login domain, many email and browser defenses allow the link to pass.

In observed campaigns, the redirected page delivered malware payloads such as ZIP archives containing LNK loaders and scripts that eventually executed PowerShell commands and connected to attacker-controlled infrastructure.

Microsoft emphasizes that this technique demonstrates how legitimate authentication mechanisms can be repurposed for social engineering rather than exploiting technical vulnerabilities.

OAuth redirection abuse enables phishing and malware delivery | Microsoft Security Blog

🧑‍💻 Matej’s Take

Microsoft’s report describes how OAuth redirection can be abused in phishing campaigns. To better understand the risk, it helps to look at how this can actually work in practice.

The attacker first registers an application in their own Entra ID tenant.

The key element is the redirect URI, which points to infrastructure controlled by the attacker. This URI will be used later in the OAuth flow to redirect the victim after authentication.

In this example the application has no API permissions configured. This is intentional. Without permissions, the user will not see a consent prompt, which removes an important warning signal and makes the login flow appear completely normal.

The attacker can now generate an OAuth authorization link and deliver it to a target user.

I will not demonstrate how to construct such links in this article, but I personally use the Microsoft Entra Sign-in URL Builder when analyzing authentication flows.

Entra Sign-in URL Builder - Generate Microsoft Entra OAuth 2.0 Authorization URLs

When the victim opens the link, the browser loads a legitimate Microsoft authentication page.

The URL points to the real Microsoft login domain, which makes the flow appear trustworthy.

In this demo the user is asked to select an account because multiple accounts exist in the browser session. In many real environments this step does not even appear. If the user already has an active session, Single Sign-On (SSO) may authenticate the user automatically, which actually makes the attack even smoother for the attacker.

Because the redirect URI points to attacker infrastructure, the user is silently forwarded to a phishing page (in my example the page is part of an AiTM phishing kit).

One practical mitigation is restricting authentication to external tenants.

If users can freely sign in to other Microsoft Entra tenants, attackers can leverage their own tenant as part of the phishing flow. Blocking outbound B2B collaboration by default reduces this exposure.

My recommendation is a deny-by-default approach: block external tenant authentication and allow only trusted partner tenants through an allow list.

Before enforcing this, you should review whether users are legitimately signing in to external tenants.

This can be verified by analyzing Entra Sign-in logs using Defender Advanced Hunting or a SIEM such as Microsoft Sentinel.

🎓 Action for Security Teams

• Review Sign-in logs for cross-tenant authentication.

• Use Defender Advanced Hunting (KQL) or Sentinel to identify external tenant sign-ins.

• Implement deny-by-default outbound B2B collaboration restrictions.

• Allow only trusted partner tenants through an allow list.

• Periodically review allowed tenants.

Microsoft is bringing Passkey Profiles and Synced Passkeys to General Availability in March 2026.

Until now, Microsoft Entra ID supported primarily device-bound passkeys. These credentials are stored on a specific device and cannot be synchronized across password managers or ecosystems such as Apple iCloud Keychain, Google Password Manager, 1Password, or Bitwarden.

Passkey Profiles introduce policy-based control over passkey usage. Administrators can define how passkeys are registered and enforced across users and groups.

Synced passkeys expand usability. They allow credentials to be securely synchronized across devices using supported password managers, improving cross-device experience and reducing registration friction.

The change addresses one of the key adoption barriers of passkeys: usability across multiple devices.

How to Enable Passkey (FIDO2) Profiles in Microsoft Entra ID (Preview) - Microsoft Entra ID | Microsoft Learn

How to Enable Synced Passkeys (FIDO2) in Microsoft Entra ID (Preview) - Microsoft Entra ID | Microsoft Learn

🧑‍💻 Matej’s Take

This was one of the missing pieces in Entra ID. Device-bound passkeys are technically stronger because the credential never leaves the device. However, adoption has been limited.

Users change devices. They reinstall operating systems. They expect portability.

Synced passkeys lower that friction.

Yes, they are slightly weaker than device-bound passkeys from a pure security standpoint. But they are still phishing-resistant and significantly stronger than traditional MFA methods such as OTP codes or push-based authentication vulnerable to advanced phishing attacks.

If the choice is between:

• Synced passkey

• SMS / OTP / weak MFA

The answer is clear.

This change moves Entra ID in the right direction.

Now the question is adoption.

🎓 Action for Security Teams

• Review the GA timeline and Message Center notification (MC1221452).

• Understand the difference between device-bound and synced passkeys.

• Define Passkey Profiles aligned with your risk appetite.

• Pilot synced passkeys with security-savvy users first.

• Update authentication strength policies if needed.

August 2025 Update: The script for exporting Entra ID Enterprise Applications, which I covered in this post, has proven to be extremely useful, mainly because of the HTML export which makes data analysis much easier. Based on that success, I decided to update the existing script for reviewing Entra ID guest accounts. The new version now supports export both to HTML and CSV, allowing for a quicker visual overview as well as easy further data processing

For a while, I had been manually running cmdlets to export guest account reports from Entra ID. These reports were crucial for analyzing and cleaning up inactive accounts, but I often found myself retyping or searching for the right commands. To simplify the process, I created a straightforward PowerShell script to generate a report of guest accounts.

Regularly reviewing guest accounts is important, especially if you’re not using advanced features like Entitlement Management in Entra ID. Identifying and removing inactive accounts helps keep your environment clean and secure.

The goal was to make the task easier:

• Quickly export guest accounts to a CSV and HTLM for further analysis.

• Use bulk delete actions in Entra ID to remove stale accounts.

I primarily focus on analyzing environments and providing recommendations, so I didn’t include any code for deleting guest accounts. I don’t have or need deletion rights, and I wanted to keep the script safe and read-only. However, it’s flexible enough for others to modify if needed.

The Script

You can find the complete script in my GitHub repository. Feel free to download, review, or contribute improvements:

Export-EntraGuestReport.ps1

Before you run the script, you must install the Microsoft Entra PowerShell module

Rich HTML Report Generation

Beyond simple CSV export, the script generates a comprehensive HTML report with interactive features, summary statistics, and visual categorization:

• Summary Dashboard: Key metrics displayed in an easy-to-read card layout

• Interactive Filtering: Search by email, filter by status, account state, and more

• Visual Status Indicators: Color-coded rows for different user states

• Sortable Columns: Click column headers to sort data

• Responsive Design: Professional appearance with modern styling

How to Use the Script

Save and Prepare the Script

Save the complete script as Export-EntraGuestReport.ps1 in your preferred location and ensure you have the Microsoft Entra PowerShell module installed:

Install-Module -Name Microsoft.Entra -Repository PSGallery -Scope CurrentUser -Force -AllowClobber

Basic Usage Examples

Generate both HTML and CSV reports with default settings:

.\Export-EntraGuestReport.ps1

Generate only CSV report for pending guests:

.\Export-EntraGuestReport.ps1 -PendingAcceptanceOnly -CSVOnly

Custom inactive threshold with HTML report only:

.\Export-EntraGuestReport.ps1 -InactiveDays 180 -HTMLOnly

Custom path and filename for comprehensive reporting:

.\Export-EntraGuestReport.ps1 -ExportPath "D:\Reports" -FileName "MonthlyGuestAudit"

Target specific tenant:

.\Export-EntraGuestReport.ps1 -TenantId "your-tenant-id" -InactiveDays 120

Available Parameters

• TenantId: Optional. Specify a particular tenant to analyze

• PendingAcceptanceOnly: Switch to filter only pending guest invitations

• InactiveDays: Customize the inactive threshold (default: 90 days)

• ExportPath: Specify custom export directory

• FileName: Custom filename (without extension)

• CSVOnly: Generate only CSV report

• HTMLOnly: Generate only HTML report

Review the Report

The script will create comprehensive reports with:

• HTML Report: Interactive dashboard that opens automatically in your browser, featuring summary statistics, filtering capabilities, and visual status indicators

• CSV Report: Detailed data export perfect for further analysis in Excel or other tools

• Summary File: Text-based summary of key findings for quick reference

Conclusion

This script makes it easy to generate a report on guest accounts from Entra ID. It simplifies data extraction for analysis and cleanup, and its flexible design lets you adapt or expand it as needed.

It was clear to me that controlling app registration and consent was crucial. In most environments, I managed to enforce that new applications require admin approval before being added. Every time I achieved that, my next comment was always the same.

“Great, but do not forget to check the existing applications because there might already be something risky in there.”

And without fail, the next question I received was: "Okay, but how do we even do that? Do I have to open every single app manually?"

In such cases, I usually pointed people to various scripts or tools that could export data about enterprise apps, helping them make informed decisions about what is safe to keep.

But recently, I started wondering if I could create something like this myself using AI to speed up the process. Since I am not a coder, building a custom tool from scratch was never realistic, so turning to AI felt like the logical way forward.

First, Understand the Basics

Before I could even think about building a reliable report, I realized that I did not fully understand how Enterprise Applications, Service Principals, and App Registrations really work. If I could not explain them clearly to myself, there was no way I could ask AI to help me build a meaningful tool.

At this point, I have to give credit where it is due. Martin Heusser’s blog posts on the topic were a game-changer for me. I read both of his articles multiple times until I felt like I truly understood the concepts. If you are in the same boat, I highly recommend his content because it really helps connect the dots.

What I Wanted to Achieve

Armed with new knowledge, I went back to my script with a clear goal. I wanted a full report of all Enterprise Applications, not just App Registrations.

The reason is simple. I needed visibility over everything tied to my tenant, not only apps registered locally but also external ones, including third-party integrations that can access Exchange Online, OneDrive, and other sensitive Microsoft 365 services. To make the report more relevant, I also added exceptions to filter out certain built-in applications that are not important for my analysis and do not need to show up in the results.

The HTML report includes:

• App Ownership to quickly identify what kind of application it is.

• Has App Registration to show if the app is registered in your tenant and holds active credentials.

• Owners because you need to know who to contact about a specific app.

• Assignment Required an often-overlooked parameter that defines whether users can access the app freely or only when explicitly assigned. For example, by default any signed-in user can query Microsoft Graph for basic directory information unless you restrict it.

• Permissions Overview probably the most critical part, listing what rights the enterprise app or service principal holds.

Adding a Risk Factor

Without some kind of risk score, every app looks equally important, which makes cleanup nearly impossible. So I built a simple logic into the script that analyzes permissions and assigns a Risk Score and Risk Level to each app. These factors are customizable. You can tweak them to match your own risk appetite.

The Result

After a few weeks of trial and error, many iterations with AI, testing, and fixing mistakes, I finally ended up with a script that I felt was worth sharing. I have already used it to analyze several tenants, and let me tell you, the first report will probably hurt. But at least you will have a starting point for cleaning up potentially dangerous apps in your environment.

One thing is certain. Right now, most environments are flying blind when it comes to Enterprise Applications in Entra ID. And that needs to change.

Where to Get the Script

If you want to try this out in your own environment, the script is publicly available on my GitHub.

You can find it here: Get-EntraIDServicePrincipalReport.ps1

Use the script, change it if you want, adapt it to your needs, it is up to you. I will keep improving it and may even incorporate feedback from the community.

Subscribe now

Prerequisites and Installation

Before running the script, ensure you have the required Microsoft Graph PowerShell modules installed:

• Install only necessary modules

Install-Module -Name Microsoft.Graph.Authentication,Microsoft.Graph.Applications,Microsoft.Graph.Identity.SignIns,Microsoft.Graph.Identity.DirectoryManagement,Microsoft.Graph.Reports -Scope CurrentUser -AllowClobber

• Or install the full umbrella module

Install-Module -Name Microsoft.Graph -Scope CurrentUser -AllowClobber

The script automatically requests the minimal required permissions:

• Application.Read.All

• Directory.Read.All

• DelegatedPermissionGrant.Read.All

• RoleManagement.Read.Directory

Available Parameters

The script offers several filtering options to optimize performance and focus analysis:

# Basic usage - analyze all Enterprise Applications 
.\Get-EntraIDServicePrincipalReport.ps1

# Filter for apps with permissions only 
.\Get-EntraIDServicePrincipalReport.ps1 -OnlyWithPermissions

# Minimum permission threshold 
.\Get-EntraIDServicePrincipalReport.ps1 -MinimumPermissions 5

# Focus on internal applications with registrations 
.\Get-EntraIDServicePrincipalReport.ps1 -OnlyWithAppRegistrations

# Analyze only service principals without registrations 
.\Get-EntraIDServicePrincipalReport.ps1 -OnlyServicePrincipals

# Custom output location 
.\Get-EntraIDServicePrincipalReport.ps1 -OutputPath "C:\Reports\MyReport.html"

# Use external risk configuration 
.\Get-EntraIDServicePrincipalReport.ps1 -RiskConfigPath "risk-rules.json"

The script includes intelligent pre-filtering that applies quick filters first, skipping detailed analysis for applications that don't meet criteria. This significantly improves performance when analyzing large tenants with hundreds of applications.

Report Output

The generated HTML report provides:

• Executive-style dashboard with key metrics and risk statistics

• Interactive filtering directly in the HTML report by risk level, ownership, assignment requirements, and permission types

• Sortable columns for risk score, permission counts, and other attributes

• Detailed permission breakdowns with expandable sections

• Ownership analysis including gap detection for governance

• Credential status tracking for active secrets and certificates

• Risk factor explanations for each application's security posture

The report automatically opens in your default browser and includes comprehensive legends explaining all indicators and classifications.

One of the most crucial security controls in Microsoft Entra ID, alongside the implementation of Multi-Factor Authentication (MFA), is managing the conditions under which users can initially register or modify their MFA methods. Why is this important? Primarily because it's not realistic to assume that all users will proactively complete their MFA registration especially when organizations introduce various exceptions or conditions that only selectively require MFA (unfortunately a common scenario).

A highly effective approach to deploying MFA within Microsoft 365 environments is through Conditional Access policies, which allow granular control over MFA enforcement under specific conditions. However, a challenge arises when users never encounter conditions that trigger their initial MFA registration due to such policy exceptions. For instance, many companies implement policies requiring MFA only when users access resources from untrusted locations. Practically, this means users who always work from trusted or known locations may never be prompted to register for MFA if additional policies enforcing MFA registration are not implemented.

This situation creates a vulnerability where an attacker who manages to compromise user credentials could potentially register MFA methods on behalf of the legitimate user. Therefore, it's crucial to strictly control MFA registration. One option is creating a Conditional Access policy that requires MFA specifically when accessing the Security Info Registration page.

Control security information registration with Conditional Access | Microsoft Learn

However, this introduces a chicken-and-egg problem: how can a user perform MFA registration if MFA itself is required to access the registration process? A practical solution to this scenario involves the Temporary Access Pass (TAP). TAP provides a temporary password that allows users to bypass MFA requirements temporarily, enabling them to register their MFA method securely even from untrusted locations or devices.

Create a Temporary Access Pass | Microsoft Learn

However, the primary focus of this blog is not the initial registration process itself, but rather the potential exploitation of MFA registration policies. Adopting a Zero Trust mindset means embracing the "Assume Breach" principle. With this perspective, let's consider a scenario where an attacker employs an Adversary-in-the-Middle (AiTM) attack to steal session cookies containing MFA tokens.

How does this look in practice? Here's a demonstration showing login attempts through a phishing page. Hint: One login attempt is legitimate, while the other is fraudulent. Can you spot the difference?

The URLs are deliberately obscured to make it impossible to identify which page is legitimate and which is phishing. While there are several methods to stop such attacks, our focus here is on the Assume Breach strategy and specifically on preventing attackers from maintaining persistent access after an initial breach. Typically, after successfully stealing session tokens, attackers aim to secure persistent access. As previously mentioned, the policy designed to protect users in this scenario is a Conditional Access policy requiring MFA for security changes.

But does this policy truly protect us in the described scenario?

As demonstrated, even with this Conditional Access policy in place, the attacker successfully added an additional MFA method. Why? Because the attacker already possessed a session token previously authenticated through MFA.

Personally, I prefer a Conditional Access policy that blocks access to Security Info Registration unless specific conditions, such as trusted devices or trusted locations, are met.

The challenge with this policy is that it does not allow the use of TAP as a bypass option, as mentioned earlier. Whether this limitation is a showstopper is up to you to decide.

Of course, this represents just one potential exploitation scenario among many, and it should never serve as the sole control measure. The goal of this blog was primarily to highlight the importance of adopting an Assume Breach approach, prompting us to consider scenarios from the perspective of what an attacker could potentially achieve in our environment and how we can proactively prevent it.

Now, after revisiting that post, I conducted a personal assessment to see how well these principles have been adopted. The results? While we've made progress by limiting cloud access for synchronized accounts, enforcing Conditional Access policies for corporate-compliant devices, and even adopting phishing-resistant MFA for admins, significant security gaps remain. Many organizations still struggle with fundamental security hygiene, even when robust security measures don’t necessarily require high-end licensing like Microsoft 365 E5.

Reflecting on that original blog post title, Protecting Microsoft 365 from on-premises attacks, I now ask: Is this the only risk we should be concerned about? Given today’s hybrid environments, where more organizations integrate on-premises services with cloud infrastructure, the reverse concern protecting on-premises infrastructure from Microsoft 365 attacks is just as pressing.

Microsoft Intune and Device Management Risks

Microsoft Intune adoption is growing, and more organizations are using it to manage privileged workstations. The key question is: Who manages these high-privilege devices? Observations vary from internal service desks to external partners many of whom authenticate using only basic MFA, which we know can be bypassed. Worse still, there are cases where MFA isn’t enforced due to misconfigurations or oversight. Although Microsoft has committed to requiring MFA for Intune portal access, these security changes are rolling out slower than expected.

Planning for mandatory multifactor authentication for Azure and other admin portals

From an attacker’s perspective, Intune provides a powerful method for deploying malware to compromise an organization’s infrastructure.

Defender for Endpoint: A Potential Backdoor?

Defender for Endpoint’s Live Response functionality enables remote command execution. If an attacker gains admin access, they can leverage this tool to execute malicious scripts, even placing a device in troubleshooting mode to disable Defender components. Now, imagine if this compromised device is a domain controller. The consequences would be catastrophic.

Mitigating the Risks: Revisiting Zero Trust Principles

The foundational principles from the Protecting Microsoft 365 from on-premises attacks blog still hold today. The key to defense is adopting a Zero Trust mindset. This means incorporating more signals, enforcing stricter controls, and maintaining proactive monitoring.

Enforce Phishing-Resistant MFA for Administrative Accounts

Given the rise of AiTM (Adversary-in-the-Middle) attacks, conventional MFA is no longer sufficient. We must require phishing-resistant MFA methods such as:

• Certificate-Based Authentication (CBA)

• Windows Hello for Business

• Passkeys

Enable passkeys in Authenticator for Microsoft Entra ID

However, simply registering a phishing-resistant method is not enough. Conditional Access policies must enforce these methods via Authentication Strengths, ensuring weaker MFA options aren’t available in case of a compromise.

Secure Administrative Access with Privileged Access Workstations (PAWs)

Organizations should mandate that administrative roles only authenticate from Privileged Access Workstations (PAWs). Traditionally used for on-premises environments, PAW principles can and should be extended to Microsoft 365. Some implementation approaches may include:

• Dedicated physical or Azure Virtual Desktop (AVD) based PAWs for cloud-centric admin tasks.

• Conditional Access enforcement ensuring that privileged accounts can only sign in from approved, compliant PAW devices.

Privileged Identity Management (PIM): Beyond Just Approval Workflows

While many view Privileged Identity Management (PIM) as merely requiring approval workflows, its core value lies in enforcing Just-In-Time (JIT) access.

When admins request access, additional security checks are conducted:

• They must prove their identity again (e.g., through phishing-resistant MFA).

• They must use a compliant corporate device.

• They receive email notifications when their role is activated and potentially alerting them to unauthorized access attempts.

Final Thoughts

Security isn’t just about implementing advanced tools. it’s about ensuring fundamental hygiene. While we have made progress, organizations continue to struggle with basic security principles that don’t necessarily require high-end licensing. By enforcing Zero Trust, requiring phishing-resistant MFA, securing administrative access through PAWs, and leveraging Just-In-Time access with PIM, we can significantly reduce the attack surface in both cloud and hybrid environments. However, these are just a few examples of necessary security measures, and organizations must continuously evaluate and implement additional controls to stay ahead of evolving threats.

Ultimately, the real question is not only how to protect Microsoft 365 from on-premises attacks, but also how to safeguard on-premises infrastructure from Microsoft 365 compromises.

Microsoft traffic profile is included with the Secure Access Essentials license, which will soon be included in the Microsoft 365 E3 license. 

Let's consider a scenario where an employee attempts to sign in to their personal Microsoft account from a corporate device. With Tenant restrictions V2 and client-side tagging with Global Secure Access, this access attempt will be blocked, ensuring that corporate data is not inadvertently shared with personal accounts.

So, what are the necessary steps to implement this?

First, we need to configure Tenant Restriction in the Microsoft Entra admin center by navigating to External Identities > Cross-tenant access settings. In the Default settings tab, you will find the Tenant Restrictions option. Set access status to block access.

Next, we need to navigate to Global Secure Access and activate Microsoft traffic profile.

If you want to test all the features of Global Secure Access, including Microsoft Entra Internet Access and Private Access, there is a 90-day trial available for the Microsoft Entra Suite license.

After enabling the profile, we need to assign it to a group of users.

NOTE: Access is granted only to users directly in the group and does not extend to nested groups.

We also need to activate Tenant Restriction within the Session Management section under Settings.

The final step is to deploy the client to your Windows devices, which is a requirement to tunnel network traffic to the Global Secure Access service. You can download the client from the Client Download section or directly via this link.

If you plan to deploy the client using Microsoft Intune or other device management tool, you can utilize the following commands:

GlobalSecureAccessClient.exe /install /quiet

GlobalSecureAccessClient.exe /uninstall

Once the client is installed on your device you should check the status and make sure that the Microsoft traffic profile was downloaded. In the system tray, right-click the Global Secure Access Client and select Advanced Diagnostics. In the Forwarding profile, you should see Microsoft 365 rules.

If everything was set up correctly, you should no longer be able to log in to Microsoft Personal OneDrive and Mail. The same restriction should apply if you attempt to use a separate account from an unknown tenant.

Test logging in with a separate account from an unknown tenant:

Of course, there are always exceptions. If you want to allow access to a specific tenant, you need to add the organization first by navigating to External Identities > Cross-tenant access settings and selecting Add organization.

Once the organization is added, you need to configure the tenant restrictions for that specific tenant to allow access.

If you haven't yet tried Global Secure Access, now is the perfect time to explore its capabilities. As Global Secure Access is a comprehensive product, I plan to dive deeper into its features and functionalities in future blog posts. Stay tuned for more insights and tips on maximizing the benefits of this essential security solution.

Microsoft Learn: Administrator reset policy differences.

A two-gate policy is enabled which mandates two forms of authentication evidence (e.g., entering a code from the Microsoft Authenticator app plus an SMS code). While the two-gate policy offers significant protection, it is still possible to disable the default policy to prevent administrators from changing their own passwords using the Update-MgPolicyAuthorizationPolicy PowerShell cmdlet.

First, the Microsoft.Graph.Identity.SignIns Module must be installed. Use the following command to install this package via PowerShellGet:

Install-Module -Name Microsoft.Graph.Identity.SignIns

Once the module is installed, it should be imported, and the Connect-MgGraph cmdlet must be invoked before executing any commands that interact with Microsoft Graph. This cmdlet retrieves the access token through the Microsoft Authentication Library.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes Policy.ReadWrite.Authorization

If you haven't already, you will need to provide consent for Microsoft Graph.

Once connected, we can check the current setting for AllowedToUseSspr, which shows whether administrators of the tenant are permitted to use the SSPR.

Get-MgPolicyAuthorizationPolicy | select AllowedToUseSspr

To disable SSPR for administrators, we need to set the value to FALSE.

$params = @{
allowedToUseSSPR = $false
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $params

The policy takes effect within 60 minutes. Our test confirms that the administrator indeed cannot use the SSPR service anymore.

I hope you find this information useful for improving your administrator’s security.

Upon implementing these security measures, you'll likely encounter a practical challenge: how can admin accounts, now devoid of mailboxes, receive essential notifications for Microsoft 365 environment management? This question becomes particularly pressing in scenarios such as when a user requests admin consent for an app that requires permissions to access organizational data, or when using Entra Privileged Identity Management (PIM), where it's necessary for an admin to be informed about assigned rights directly in their main inbox.

Fortunately, this dilemma has a straightforward solution: the Plus Addressing feature in Exchange Online. This functionality elegantly bridges the gap, ensuring that admin accounts can receive critical notifications without compromising on security protocols.

Microsoft Learn: Plus Addressing in Exchange Online

Plus Addressing in Exchange Online allows us to create unique email addresses for mailbox by adding a plus sign ('+') and a keyword to a standard email address.

How does it work? We simply need to add the address using the format <local-part>+<tag>@<domain> as follows:

In my example, the email address for my administrative account is configured as AdeleV+365.adm@mydomain.com, ensuring that emails are routed directly to my main mailbox at AdeleV@mydomain.com.

A simple test of both scenarios confirms that the mail is delivered to the main mailbox of the user AdeleV@mydomain.com:

This wraps up the key insight I aimed to share through this post: a seemingly minor yet profoundly impactful tip for the efficient management of Microsoft 365 environments.

An intriguing challenge for me was figuring out how to implement a modern login method for Windows devices using a dedicated hardware authentication technique. While smart cards have long been a traditional method of authentication, the question arises: have they become obsolete and unusable in the era of FIDO2 keys? I believe they have not, as they can still effectively cover certain user scenarios.

Using YubiKey and PIV

One of the features of FIDO2 keys is their ability to also function as a "smart card" allowing you to store your own digital certificate on them. This opens up new possibilities and enhances security for Windows device logins.

I personally use the YubiKey 5 NFC, which offers Personal Identity Verification (PIV) functionality.

Before you can store a certificate on the FIDO2 key, several prerequisites need to be met. Among them is the installation of the YubiKey Smart Card Minidriver for Windows which is available here. Additionally, setting a PIN, PUK, and Management Key on the FIDO2 key with YubiKey Manager is necessary to securely store the certificate.

Now that we have our FIDO2 key ready, we need to prepare Certificate Authority templates. Those of you who have used or are still using traditional smart cards are likely familiar with the "Enroll On Behalf Of..." process. The idea is that an administrator can issue a certificate on behalf of a user. For this purpose, we first need to prepare an Enrollment Agent certificate.

Preparing the Enrollment Agent Templates

An Enrollment Agent certificate is used to grant a highly privileged right to issue certificates on behalf of other individuals, including administrative accounts. This certificate must be protected very securely since it grants the high privilege of issuing certificates for others. Enrollment rights should be restricted as much as possible. Additionally, you might want to store the Enrollment Agent certificate in the TPM (Trusted Platform Module) to reduce the risk of theft, or even storing it on a FIDO2 key.

Duplicate the Enrollment Agent template on your Windows Certificate Authority Server and name it accordingly:

Change the Compatibility Settings to the highest operating system version:

Configure Request Handling:

Select Key Storage Provider as Provider Category and Microsoft Platform Crypto Provider to store the certificate in the TPM:

Configure Read and Enroll permissions for your privileged accounts:

Use certutil -store -user My to check if certificate is stored in Microsoft Platform Crypto Provider:

Preparing the Smart Card Templates for FIDO2 key

Now that we have the Enrollment Agent certificate in place, the next step is to issue the Smart Card Template for our FIDO2 key.

Duplicate the Smartcard Logon template on your Windows Certificate Authority Server and name it accordingly:

Change the Compatibility Settings to the highest operating system version:

Configure Request Handling:

Select Key Storage Provider as Provider Category and Microsoft Smart Card Key Storage Provider to store the certificate on FIDO2 key:

Configure Issuance Requirements:

Configure Read and Enroll permissions for your privileged accounts:

Issuing the certificate

Here's how the process of issuing a certificate on a FIDO2 key on behalf of another user typically looks like:

Select the Enrollment Agent Certificate installed previously:

Select the Smart Card Template:

Select a user to whom you want to issue the certificate:

Enter FIDO2 PIN code:

Congratulations! If everything has been set up correctly, you should now be able to successfully log in using a FIDO2 key in a Windows environment.

Smart Card Removal Behavior

One last important setting you may want to configure is the Smart Card Removal Behavior to automatically lock the workstation. To achieve this, you'll need to do two things:

1. Group Policy Setting: Set the GPO (Group Policy Object) policy "Interactive logon: Smart card removal behavior" to the value "Lock Workstation." This policy determines what happens when the smart card is removed from the reader during an active session. Locking the workstation ensures that unauthorized access is prevented when the FIDO2 key is removed.

2. Service Startup: Set the startup type for the Windows service "Smart Card Removal Policy" to automatic. This service is responsible for enforcing the Smart Card Removal Behavior policy.

By implementing these settings, you enhance the security of your authentication process. When a user removes the FIDO2 key, the workstation will automatically lock, safeguarding sensitive data and ensuring that only authorized users can access the system.

Final thoughts

With these final configurations in place, your Windows environment is now equipped with a robust and modern authentication system that combines the benefits of FIDO2 keys with the security features of smart card technology.

msiexec /q /i LAPS.x64.msi CUSTOMADMINNAME=Hulk

Windows LAPS with Microsoft Entra ID now Generally Available!

As Windows LAPS is now build-in directly to supported editions, there is no need for installation, resulting in the absence of the local administrator creation feature.

Microsoft Learn: What is Windows LAPS?

However, this doesn't mean you can't achieve similar functionality through other means. I personally prefer utilizing the Microsoft Intune Remediations feature as it allows managing local accounts effectively with PowerShell Scripts.

Microsoft Learn: About Remediations

The first step in process involves detecting the presence of a specific user on the target machine. In this example, I’m focusing on detecting the existence of the user "Hulk." This can be achieved using PowerShell, and here's how the detection script might look:

$targetUser = "Hulk"
$existingUser = Get-LocalUser -Name $targetUser -ErrorAction SilentlyContinue
if ($existingUser) {
    Write-Host "User '$targetUser' exists."
    exit 0  # Exit with code 0 to indicate success
} else {
    Write-Host "User '$targetUser' does not exist."
    exit 1  # Exit with code 1 to indicate failure
}

In this script, I’m using the Get-LocalUser cmdlet to check if the specified user exists on the machine. If the user is found, the script exits with a success code (0); otherwise, it exits with a failure code (1).

Now, let's move on to the remediation script. If the user doesn't exist, we want to create and enable the user account. The script below accomplishes this by generating a random password, creating the user account, and setting up appropriate account settings:

function Generate-RandomPassword {
    param (
        [int]$length
    )
    $validChars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()_+-=[]{}|;:,.<>?'
    $password = ''
    1..$length | ForEach-Object {
        $randomChar = Get-Random -Minimum 0 -Maximum $validChars.Length
        $password += $validChars[$randomChar]
    }
       return $password
}
$targetUser = "Hulk"
# Check if the user already exists
$existingUser = Get-LocalUser -Name $targetUser -ErrorAction SilentlyContinue
if (!$existingUser) {
    # Create the user account with temporary password and enable it
    $password = Generate-RandomPassword 14  # Generate a random password
    $securePassword = ConvertTo-SecureString $password -AsPlainText -Force
    New-LocalUser -Name $targetUser -Password $securePassword -AccountNeverExpires -UserMayNotChangePassword -PasswordNeverExpires
    Enable-LocalUser -Name $targetUser
    Write-Host "User '$targetUser' created and enabled with a temporary password."
    exit 0  # Exit with code 0 to indicate success
} else {
    Write-Host "User '$targetUser' already exists. No remediation needed."
    exit 1  # Exit with code 1 to indicate failure
}

This script generates a strong, temporary password using the Generate-RandomPassword function. Then, if the user doesn't already exist, it creates the user account with the generated password and enables the account. If the user already exists, the script indicates that no remediation is needed.

Create a script package in Microsoft Intune > Devices > Remediations.

Microsoft Learn: Deploy the scripts packages

Make sure to select Run script in 64-bit PowerShell.

NOTE: Created user is NOT added to local administrators group automatically.

The final step is to add the created user to local administrators group. I’m doing that with Custom OMA-URI Setting:

./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

<GroupConfiguration>
    <accessgroup desc = "Administrators">
        <group action = "R" />
        <add member = "AzureAD\pcadmin@contoso.com"/>
        <add member = "hulk"/>
    </accessgroup>
</GroupConfiguration>

Microsoft Learn: Policy CSP - LocalUsersAndGroups

By combining these two scripts and deploying them through Microsoft Intune's remediation feature, you can effectively manage local user accounts across your environment. This approach not only provides the flexibility to create custom accounts but also allows for automation and consistency in user account management.

Now we can configure Windows LAPS with custom managed local administrator account.

• Beta Channel: Devices set to this channel will be the first to receive new updates. For use in (manual) test environments only and a limited number of devices.

• Current Channel (Preview): Devices set to this channel will be offered updates earliest during the monthly gradual release cycle. Suggested for pre-production/validation environments.

• Current Channel (Staged): Devices will be offered updates after the monthly gradual release cycle. Suggested to apply to a small, representative part of your production population (~10%).

• Current Channel (Broad): Devices will be offered updates only after the gradual release cycle completes. Suggested to apply to a broad set of devices in your production population (~10-100%).

• Critical - Time delay: Devices will be offered updates with a 48-hour delay. Suggested for critical environments only.

I recommend using the Current Channel (Staged) for pilot and Current Channel (Broad) for production devices.

Here's an example of how to configure update channel via Microsoft Intune:

Create a custom setting for Windows devices:

Name the policy and enter description:

Add a new OMA-URI Setting, enter name, OMA-URI: ./Device/Vendor/MSFT/Defender/Configuration/PlatformUpdatesChannel and Integer value for update channel:

• Beta Channel = 2

• Current Channel (Preview) = 3

• Current Channel (Staged) = 4

• Current Channel (Broad) = 5

• Critical - Time delay = 6

Assign the policy to a group of devices.

UPDATE: You can now configure update channels with Microsoft Defender Antivirus policy via Microsoft Intune

Use PowerShell cmdlet "Get-MpPreference | select PlatformUpdatesChannel" to check Platform Update Channel value on a device:

By taking control of Microsoft Defender updates through a well-structured rollout process using Microsoft Intune, organizations can mitigate risks, ensure stability, and maintain a secure environment. Hopefully this article has demonstrated the importance of controlled rollouts and provided a step-by-step guide for implementing a successful update management policy. With the right approach, organizations can stay ahead of potential issues while keeping their devices protected and optimized.

Microsoft Learn: Manage the gradual rollout process for Microsoft Defender updates

TAGs are an essential feature in MDE that allow us to organize and manage devices based on specific criteria such as location, department, or device type. Typically, TAGs are added through the MDE portal after the devices are onboarded or with Group Policy if devices are domain joined. Manual process can be time-consuming, especially when dealing with a large number of devices.

To streamline the onboarding process and automatically apply TAGs to workgroup-joined devices, we can incorporate a simple command into the onboarding script itself. By including this command, the devices will be automatically tagged during the onboarding process, eliminating the need for manual intervention later on.

Here's an example of how to add a TAG to devices using the onboarding script:

1. Open the onboarding script file in a text editor

2. Locate the :SCRIPT_START section

3. Add a command to assign a TAG to the device. For instance, if we want to assign a TAG "Workgroup", we can use the following command:

REG add "HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging" /v Group /t REG_SZ /f /d "Workgroup" >NUL 2>&1

Save the modified onboarding script.

By including the command to assign a TAG within the onboarding script, the devices will be automatically tagged during the onboarding process. This saves time and effort since we don't have to manually assign TAGs through the MDE portal afterward.

Remember to customize the TAG based on your organization's requirements. You can create a TAG that align with your device categorization needs, such as geographical location, department, or device role. By leveraging TAGs, you can effectively manage and organize your devices within Microsoft Defender for Endpoint.

In conclusion, onboarding workgroup-joined devices in Microsoft Defender for Endpoint requires manual intervention through a local script. By incorporating a command to assign TAGs within the onboarding script, we can streamline the process and automatically categorize the devices during onboarding. This ensures efficient device management and eliminates the need for manual TAG assignment through the MDE portal.