Problemet

Du har gjort alt rigtigt.

Brugeren er eligible til Global Admin via PIM.

Conditional Access kræver MFA.

PIM-rollen kræver MFA ved aktivering.

På papiret er det textbook least privilege.

Så tester du det. Du aktiverer rollen.

Ingen prompt.

Direkte elevation til Global Admin.

Hvorfor det sker

Require MFA er et claim check. Ikke en action.

Hvis brugeren allerede har authenticated med MFA tidligere i sessionen, så er claim'et der. PIM kigger på claim'et, ser det, og siger "godt nok."

Der sker ingen ny verifikation i det øjeblik hvor privilegierne tildeles.

Hvilket betyder:

• En bruger der loggede ind for 30 minutter siden får en gratis elevation.
• En token-stealing attacker der allerede har passed MFA får også en gratis elevation.

Hele pointen med just-in-time elevation er at fremtvinge en frisk, bevidst proof of presence i det øjeblik privilegierne gives.

Default-opførslen gør ikke det.

Det første forsøg der næsten virker

Instinktet er at bygge en kæde:

1. Tilføj en authentication context på PIM-rollen.
2. Opret en Conditional Access-policy der targeter den context.
3. Sæt Sign-in frequency = Every time.

Det er tættere på. Men Microsofts egen dokumentation er ærlig omkring det: brugere bliver måske ikke re-promptet hvis de allerede har authenticated med stærke credentials i den nuværende session.

"Måske ikke" er ikke det du vil have i et privileged access-design.

Hvad der faktisk virker

Require authentication strength — med en phishing-resistant metode.

Det her er ikke et claim check. Det er et method check.

Hvis brugeren loggede ind med almindelig push-MFA, så kan deres eksisterende claim ikke opfylde et krav om phishing-resistant authentication. Så de bliver promptet — lige der, i det øjeblik elevation sker, med den stærkere metode.

Mental-modellen skifter fra:

"Har du gennemført MFA?"

til:

"Bevis dig selv med en phishing-resistant metode, lige nu, uanset hvordan du loggede ind."

Det er den model privileged access rent faktisk har brug for.

Kæden der holder

  graph LR
    A[PIM Role:
Auth Context required] --> B[Conditional Access:
Targets the context]
    B --> C[Require Authentication Strength:
Phishing-resistant MFA]
    C --> D[Fresh prompt at activation]

Hvert skridt tæller:

• Authentication context — giver aktiveringen noget CA kan targete.
• CA-policy — håndhæver reglen når context'en dukker op.
• Authentication strength — fremtvinger en metode den eksisterende session formentlig ikke har.

Spring et af dem over, og du er tilbage ved silent elevation.

Rækkefølgen for udrulning tæller

Før du slår det her til tenant-wide skal dine admins have en phishing-resistant metode registreret.

Hvis ikke, så låser du dem ude af deres egen elevation-path.

Praktisk rækkefølge:

1. Onboard admins til FIDO2, passkey, Windows Hello eller CBA.
2. Verificér registreringen. Antag ikke.
3. Test hele kæden på én pilot-admin.
4. Rul ud til resten.

Ikke omvendt.

Slutbemærkning

Require MFA lyder som en stærk kontrol. Det er den ikke — ikke ved aktiveringssteget.

Det er et claim check som en session-riding attacker allerede har passed.

Hvis du bekymrer dig om privileged access — og det bør du — så gør selve elevation-øjeblikket til proof-pointet. Phishing-resistant, frisk, hver gang.

Alt mindre er just-in-time elevation i navnet, ikke i reglen.