Elevate 1.8.0

Added

• macOS, Windows and CLI: the Azure tab is a scope tree, and a subtree is one click. Azure
  resource eligibility does not scale in a flat list — a platform engineer eligible for Contributor
  on sixty subscriptions had sixty sibling rows to read and sixty clicks before the single
  activation Elevate promised. The Azure tab now groups its rows by the hierarchy the ARM scope
  string already describes: management group, subscription, resource group, resource, each header
  opening and closing and saying how many roles sit under it. A scope that only passes through — no
  eligibility of its own, one way down — is folded into the node below and named there ("Alpha /
  prod"), and a scope leading to a single role gets no header at all, so a narrow panel spends no
  row or indent on nothing. In select mode a scope header carries its own checkbox that takes every
  eligibility under it at once. The search box narrows the tree rather than sitting beside it, now
  reaches the whole ARM path, and keeps matches in their place in the tree even under a header you
  had closed. For scripts, elevate gains --under <scope> (everything at or below a resource
  group or subscription name, a subscription id, or a whole path, compared step by step so
  /subscriptions/abc never swallows /subscriptions/abcdef) and a glob form of --scope where a
  * crosses slashes (--scope "/subscriptions/*"); --scope without a * is the substring
  search it always was. elevate activate --all then takes every role the filters and names match
  instead of insisting each name picks exactly one, which is the scripted form of the subtree
  checkbox. Management groups sit beside the subscriptions rather than above them, in the panel and
  for --under: ARM writes a management group scope as its own flat path and never repeats it in a
  subscription's, so the eligibilities alone cannot say which subscriptions belong to which
  management group. (#186,
  #194)
• macOS and Windows: the activation sheet no longer signs off with "Active", the word that means
  only that PIM wrote the assignment down. It holds for the first effective-access check and closes
  on Ready when the access is already there, on Activated when the check has not answered in
  a few seconds — it never holds you there for minutes, and the panel row carries the rest. A role
  that reaches its propagation deadline without coming into effect now also raises a notification
  naming the likely cause, rather than saying so only on a row nobody is looking at by then. Follows
  #181, which showed the propagating state on the
  row but left the sheet — the path most activations actually go through — saying what it always had.
• macOS, Windows and CLI: the green light now means something. PIM reports an assignment active well
  before the access works, which is the most-repeated complaint about PIM. After an activation
  settles, Elevate probes the thing that would actually enforce the role — for an Entra directory
  role a token minted right then, looking for the role in its wids claim; for an Azure resource
  role Azure's own permission check at the activated scope, compared against what the role
  definition grants; for PIM for Groups a fresh token's groups claim, falling back to Graph's
  transitive membership check. elevate activate --wait, elevate profiles run --wait and
  elevate run now wait for that rather than for PIM's record, and report one of three outcomes
  per role: in effect, active but still not in effect (with the likely cause named — almost always
  a stale token in another tool), or active but not observable from here, which covers a
  directory-scoped Entra role, group ownership and sign-in methods whose tokens cannot be read.
  elevate run --settle 2m now bounds that check instead of being a blind pause; --settle 0
  turns the check off and keeps the old fixed 30-second pause for groups. In the panels a row that
  is active but not usable yet shows a hollow green dot and "propagating (~3 min)" beside its
  countdown, which keeps running because the clock started when PIM recorded the activation; the
  dot fills and a notification arrives the moment the access is really in effect, so switching away
  and coming back at the right time now works. A role that never confirms says "not in effect yet"
  and names the likely cause on hover. See
  Activated, but nothing happened.
  (#181)
• CLI: elevate token --resource arm|graph|<resource uri> prints an access token on stdout and
  nothing else, so a command that authenticates itself — a curl against ARM, in-house tooling —
  can make one authenticated call with what is active now. A command rather than an exported
  variable because it refreshes, is not inherited by every descendant process and works outside
  run: elevate run --role Contributor -- sh -c 'curl -H "Authorization: Bearer $(elevate token --resource arm)" https://management.azure.com/...'. --format json adds the resource, account,
  tenant and expiry, and --format kubectl prints an ExecCredential, so kubectl can call
  elevate token as an exec credential plugin and get a fresh token whenever the old one expires.
  For a command that cannot call back out — a compiled binary, a container entrypoint —
  elevate run --export-token arm -- ./my-tool puts the token in ELEVATE_ARM_TOKEN for that
  command only, never in your shell. Tokens are minted after the activation is active rather than
  taken from the cache, so what was just activated is in them, and are never logged. token
  activates nothing itself. --resource graph is refused without --i-know, and warns when given
  it: Elevate's Graph token carries only the four permissions its registration is consented for, so
  a Graph call outside them is refused however privileged the role that was just activated. ARM has
  no such ceiling.
• macOS, Windows and CLI: organization co-branding. Four managed-configuration keys —
  OrganizationName (1–32 characters, which gates the other three), OrganizationTitleStyle
  (by, managedBy or none), OrganizationSupportUrl (https:// only) and
  OrganizationSupportEmail — add your organization's name beside Elevate's own and point users
  at your help desk. The name appears as a caption under the title in the panel, on the first-run
  screen and in Settings, and the support contact becomes a "Get help from IT" link there
  and is appended to CLI sign-in and activation failures. Elevate's own name and icon are never
  replaced. Diagnostics names the organization. The Windows ADMX template and the macOS and Intune
  templates carry all four.
• Windows: an account can now use its own Entra app registration instead of the one in Settings,
  matching macOS. Choose Use a different registration under Entra app registration in Add
  account, or Change app registration… / Upgrade to Entra app registration… from an
  existing account's menu. Each pinned client ID gets its own MSAL (WAM) public client, so its
  tokens stay separate; its admin consent links use that client ID. Both options are hidden when
  the organization manages the client ID, and such an account can then only move to the managed
  registration.
• CLI: an account can now use its own Entra app registration instead of the configured one, the
  last platform to gain it. elevate login --method own --client-id <application id> adds one,
  elevate accounts set-client-id <account> <application id|--from-settings> moves an account
  between registrations later — and upgrades an Azure CLI, Azure PowerShell or other-app account to
  an Entra app registration — keeping its tenants, roles and profiles. The change is saved only
  after the same account signs in with the new registration. elevate accounts names the
  registration each account uses. Under a managed client ID only the managed registration may be
  chosen.
• macOS: an account can now use its own Entra app registration instead of the one in Settings.
  Choose Use a different registration in Add account, or Change app registration… from an
  existing account's menu to switch later; both keep the account's tenants, roles and profiles.
  When the organization manages the client ID, such an account can only move to the managed
  registration. See
  Using a second registration for some accounts.
• macOS: an account added with the Azure CLI app, the Azure PowerShell app or Other app
  (browser sign-in) can be upgraded to an Entra app registration from its account menu
  (Upgrade to Entra app registration…), so Elevate can also read and activate Entra roles and
  PIM for Groups for it — keeping its tenants, roles and profiles. The change commits only after
  the same account signs in with the new registration.

Changed

• Renamed the "Company app (client ID)" sign-in method to Other app (browser sign-in) on
  macOS and Windows. The stored value (custom:<id>) and the managed-configuration key
  (custom) are unchanged.

• Changing the client ID no longer removes accounts, on any platform. Accounts that use the
  configured registration keep their tenants, roles and profiles and sign in again — in the apps
  they show Sign in, and the CLI (elevate config set client-id) asks them to sign in on next
  use instead of signing them out; it still confirms first unless --yes is given. Accounts with
  their own registration, and Azure CLI and Azure PowerShell accounts, are unaffected.

• Windows: every release now opens the microsoft/winget-pkgs pull requests for Reothor.Elevate
  and Reothor.Elevate.CLI itself (and the audit tool's release its Reothor.Elevate.Audit
  one), so winget install and winget upgrade follow the GitHub releases after Microsoft's
  review.

Fixed

• macOS, Windows and CLI: a role behind a Conditional Access authentication context could not be
  activated at all. The activation was refused, the browser step-up was completed, and the retry
  was refused again with the same message — "the sign-in did not satisfy it" — however many times
  it was repeated. Two faults, both on the path between the step-up and the retry:

  Elevate never declared the cp1 client capability, so its tokens carried no xms_cc claim. PIM
  will not honour an authentication context (acrs) from a client that has not said it understands
  a claims challenge: it answered every activation with RoleAssignmentRequestAcrsValidationFailed
  and re-issued the same challenge, even for a token that plainly carried the context. Elevate has
  always handled claims challenges, so it now says so — through MSAL's client configuration on
  macOS, Windows and the CLI, and as an xms_cc claims request on every token the loopback
  providers mint themselves, refreshes included, since a refreshed token would otherwise lose it.

  And the token the step-up produced was thrown away: the retry asked MSAL silently for "the" token
  for those scopes, and MSAL bypasses its access-token cache whenever a claims request is specified
  and makes no promise to write the result back into it, so the retry could go out with the token
  from before the step-up. The step-up token is now held for its own lifetime and is the one the
  retry sends, which also spares the second and third role behind the same context their own
  browser round trip.

• macOS: the panel's confirmations (Remove tenant, Sign out, Delete profile) did nothing and
  dismissed the panel on click. A confirmationDialog opens its own window, which took key focus
  from the menu bar panel and closed it before the click reached a button. They now confirm inline,
  as a card in the panel itself.

• macOS: a pending "Delete profile?" confirmation in the "All profiles" popover is now cancelled
  when a search query filters its profile out of the list. The card is part of the profile's row,
  so it left the list with the row while the delete stayed pending, with nothing on screen to
  confirm or cancel it.

macOS

Signed with Developer ID and notarized.

Install with Homebrew (the fully qualified cask name is required: this tap is not a homebrew- named repository):

brew tap FrodeHus/elevate https://github.com/FrodeHus/elevate
brew trust frodehus/elevate
brew install --cask frodehus/elevate/elevate

The cask installs the pkg (Homebrew asks for your password), which also puts the elevate CLI on your PATH.

Or download Elevate-1.8.0.dmg below and drag Elevate to Applications. SHA-256: dace553c2dcc93a9553b99643c82b953498789a0798ed2fabc79c575bf35d4ee The DMG is the app alone.

Windows

Download the MSI for your architecture below and run it. It installs for the current user (no admin rights) into %LOCALAPPDATA%\Programs\Elevate and needs the .NET 10 runtime: winget install Microsoft.DotNet.Runtime.10.

Code-signed (Certum). SmartScreen can still show "Windows protected your PC" for a new release until the publisher has built reputation; choose More info, then Run anyway.

SHA-256:

• x64: 18b0e84f62057111859719f6dad5930d73d290291ff63411b43735b9bd8e7a99
• arm64: c32695fd710ca1447ff8176fabf2a25de621aaabb0a9a035ab26249bc287ea56

CLI (Linux, macOS, Windows)

One self-contained elevate binary per platform, no runtime to install.

macOS (Apple Silicon): the CLI is installed with the app by the Homebrew cask above or by Elevate-1.8.0.pkg, as /usr/local/bin/elevate. The elevate-cli formula is deprecated and will be removed in a later release; it still installs on Linux and Intel Macs:

brew install frodehus/elevate/elevate-cli

Windows: Elevate-1.8.0-x64.msi (or -arm64.msi) installs elevate.exe in a cli folder under the app and adds that folder to your PATH. Standalone: winget install Reothor.Elevate.CLI (the manifest goes to winget-pkgs with each release and is published once Microsoft's checks pass, usually within a day or two), or download elevate-cli-1.8.0-win-x64.zip (or -win-arm64.zip) below and put elevate.exe on your PATH.

Or download the archive for your platform below and unpack it anywhere on your PATH. Verify with sha256sum -c elevate-cli-1.8.0-checksums.txt. See cli/README.md.

elevate-audit

The read-only companion that lists standing privileged access to move to PIM is versioned and released on its own, under the audit-v tags: brew install frodehus/elevate/elevate-audit, winget install Reothor.Elevate.Audit, or the archives of the latest audit release. See docs/audit.md.

Enterprise

Elevate-1.8.0.pkg is a macOS installer package, and installs the elevate CLI (/usr/local/bin/elevate, Apple Silicon), signed with Developer ID Installer and notarized, for Jamf, Intune and sudo installer -pkg Elevate-1.8.0.pkg -target /. SHA-256: 81c305c999b88c53534ef854f08ec17fdfef1d154464a81a4c8d7894b4b3ecaf

Elevate-enterprise-kit-1.8.0.zip holds the managed configuration templates: the Elevate.admx/Elevate.adml policy definitions and a .reg file for Windows, a mobileconfig, an Intune preference file and a Jamf manifest for macOS, a managed.json template for the CLI, the worked example and keys.md, the key reference. SHA-256: c0cf0537aba5a3acc87236f5944acfd6f99f8f352346884fd00e634aa027b602

Deploying Elevate to a fleet starts at docs/enterprise/README.md.