JAMF Connect Privilege Escalation for Tech Group only

Hi ​@justintechy,

This is a known behavior with Jamf Connect's privilege elevation when VerifyUserPromotion is enabled with Microsoft Entra ID. The OIDC tokens cached in the user's keychain persist after the elevation session ends, causing two issues: (1) subsequent elevation requests skip authentication, and (2) the technician's Entra session leaks to office.com.

Here are a few approaches to address this:

1. Use VerifyUserPromotionFIDO2 instead of VerifyUserPromotion

This setting forces authentication through a browser window and supports WebAuthn/FIDO2 keys. Because it uses a browser-based flow, the token handling is different and may reduce the cached token problem. It takes priority over VerifyUserPromotion.

<key>VerifyUserPromotionFIDO2</key>
<true/>

Note: Your Jamf Connect OIDC app registration in Entra ID must use the redirect URI jamfconnect://loggedin.

2. Create a cleanup script to remove Entra tokens from keychain after demotion

You can use Jamf Pro to deploy a script (via policy or Jamf Connect's built-in script scheduling) that removes the cached OIDC tokens from the user's keychain when the elevation session ends. The three keychain items you identified can be removed programmatically:

#!/bin/zsh
# Remove Jamf Connect OIDC/Entra cached tokens from user keychain
currentUser=$(stat -f%Su /dev/console)

# Remove Microsoft Entra OIDC tokens stored by Jamf Connect
security delete-generic-password -l "com.jamf.connect.login" /Users/$currentUser/Library/Keychains/login.keychain-db 2>/dev/null
security delete-generic-password -l "com.jamf.connect" /Users/$currentUser/Library/Keychains/login.keychain-db 2>/dev/null

# You may also need to target specific Entra/Microsoft token entries
# List keychain items first to identify exact labels:
# security dump-keychain /Users/$currentUser/Library/Keychains/login.keychain-db | grep -i "jamf\|entra\|microsoft\|OIDC"

You'll need to inspect the actual keychain item labels on a test machine (since you mentioned you can already see the three tokens) and adjust the security delete-generic-password commands accordingly.

3. Trigger cleanup automatically with Jamf Pro Policy

Since jamfconnect://demote can be called via URL scheme, you could combine the demotion and cleanup into a Jamf Pro policy:

#!/bin/zsh
# Demote the user
open jamfconnect://demote

# Wait for demotion to complete
sleep 5

# Clean up cached Entra tokens
currentUser=$(stat -f%Su /dev/console)
# [Insert your keychain cleanup commands here based on the token labels you identified]

4. Entra ID Token Lifetime Policies

While you mentioned Conditional Access didn't work because Jamf Connect is external, consider configuring Token Lifetime Policies in Entra ID specifically for the Jamf Connect app registration. You can set shorter access token lifetimes and restrict refresh token behavior. This won't prevent caching entirely, but reduces the window of exposure.

5. Consider filing a Feature Request with Jamf

The core issue — that Jamf Connect caches the OIDC token and doesn't clear it after the elevation session ends — is arguably a product gap. I'd recommend submitting a feature request via Jamf Ideas requesting that Jamf Connect automatically purge cached Entra tokens upon demotion, especially when a technician authenticates on behalf of a user.

References:

• Configuring macOS Privilege Elevation using Jamf Connect
• Privilege Elevation Settings
• Jamf Connect URL Scheme