Using a FIDO2 Security Key Over RDP to Windows Server 2022: On-Prem, Hybrid and Entra-Joined

Posted on July 2, 2026 by Thomas.Marcussen

“I want to RDP into a Windows Server 2022 and log in with my FIDO2 security key instead of typing a password.” It sounds like a single feature you turn on. It is not. Whether it works at all depends on one thing most people skip past: what your server and your client are joined to.

Before you touch a single setting, you also need to be clear about which of two completely different things you actually want, because they share the word “FIDO2” and almost nothing else:

Authenticate the RDP logon itself with a FIDO2 key – passwordless sign-in to the remote server.
Redirect a FIDO2 key into the session so a web app or app inside the RDP session can use WebAuthn, while the key stays plugged into your local machine.

These have different requirements and different failure modes. Let me take them in order, and for the first one walk through all three join states.

First, the one that trips everyone up: a FIDO2 key is an Entra credential

This is the single fact that makes the rest of the post make sense. A FIDO2 security key is registered in Microsoft Entra ID. It is not, by itself, an on-premises Active Directory credential.

So when you log on to a remote server with a FIDO2 key, two things have to happen:

Entra ID authenticates the key.
Something has to turn that into a Kerberos ticket the on-prem world (and the server) understands.

That second step is where the join state decides your fate.

Entra-joined

The cleanest case. If both your client and the target are Microsoft Entra joined, FIDO2 sign-in over RDP works with the modern RDP stack (the web-account-selector flow) on current Windows 10, Windows 11 and Windows Server 2022 builds.

The catch with servers: pure Entra join is not supported on Windows Server. Server SKUs do not Entra-join the way a client does. So in practice “Entra-joined target” applies to Windows 10/11 remote hosts, and your Windows Server 2022 box lands in the hybrid scenario below even when the rest of your estate is cloud-first.

What you need:

Client (and where applicable the host) Microsoft Entra joined.
FIDO2 enabled as an authentication method in Entra ID > Authentication methods (see Microsoft’s FIDO2 enablement guide), with the user in scope and a key registered.
Current Windows builds on both ends and an up-to-date RDP client.

For an Entra-joined client signing into an Entra-joined Windows 10/11 host, there is no Kerberos-trust plumbing to configure – it largely just works once the method is enabled.

Hybrid-joined (this is where Server 2022 actually lives)

Because Windows Server 2022 cannot be pure-Entra-joined, hybrid is the realistic target join state for a server. Both the client and the server are Microsoft Entra hybrid joined – joined to on-prem AD and registered to Entra ID.

Here you must build the bridge that turns the Entra FIDO2 authentication into an on-prem Kerberos ticket. That bridge is Microsoft Entra Kerberos, deployed as cloud Kerberos trust:

Run the Entra Kerberos setup to create the Microsoft Entra Kerberos Server object in your on-prem AD. It shows up as a special computer object (effectively a read-only-DC-style KDC object) that lets Entra ID issue partial TGTs for your AD domain.
Configure Windows Hello for Business cloud Kerberos trust via Intune or Group Policy so the FIDO2/WHfB credential is allowed to request those tickets.
Enable the security key sign-in credential provider on the machines. On Entra-joined clients this is on by default; on hybrid-joined devices you turn it on explicitly – via Intune (Authentication method / “Enable security key sign-in”) or the equivalent ADMX policy Turn on security key sign-in under Computer Configuration > Administrative Templates > System > Logon.

With cloud Kerberos trust in place, the flow is: key authenticates to Entra, Entra issues a partial TGT, the on-prem DC completes it, and the server gets a Kerberos logon it trusts. Service tickets and authorization stay on your on-prem domain controllers – you are not moving authorization to the cloud, only the initial credential.

If FIDO2 RDP “authenticates but won’t log on to the server,” cloud Kerberos trust is almost always the missing piece.

On-prem only (no Entra at all)

Here is the honest answer: the native FIDO2 credential provider does not work for on-premises-only devices. Microsoft is explicit about this. No Entra, no FIDO2 sign-in – because there is nothing to issue the Entra side of the credential.

That does not leave you stuck, but it does mean changing the question. Your realistic options are:

Use the key as a smart card. Many FIDO2 keys also carry a PIV/smart-card applet. Stand up AD CS (your on-prem PKI), issue smart-card logon certificates onto the key, and you get certificate-based passwordless RDP using the long-standing smart-card logon path. RDP already knows how to redirect a smart card reader into the session. This is “passwordless RDP with a security key” in the literal sense, but the mechanism is smart-card logon, not FIDO2/WebAuthn.
Go hybrid. If passwordless-with-FIDO2 specifically is the goal, the supported route is to hybrid-join the estate and deploy cloud Kerberos trust as above. For most shops this is the better long-term answer than building out smart-card PKI just for RDP.
A third-party MFA-for-RDP product if you want a step-up factor on top of passwords without the PKI or Entra work.

So: pure on-prem FIDO2 sign-in is not a checkbox – it is either smart-card-via-PKI or a move to hybrid.

Scenario 1 at a glance

Join state (client + server)	FIDO2 RDP logon?	What you have to configure
Entra joined (Win10/11 host)	Yes	FIDO2 method enabled in Entra; current builds
Hybrid joined (typical for Server 2022)	Yes	Entra Kerberos (cloud Kerberos trust) + WHfB cloud trust + security key sign-in enabled
On-prem only (no Entra)	Not natively	Key-as-smart-card via AD CS PKI, or move to hybrid

Scenario 2: WebAuthn redirection into the session

Different problem, much smaller. You do not want to log into the server with the key – you want a website or app running inside the RDP session to use the FIDO2 key that is physically plugged into your local PC.

That is WebAuthn redirection, and the good news is:

It is supported on Windows Server 2022 (and Windows 10 1809+ / Windows 11).
It is on by default. There is no positive switch to flip – you only need to make sure nobody disabled it.

The control that matters lives on the server (the RDP host) as Group Policy:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection > Do not allow WebAuthn redirection

Set it to Disabled or Not Configured to allow redirection. If it is Enabled, redirection is blocked and any in-session FIDO2 prompt fails instantly.

This is the one I see bite people most often, and the cause is almost always the same: a hardened golden image. CIS benchmarks and a lot of corporate baselines set “Do not allow WebAuthn redirection” to Enabled. If your security key worked fine on the local desktop but dies the moment you are inside RDP, check this policy before anything else. The ADMX comes from the Windows 11 22H2 administrative templates or newer, so make sure your Central Store is current too.

On a current Remote Desktop client you opt in on the Local Resources tab by ticking WebAuthn (Windows Hello or security keys). For the full walkthrough of using your key inside the session – including Windows 11 client cross-device passkey support – see the companion post: Using Your FIDO2 Key From Inside the RDP Session.

Picking the right path

“I want to log into the server with my key.” → Scenario 1. Find your join state in the table. For a real Windows Server 2022, that almost always means hybrid + cloud Kerberos trust.
“I want to use my key for a website/app running on the server.” → Scenario 2. Confirm “Do not allow WebAuthn redirection” is not Enabled, and you are done.
“We are on-prem only and want passwordless RDP.” → It is not native FIDO2. Either key-as-smart-card via AD CS, or move to hybrid.

Wrap-up

The reason “enable FIDO2 over RDP” has no single answer is that the key is an Entra credential and your server probably is not pure-cloud. Sort out the join state first, then the rest follows: Entra-joined is nearly free, hybrid needs cloud Kerberos trust, and on-prem-only means smart-card PKI or a hybrid move. And if it is really just an in-session web app you are after, the whole thing collapses to one Group Policy that your hardening baseline may have already turned off.

PIM Tray: Activate Microsoft Entra ID PIM Roles From the Windows Tray

Posted on May 12, 2026 by Thomas.Marcussen

Entra ID PIM activation - PIM Tray Windows tray app

Entra ID PIM activation is a daily ritual for anyone who operates Microsoft Entra ID. If you operate Microsoft Entra ID for a living, you know the dance. Open the portal. Sign in. PIM. My roles. Activate. Type a reason. Pick a duration. Confirm. Repeat for every role, every shift, every customer.

Honestly, I do this on most days. So does every other IT pro I know.

This week, however, I finally decided I was done with it – so I built PIM Tray, a tiny Windows tray app that activates one or more Entra ID PIM roles in a single dialog. It is free, open source under MIT, code-signed, and on GitHub at github.com/ThomasMarcussen/PIMTray.

Entra ID PIM Activation in 30 Seconds: What PIM Tray Does

Sits in the Windows system tray as a shield icon.
Left-click opens a small window listing every role you are eligible for. Right-click shows the same list as a context menu, plus sign-in / sign-out / about.
Tick one or more roles, hit Activate, type a reason, pick a duration, done.
A single Windows toast tells you which roles activated, which are pending approval, and which failed – so partial success is obvious instead of buried.

That is essentially the whole pitch. In short: no browser, no tab switching, no clicking through six blades to find the same form you used twenty minutes ago.

Why I Built an Entra ID PIM Activation Tool

First, I tried the obvious alternatives.

The Entra portal is the canonical UX. It is fine for one role, painful for three, exhausting for ten.
Microsoft.Graph PowerShell with a snippet works, but I do not want to keep a terminal open for a 3 second action, and reason prompts in a shell are friction.
Microsoft Authenticator and WAM do not do PIM activation.
A couple of community tools exist, but none were code-signed, none batched, and one of them shipped its own browser.

In the end, what I actually wanted was a tool that lived where my other always-on tools live – the notification area – and respected the fact that admins activate roles in clusters, not one at a time.

Therefore I built PIM Tray, a small tool that turns Entra ID PIM activation into a one-click workflow that lives in the Windows tray.

How Entra ID PIM Activation Works in PIM Tray

In particular, there are three moving parts: authentication, discovery, and activation.

PIM Tray uses MSAL (Microsoft.Identity.Client) as a public client. The default system browser pops, you complete MFA and Conditional Access the proper way, and the token is cached encrypted to disk at %LOCALAPPDATA%\PIMTray\msal_cache.bin via DPAPI. As a result, subsequent launches go silent until the refresh token expires.

Importantly, no password is ever typed into the app, and there is no embedded browser or token-stealing surface area.

Role Discovery: One Microsoft Graph Call

After sign-in, PIM Tray queries Microsoft Graph for every PIM role you are eligible for, with the scope expanded:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilitySchedules
    ?$filter=principalId eq '&lt;your object id>'
    &amp;$expand=roleDefinition

As a result, every eligible role shows up in the list automatically, with its display name and scope (Directory or a resource path). There is no config file of role IDs to maintain.

Activation: One POST Per Checked Role

Then, for each role you tick, PIM Tray posts a self-activation request:

POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentScheduleRequests
Content-Type: application/json

{
  "action": "selfActivate",
  "principalId": "&lt;user object id>",
  "roleDefinitionId": "&lt;role id>",
  "directoryScopeId": "/",
  "justification": "Friday change window, ticket INC0001234",
  "scheduleInfo": {
    "startDateTime": "2026-05-12T07:30:00Z",
    "expiration": { "type": "AfterDuration", "duration": "PT4H" }
  }
}

Notably, errors surface verbatim from Graph. If your role policy requires approval, the request is created in pending state and the tray balloon says so. If the policy requires ticket info that the form does not capture, the call fails clearly. No magic, no silent retries, no surprises.

Under the hood, the whole app is .NET 9 WinForms. In total, the signed exe is about 1.3 MB, while the MSI installer is under 500 KB.

Entra ID PIM Activation: The Permissions Question

PIM Tray needs three delegated Microsoft Graph scopes:

RoleEligibilitySchedule.Read.Directory
RoleAssignmentSchedule.ReadWrite.Directory
User.Read

Specifically, there are two practical ways to satisfy them:

Use the bundled default ClientId – the public Microsoft Graph PowerShell first-party app. The first sign-in shows the standard consent prompt. A Global Administrator can pre-consent at tenant level so end users never see the prompt again. Zero setup, but tenant-wide consent to a Microsoft-published app is heavier than some security teams want.
Register your own Entra ID app. New registration, mobile and desktop platform, redirect URI http://localhost, the three delegated scopes above, admin consent granted once. Paste the resulting TenantId and ClientId into appsettings.json (auto-created at %APPDATA%\PIMTray\ on first run). Cleaner long-term, especially if you ship the tool to other admins in your tenant.

In addition, both paths are documented in the README. For personal use, option 1 is two clicks away.

Install

PIMTray.msi  ->  C:\Program Files\PIM Tray\PIMTray.exe

To get started, download the signed MSI from the v1.0.0 release. The MSI is signed with our EV certificate (DigiCert, with RFC 3161 timestamp) so SmartScreen and Microsoft Defender treat it normally and Add/Remove Programs shows a real publisher instead of Unknown.

Requirements:

Windows 10 or 11 (x64)
.NET 9 Windows Desktop Runtime on the target machine
At least one eligible PIM role on your signed-in account

Alternatively, to build from source, clone the repo and run dotnet publish -c Release -r win-x64 --self-contained false -p:PublishSingleFile=true. The exe lands in bin\Release\net9.0-windows\win-x64\publish\.

Frequently Asked Questions

Does PIM Tray support PIM for Groups?

Not in v1.0.0. The current release covers Entra ID directory roles via roleManagement/directory. Group-membership activations (identityGovernance/privilegedAccess/group/) are on the roadmap.

Does PIM Tray support Azure resource PIM (subscriptions, resource groups)?

Not yet. Azure RBAC PIM goes through roleManagement/rbacApplications and needs a different scope ID model. Tracking it as a roadmap item.

Does PIM Tray work with Conditional Access policies that require MFA on PIM?

Yes. In fact, authentication is interactive through MSAL using the system browser, which inherits all your Conditional Access policies, MFA prompts, and even Windows Hello / passkey flows. If your policy requires reauth for PIM, you get the standard Microsoft challenge.

Where is the token stored?

%LOCALAPPDATA%\PIMTray\msal_cache.bin, encrypted with DPAPI scoped to the current Windows user. The token never leaves your machine.

Is PIM Tray code-signed?

Yes. Both PIMTray.exe and PIMTray.msi are signed with an EV code-signing certificate from DigiCert and timestamped via RFC 3161, so the signature stays valid past certificate expiry.

Is PIM Tray open source?

Yes, MIT licensed. Source, issues and pull requests at github.com/ThomasMarcussen/PIMTray.

What is Next

The roadmap on the repo is short and honest:

PIM for Groups (group-membership activations)
Azure Resource PIM (subscription / resource group scopes)
Approval-pending polling so you do not have to refresh manually
Start at logon toggle in the About dialog
Optional dark mode

Finally, if you use PIM Tray and it shaves five minutes off your week, that is a win for both of us. Issues and PRs welcome.

Try It

Repo: github.com/ThomasMarcussen/PIMTray
Download MSI (v1.0.0): github.com/ThomasMarcussen/PIMTray/releases/tag/v1.0.0

If PIM Tray fits your Entra ID PIM activation routine and you build something on top of it, ping me. I would like to hear what other patterns admins want to automate next.

Thomas Marcussen is a Microsoft MVP and Technology Architect. More notes and tools at thomasmarcussen.com.

Intune Connector for Active Directory – What To Know About The Latest Security Update

Posted on June 22, 2025 by Thomas.Marcussen

Microsoft is offering clients an updated Intune Connector for Active Directory and this connector is what Intune will be using starting from Intune 2501. This connector uses Windows Autopilot to deploy devices that are Microsoft Entra hybrid joined.

The updated version of the connector aims to enhance security and will be using a Managed Service Account (MSA) instead of a SYSTEM account. Customers currently using the old version of the Intune Connector for Active Directory (that uses the local SYSTEM account) should know that this connector will no longer have support, starting in late June 2025.

Therefore, it’s important to start planning for the update because once support ends, enrollments from the old connector build will no longer be acceptable.

Key Features of the Intune Connector

The main role of the Intune Connector for Active Directory is to join computers to an on-premises domain and add them to an organizational unit (OU) allowing for central management and policies.

The Intune Connector also places joined computers within a specific OU, something that helps establish granular control over device configurations and settings. Furthermore, customers will also benefit from hybrid enrollment of devices which offers the convenience of device management by both on-premises AD and Intune.

The Intune Connector plays a key role in leveraging Windows Autopilot to set up and deploy devices. And for all those already using Autopilot, they will know that this feature will have a huge impact in making life easier for customers by simplifying deployment processes.

In addition to all the above, the Intune Connector ensures that the policies defined in both AD and Intune continue to enforce, thus offering compliance and consistency.

Why Switch to Managed Service Accounts?

As the new version of the Intune Connector for Active Directory makes the change to using Managed Service Accounts, it’s important to understand why they are important. The use of MSAs will enable the new connector to follow least privilege principles and thereby strengthen security.

With MSAs, clients enjoy managed domain accounts that have automatic password management. They are also generally permissible with privileges to perform their duties. With such measures in place, there is a reduction in the risk of compromise, intentional or otherwise.

You can only use standalone MSAs on one domain-joined machine and can thus only access resources within that domain. MSAs can easily and securely run services on a computer while simultaneously maintaining the capability to connect to network resources as a specific user principal. When taking all of this into account, it’s not difficult to see why Microsoft views the use of MSAs as better for the Intune Connector moving forward.

Securing The Future

The security update to the Intune Connector for Active Directory fits in seamlessly with Microsoft’s Secure Future Initiative. Microsoft is uniquely ideal within the tech industry to play a key role in safeguarding the future for all its clients.

As such, the tech giant is taking a comprehensive approach to cybersecurity with a key focus on certain areas that are critical to enhancing security across the board. There continues to be substantial progress in these areas:

identity and secret protection

Updates to Entra ID and Microsoft Account (MSA) are live for both public and U.S government clouds to generate, store, and automatically rotate access token signing keys using the Azure Managed Hardware Security Module (HSM) service.

Microsoft has continued to drive broad adoption of its standard identity SDKs, which provide consistent validation of security tokens. As a result, we now see this standardized validation covering more than 73% of tokens issued by Microsoft Entra ID for Microsoft owned applications.

Tenant Protection and Isolation of Production Systems

A full iteration of app lifecycle management for all production and productivity tenants has been performed. This has resulted in the elimination of 730,000 unused apps. Additionally, because of the elimination of 5.75 million inactive tenants, the potential cyberattack surface has become significantly smaller.

Not only that, but a new system to streamline the creation of testing and experimentation tenants with secure defaults is available. It also enforces a strict lifetime management.

Protect networks

More than 99% of physical assets on the production network record in a central inventory system. This enriches asset inventory with ownership and firmware compliance tracking. Virtual networks with backend connectivity are isolated from the Microsoft corporate network, as well. They are additionally subject to complete security reviews to reduce lateral movement.

With the expansion of platform capabilities such as Admin Rules to ease the network isolation of platform as a service (PaaS) resources such as Azure Storage, SQL, Cosmos DB, and Key Vault, Microsoft has made it easier for customers to secure their own deployments.

Protection of engineering systems

We are now experiencing more consistent, efficient, and trustworthy deployments because 85% of production build pipelines for the commercial cloud are now using centrally governed pipeline templates.

Other notable changes include shortening the lifespan of Personal Access Tokens to seven days, disabling Secure Shell (SSH) protocol access for all Microsoft internal engineering repos, and massively reducing the number of elevated roles with access to engineering systems.

Moreover, proof of presence checks for critical chokepoints in software development code flow are now available.

THREAT DETECTION AND MONITORING

A lot of progress continues toward the goal of pushing all Microsoft production infrastructure and services to adopt standard libraries for security audit logs. Additional efforts include those to emit relevant telemetry and to retain logs for a minimum of two years.

A good example is the establishment of central management and a two-year retention period for identity infrastructure security audit logs, including all security audit events throughout the lifecycle of current signing keys. Add to this the fact, that no less than 99% of network devices now have enablement with centralized security log collection and retention.

Accelerate response and remediation

We can now observe improved time to mitigate for critical cloud vulnerabilities because of the recent process updates across Microsoft. Customers will also appreciate the greater transparency provided by the publishing of critical cloud vulnerabilities as common vulnerability and exposures (CVEs). This is especially helpful even when there are no direct customer action requirements.

In addition to this, the establishment of the Customer Security Management Office (CSMO) will go a long way to improve public messaging and customer engagement for security incidents.

Required Permissions

As we look at the new version of the Intune Connector for Active Directory, one of the key areas that can help us distinguish this new connector from its previous version is doing a comparison of account permissions:

	Old Connector	New Connector
Logged On Account	SYSTEM	Domain/MSA
Password Management	Set by user, subject to domain rules	Managed by domain only – automatically reset
Privilege Set Size	MAX	5 Privileges: SeMachineAccountPrivilege – Disabled default SeChangeNotifyPrivilege – Enabled Default SeImpersonatePrivilege – Enabled Default SeCreateGlobalPrivilege – Enabled Default SeIncreaseWorkingSetPrivilege – Disabled default
Registry Access Rights	Full, implicit	Read write, explicit
Enrollment Certificate Rights	Full, implicit	Full, explicit
Create Computer Object Rights (required for hybrid Autopilot scenario)	Unlimited if connector is on the same machine as domain controller. Delegation is required if connector is not on the domain controller.	Explicit delegation required

Pre-requisites

As with any product or application, there are certain requirements that all customers intending to use the Intune Connector for Active Directory will need to meet. So, before proceeding with the set up of the new Intune Connector, you need to verify that you can meet all the pre-requisites. These requirements include:

The computer you’re installing Intune Connector for Active Directory to must be running Windows Server 2016 or later.
You should also verify that you have .NET Framework version 4.7.2 or later installed.
To facilitate communication with Microsoft’s Intune service, the server hosting the Intune Connector should have internet access.
The Intune Connector will need standard domain client access to domain controllers.
Customers must verify that they have a Microsoft Entra account with Intune Service Administrator permissions, as this is a requirement to download and manage the connector.
Also needed will be a domain account with local administrator privileges and the ability to create msDS-ManagedServiceAccount objects.
Verify that the Windows Server configuration aligns with the Desktop Experience and, for versions 2019 or earlier, install the Microsoft Edge browser manually before connector setup.
The Microsoft Entra account should have an Intune license assigned to it.
For those that will be using Hybrid Azure AD Join, they should check that it’s configured via Azure AD Connect tool.
Lastly, the Intune Connector machine must have the appropriate delegated permissions to create computer objects in the target OU.

Setting Up The Connector

To setup the new Intune Connector for Active Directory, you need to start by uninstalling the existing connector. You can do this by uninstalling from the Settings app on Windows and then, uninstalling using the ODJConnectorBootstrapper.exe (select Uninstall). With that done, you can download the connector build from Intune and then perform the installation (as described in detail in my previous blog).

Configuring organizational units (OUs) for domain join

Customers should be aware that by default MSAs won’t have access to create computer objects in any Organizational Unit (OU). Thus, if you intend to use a custom OU for domain join, you’ll need to update the ODJConnectorEnrollmentWiazard.exe.config file. Fortunately, this is something you can do before or after connector enrollment:

Update ODJConnectorEnrollmentWizard.exe.config:
Default location is “C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard”
Add all the OUs required in OrganizationalUnitsUsedForOfflineDomainJoin
OU name should be the distinguished name.
You need to be aware that the MSA is only granted access to the OUs configured in this file (and the default Computer’s container). This means that if any OUs are removed from this list, completing the rest of the steps will revoke access.
Open ODJConnectorEnrollmentWizard (or restart it if it was open) and select the “Configure Managed Service Account” button.
If successful, a pop up will appear showing success.

Using the Intune Connector with multiple domains

For those who are already using the connector with more than one domain, they will be able to use the new connector by setting up a separate server per domain and installing a separate connector build for each domain.

Configuring the connector

Customers should install the Intune Connector for Active Directory on each of the domains that they want to use for domain join. In case a second account redundancy is required, customers must install the connector on a different server (in the same domain).
Go through the connector configuration steps meticulously and verify that everything has been done correctly. Also check that the MSA has the appropriate permissions on the desired OUs.
Verify that all connectors are present in the in the Microsoft Intune admin center (Devices > Enrollment > Windows > under Windows Autopilot, select Intune Connector for Active Directory) and that the version is greater than 6.2501.2000.5.

Configure Domain Join profile

Follow the steps given below.

Start by creating a domain join profile for each domain that you want to use for hybrid joining devices during Autopilot.
Target the domain join profile to the appropriate device groups.

Wrap Up

The Intune Connector for Active Directory provides an essential tool for managing hybrid devices in an Intune environment. With its many available features, customers will get centralized management capabilities for their environments thus allowing businesses to operate more efficiently.

But, with security having been a big concern for many, Microsoft has made the switch to using a Managed Service Account instead of a SYSTEM account. This action has effectively tightened security in customers’ environments. Going forward, the previous version of the Intune Connector will no longer be supported. Therefore, if you are yet to download and set up the new Intune Connector for Active Directory, the sooner you do the better.