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

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.

Authentication: MSAL Interactive Sign-In

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 '<your object id>'
    &$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": "<user object id>",
  "roleDefinitionId": "<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:

  1. 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.
  2. 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

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

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 ConnectorNew Connector
Logged On AccountSYSTEMDomain/MSA
Password ManagementSet by user, subject to domain rulesManaged by domain only – automatically reset
Privilege Set SizeMAX5 Privileges:   SeMachineAccountPrivilege – Disabled default SeChangeNotifyPrivilege – Enabled Default SeImpersonatePrivilege  –  Enabled Default SeCreateGlobalPrivilege –   Enabled Default SeIncreaseWorkingSetPrivilege – Disabled default
Registry Access RightsFull, implicitRead write, explicit
Enrollment Certificate RightsFull, implicitFull, 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.