Onboarding Without the Master Key: The Least-Privilege Build

Just Enough Administration (JEA) solves this precisely. A JEA endpoint is a constrained PowerShell remoting endpoint: users who connect can run only the commands you make visible, with only the parameter values you allow.

The endpoint is set up once, on the Entra Connect server itself, by a local administrator in an elevated Windows PowerShell 5.1 session. First, the role capability defines what's visible. Here it's two commands, with PolicyType locked to Delta:

$module = "$env:ProgramFiles\WindowsPowerShell\Modules\SyncOps"
New-Item -ItemType Directory -Path "$module\RoleCapabilities" -Force | Out-Null
New-ModuleManifest -Path "$module\SyncOps.psd1"

New-PSRoleCapabilityFile -Path "$module\RoleCapabilities\SyncOps.psrc" `
    -ModulesToImport 'ADSync' `
    -VisibleCmdlets @(
        @{ Name = 'Start-ADSyncSyncCycle'
           Parameters = @( @{ Name = 'PolicyType'; ValidateSet = 'Delta' } ) },
        'Get-ADSyncScheduler'
    )

The session configuration says who may connect and what identity the session runs as:

$pssc = "$env:ProgramData\JEAConfiguration\SyncOps.pssc"
New-Item -ItemType Directory -Path (Split-Path $pssc) -Force | Out-Null

$group = 'SOMEDOMAINSOMEWHERE\Onboarding-Provisioners'
$roles = @{ $group = @{ RoleCapabilities = 'SyncOps' } }

New-PSSessionConfigurationFile -Path $pssc `
    -SessionType RestrictedRemoteServer `
    -RunAsVirtualAccount `
    -TranscriptDirectory 'C:\ProgramData\JEAConfiguration\Transcripts' `
    -RoleDefinitions $roles

Register-PSSessionConfiguration -Name 'SomeDomainSomewhere.SyncOps' `
    -Path $pssc -Force

The repository's Register-SyncJeaEndpoint.ps1 wraps these steps with -WhatIf, -Uninstall, and pre-flight checks, including one that stops you from registering from PowerShell 7 by mistake.

That's the end of the setup. The next snippet is different: it's from the onboarding script, and it runs from the tech's workstation, as the tech, every time. The only change to the script's sync call is one parameter:

Invoke-Command -ComputerName 'entcon01.somedomainsomewhere.com' `
    -ConfigurationName 'SomeDomainSomewhere.SyncOps' `
    -ScriptBlock { Start-ADSyncSyncCycle -PolicyType Delta }

Here's what that buys you:

• RestrictedRemoteServer gives the session no file system access, no arbitrary script blocks, and nothing beyond the two visible commands.
• RunAsVirtualAccount runs the session as a temporary local administrator that exists only for that session. Members of the allowed group need no standing rights on the server at all.
• Transcripts record every session and every command, so you have an audit trail for free.

The JEA gotchas we hit

• A command with no parameter limits must be a plain string. Our first version listed Get-ADSyncScheduler as @{ Name = 'Get-ADSyncScheduler' }, and the role capability wouldn't load. A hashtable entry needs both Name and Parameters. If you don't constrain parameters, list the command name as a string.
• Register it in Windows PowerShell 5.1, not PowerShell 7. Remote clients connect to the default WinRM endpoint, which is Windows PowerShell. If you register from pwsh, the endpoint lands in the wrong place.
• Registering restarts WinRM. Existing remote sessions on the server drop briefly, so schedule it.
• JEA constrains what runs, not how WinRM authenticates. A workstation that isn't domain-joined still needs TrustedHosts or an HTTPS listener to connect. JEA doesn't change that.

The test we didn't plan

The best proof that this worked was an accident. During verification, I ran the sync command without -ConfigurationName, which meant a normal admin remoting session. The answer was "Access is denied." The old path into the Tier 0 server was closed, and the only way in was the endpoint that can do exactly one thing.

Write that negative test on purpose. It's the one that proves you actually removed something.

Step 3: Replace Global Administrator for the Temporary Access Pass

New hires get a Temporary Access Pass so they can sign in and register MFA on day one. Creating a TAP needs Authentication Administrator, not Global Administrator. Authentication Administrator can manage authentication methods for non-admin users, which is exactly the population the help desk onboards.

We made the role eligible through PIM, not permanent. The eligible assignment goes to a role-assignable Entra group for the help desk. A Privileged Role Administrator sets that up once, in the Entra admin center. That also means changing the group's membership requires a privileged role, so nobody can quietly add themselves. Each tech activates the role for their own session, with MFA and a justification, and it expires on its own.

One sequencing rule saves a lot of confusion: activate PIM before signing in to Microsoft Graph. The Graph token reflects your roles when it was issued. If you activate the role after Connect-MgGraph, the token doesn't have it. Run Disconnect-MgGraph, sign in again, and it works.

The replication race Graph reports two different ways

A freshly synced user shows up in Get-MgUser a little before the authentication-methods endpoint catches up. Try to create a TAP in that window and Graph fails. Here's the catch: it fails in two different ways, depending on how far replication has gotten:

• resourceNotFound: the user object isn't there yet, from that endpoint's point of view
• accessDenied ("Request Authorization failed"): the object is there, but its authorization context hasn't replicated yet, even with the PIM role active

The first version of our retry logic only caught resourceNotFound. When the second error showed up, the script gave up, and the error message sent the tech off to check their PIM activation and the TAP policy. Both were fine. The real fix was to treat both errors as transient. Here's that logic from the onboarding script, simplified. It runs as the tech, with the PIM role active:

$transient = 'resourceNotFound|could not be found|' +
             'accessDenied|Request Authorization failed'
$tapBody = @{ lifetimeInMinutes = 1440; isUsableOnce = $false }

for ($attempt = 1; $attempt -le 5; $attempt++) {
    try {
        $tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $userId `
            -BodyParameter $tapBody -ErrorAction Stop
        break
    }
    catch {
        if ($attempt -lt 5 -and $_.Exception.Message -match $transient) {
            Start-Sleep -Seconds 15   # replication lag, not a policy problem
        }
        else { throw }
    }
}

There's also a diagnostic trick that's worth stealing. If any TAP already succeeded in the same run, the policy and the tech's role are fine. A later failure is replication, not permissions. The script now says so, instead of sending the tech to check a PIM role that's already active.