Sådan finder du hvilken Conditional Access-politik der blokerer en bruger i Microsoft 365 (Helpdesk-guide 2026)

Opdateret: 3. august 2026

Når en bruger ringer og siger "jeg kan ikke logge ind på Outlook, det siger noget om en politik", er svaret næsten altid: åbn sign-in loggen i Microsoft Entra admin center, find den fejlede login-begivenhed, og klik på fanen Conditional Access. Den politik der står som Failure med Grant Controls sat til Block, er den der blokerer brugeren. Fejlkoden hedder AADSTS53003, og du kan løse den på under fem minutter, hvis du kender arbejdsgangen. Denne guide viser den præcise vej fra det første tickét til en dokumenteret fix, som jeg selv bruger på tenants med op mod 8.000 brugere.

• Fejlkoden AADSTS53003 i sign-in loggen betyder altid: en Conditional Access-politik har evalueret sign-in'et og blokeret det via Grant Controls.
• Åbn sign-in loggen i Entra admin center, find den fejlede begivenhed, og fanen Conditional Access viser hver politik og dens resultat (Success, Failure, Not Applied).
• Værktøjet What If lader dig simulere en brugers login uden at kontakte dem. Perfekt til at finde politik-konflikter proaktivt.
• Brug Temporary Access Pass (TAP) til at give en bruger midlertidig adgang uden at ændre selve politikken.
• Enhver tenant skal have mindst to break-glass konti ekskluderet fra alle Conditional Access-politikker. Ellers kan admins låses ude af deres egen tenant.
• Aktivér Report-only tilstand på nye politikker i mindst 7 dage før produktion. Det fanger blokader før brugerne oplever dem.

Hvad betyder AADSTS53003 præcist?

AADSTS53003 er den fejlkode Microsoft Entra ID returnerer, når mindst én Conditional Access-politik har evalueret et sign-in og aktivt blokeret det via en Grant Control sat til Block access. Den fulde tekst lyder typisk: "Access has been blocked by Conditional Access policies. The access policy does not allow token issuance." Brugeren ser en generisk fejlskærm i deres browser eller app. De får sjældent at vide, hvorfor de blev blokeret, og de kan ikke selv løse det.

Det er vigtigt at forstå, at AADSTS53003 ikke er det samme som en almindelig login-fejl som forkert kodeord (AADSTS50126), en udløbet MFA-token (AADSTS50158), eller en låst konto (AADSTS50053, som håndteres separat, se vores guide til Active Directory kontolåsninger). AADSTS53003 udløses efter at brugeren har bevist deres identitet: de har logget ind korrekt, men politik-motoren har bestemt, at deres session-kontekst (enhed, placering, klient-app, risiko) ikke opfylder kravene.

Ærligt talt, i mine 11 år på helpdesken har jeg set fejlen manifestere sig på tre måder: brugeren får en direkte blokade-side i browseren, appen (Outlook, Teams) går i evig login-loop, eller, den værste, en scripted service-konto fejler stille og roligt uden at nogen opdager det før dashboards holder op med at opdatere. Alle tre sager løses med samme fremgangsmåde: find politikken, forstå hvorfor den udløstes, og enten juster politikken eller giv brugeren en compliant kontekst.

Microsoft dokumenterer hele fejlkoden i deres officielle Conditional Access troubleshooting-guide, som er værd at bogmærke. Den opdateres løbende med nye policy-conditions.

Sådan finder du den blokerende politik i sign-in logs

Dette er den kerne-arbejdsgang enhver M365 helpdesk-tekniker skal kunne udenad. Det tager under to minutter, når du har gjort det ti gange.

Trin 1: Åbn sign-in loggen med korrekt filter

Log ind i Microsoft Entra admin center med en konto der har rollen Global Reader, Security Reader, eller højere. Gå til Identity → Monitoring & health → Sign-in logs.

Klik på Add filters og tilføj:

• User: brugerens UPN (fx [email protected])
• Status: Failure
• Date: sidste 24 timer (juster hvis brugeren ringede senere)

Hvis brugeren har logget ind mange gange, tilføj også Application. Får de kun fejlen i Outlook, filtrer på Office 365 Exchange Online. Sker fejlen i browseren mod SharePoint, filtrer på Office 365 SharePoint Online.

Trin 2: Åbn den fejlede begivenhed og gå til Conditional Access-fanen

Klik på den fejlede sign-in række. Der åbnes en detalje-rude med flere faner: Basic info, Location, Device info, Authentication details, Conditional Access, Report-only, Additional details.

Klik på Conditional Access. Du får en tabel med alle politikker der matchede brugeren, applikationen og betingelserne, hver med et resultat:

• Success: politikken evaluerede og bestod (fx MFA blev udført).
• Failure: politikken evaluerede og fejlede. Hvis Grant Controls viser Block, er dette din blokerende politik.
• Not Applied: politikken var ikke i scope for denne sign-in.
• User Action Required: politikken kræver en handling brugeren ikke udførte (fx MFA-registrering).

Klik på selve politik-navnet for at åbne den. Du kan nu se den nøjagtige konfiguration: hvilke brugere og grupper er inkluderet, hvilke apps, hvilke conditions (device platform, location, sign-in risk, client apps), og hvilken Grant Control der blev anvendt.

Trin 3: Notér Correlation ID og Request ID

Under fanen Basic info finder du en Correlation ID og en Request ID. Gem begge i ticket-noten. Hvis du senere skal åbne en support-sag med Microsoft, er Correlation ID det første de spørger efter. Det giver dem mulighed for at trække de fulde backend-logs for den præcise sign-in.

Sådan bruger du What If-værktøjet til Conditional Access

What If er Entra ID's simuleringsværktøj til Conditional Access. Det lader dig svare på spørgsmål som "hvis Anna prøver at logge ind på Teams fra sin private iPad hjemmefra klokken 20, hvilke politikker udløses så?" uden at Anna behøver at røre en enhed. Jeg bruger det mindst en gang om ugen, ofte før jeg ruller en ny politik ud, men også reaktivt når en bruger klager.

Sådan åbnes What If

I Entra admin center: Protection → Conditional Access → Policies. Øverst finder du knappen What If. Klik.

Udfyld simuleringen med brugerens faktiske kontekst

Vælg brugeren i feltet User or workload identity. Under Cloud apps, actions, or authentication context vælger du den app brugeren prøvede at bruge (fx Office 365 Exchange Online). Under Conditions udfylder du så præcist som muligt:

• IP address: kopier fra sign-in loggens Location-fane
• Country/Region: samme sted
• Device platforms: Windows, iOS, Android osv.
• Client apps: Browser, Mobile apps, Exchange ActiveSync osv.
• Sign-in risk: hvis Identity Protection er aktiveret

Klik What If. Værktøjet returnerer en liste over politikker der ville anvendes, samt hvilke Grant Controls og Session Controls der aktiveres. Hvis en politik står under Policies that will apply med Block, har du fundet den. Uden at kontakte brugeren.

De 5 politik-typer der oftest låser brugere ude

Efter fire år på Rackspace hvor jeg håndterede eskaleringer for mellemstore M365-tenants, kan jeg med rimelig sikkerhed sige, at 80% af alle AADSTS53003-tickets falder i en af disse fem kategorier.

1. Require compliant device (for brugere der aldrig har enrolleret)

Klassisk fælde: din organisation rullede Intune ud, oprettede en politik der kræver compliant device for alle brugere til alle apps, men glemte at ekskludere brugere der stadig er i registreringsflowet. Resultatet: den nye bruger kan ikke tilgå Intune-portalen for at enrollere sin enhed, fordi selve Intune-portalen bag Conditional Access kræver en compliant enhed. Kylling og æg.

Fix: Opret en udelukkelsesgruppe (fx "CA-Exclude-Enrollment") som midlertidigt tilføjes til brugere under onboarding. Alternativt: konfigurér politikken med Require app protection policy OR compliant device, hvilket lader brugeren enrollere via Company Portal-appen.

2. Block legacy authentication (for gamle scannere og MFP'er)

Microsoft har officielt deaktiveret basic authentication for Exchange Online i alle tenants siden 2023, men mange organisationer har derudover en politik der eksplicit blokerer "Other clients" for at fange EWS, IMAP, POP og SMTP AUTH. Det låser typisk gamle multifunktions-printere ude (scan-to-mail) og legacy line-of-business apps.

Fix: Migrer scan-to-mail til SMTP AUTH med certifikat-baseret autentificering eller direct send via Exchange connector. Se Microsofts officielle vejledning til klient-SMTP submission for detaljer.

3. Named locations (når brugeren rejser eller bruger VPN)

Politikker der kræver "trusted location" fanger konsulenter der arbejder hjemmefra, sælgere på hotel-Wi-Fi, eller brugere der bruger split-tunnel VPN hvor deres offentlige IP ændrer sig. Hvis din organisation også har en politik der blokerer login fra visse lande, kan en rejsende bruger blive blokeret ved landegrænsen.

Fix: Overvej i stedet at kræve MFA fra ikke-trusted locations frem for blokade. Hvis geo-blokering er nødvendigt (compliance-krav), opret en godkendelsesproces for rejseundtagelser og en udelukkelsesgruppe med 24-timers tidsbegrænset medlemskab via Privileged Identity Management (PIM) for Groups.

4. Hybrid Azure AD Join requirement (for BYOD-brugere)

Denne politik kræver at enheden er hybrid Entra joined (dvs. både domain joined og registreret i Entra). Den fanger enhver bruger der prøver at logge ind fra en personlig laptop eller ny enhed der endnu ikke er fuldt joined.

5. Sign-in risk politikker (false positives fra Identity Protection)

Politikker der blokerer ved "high sign-in risk" udløses ofte af rejsende brugere ("atypical travel"), delte adresser (kollektiver eller shared VPN endpoints), eller, det jeg oftest ser, brugere der lige har fået nyt password og logger ind fra flere enheder samtidig, hvilket Identity Protection tolker som credential compromise.

Fix: Sørg for at "Require password change" er en Grant Control i stedet for "Block". Så kan brugeren selv løse risikoen ved at nulstille sit password via SSPR. Detaljer i Microsofts Identity Protection risk-dokumentation.

Sådan giver du midlertidig adgang med Temporary Access Pass

Temporary Access Pass (TAP) er en tidsbegrænset kode Microsoft Entra ID kan udstede til en bruger, som lader dem logge ind uden password og uden MFA. Perfekt til at få en blokeret bruger ind midlertidigt, mens du løser den underliggende Conditional Access-konfiguration. TAP tæller som stærk autentificering, så den opfylder MFA-krav.

Aktivér TAP-metoden i tenanten (én gang)

I Entra admin center: Protection → Authentication methods → Policies → Temporary Access Pass. Sæt til Enabled. Under Configure anbefaler jeg:

• Minimum lifetime: 1 time
• Maximum lifetime: 8 timer (én arbejdsdag)
• Default lifetime: 1 time
• One-time use: True (undtagen ved onboarding-scenarier)
• Length: 8-16 karakterer

Udstedelse af en TAP

I Entra admin center: Users → All users → [vælg bruger] → Authentication methods → Add authentication method → Temporary Access Pass. Vælg varighed og om den er one-time. Kopier koden og giv den til brugeren via en sikker kanal (telefon, personligt fremmøde), ikke chat eller e-mail.

Brugeren indtaster TAP-koden i stedet for password ved næste login. Når TAP'en er brugt eller udløber, går brugeren tilbage til normale autentificerings-metoder.

Break-glass konti: så du aldrig låser dig selv ude

Den værste ticket i mit liv var en fredag aften på det advokatfirma jeg administrerede. En anden admin havde ændret en Conditional Access-politik til at kræve compliant device for alle brugere til alle apps, inklusive Global Administrators. Mandagen efter kunne ingen admin logge ind for at rette fejlen, fordi Entra-portalen selv sad bag politikken. Vi endte med at åbne en 12-timers Microsoft support-sag for at få politikken tilbagerullet fra deres backend.

Løsningen: break-glass konti (også kaldet emergency access accounts). Dette er to dedikerede Global Administrator-konti, der er eksplicit ekskluderet fra alle Conditional Access-politikker. De bruges kun i nødstilfælde og overvåges strengt.

Opsætning af break-glass konti (den rigtige måde)

1. Opret to konti med UPN der ikke matcher noget on-prem AD (fx [email protected]). Brug ikke federated identity. De skal være cloud-only, så de fungerer selv hvis ADFS er nede.
2. Giv dem Global Administrator-rollen permanent (ikke PIM-eligible, fordi PIM kræver MFA, og du skal kunne bruge kontoen selv hvis MFA-tjenesten fejler).
3. Sæt et meget langt tilfældigt password (32+ karakterer) og opdel det i to halvdele opbevaret i separate fysiske safes hos to forskellige personer.
4. Ekskluder begge konti fra alle Conditional Access-politikker via en dedikeret gruppe (fx "CA-BreakGlass-Exclude").
5. Konfigurér Azure Monitor-alerts på ethvert sign-in fra disse konti. Hvis en break-glass konto bruges, skal hele sikkerhedsteamet vide det inden for et minut.
6. Test kontoen mindst hver 90. dag ved at logge ind og verificere adgang.

Microsoft har en dedikeret officiel vejledning til emergency access accounts som jeg anbefaler at følge nøjagtigt. Det er ikke stedet at improvisere.

Report-only tilstand: fang blokader før produktion

Report-only er den vigtigste feature at forstå for enhver der rører Conditional Access. Når en politik står i Report-only, evalueres den mod alle sign-ins og logges, men Grant Controls anvendes ikke. Med andre ord: du ser hvad politikken ville blokere, uden at det faktisk sker.

Sådan bruger jeg Report-only

Enhver ny politik jeg opretter, starter i Report-only i mindst 7 dage, helst 14 dage så jeg fanger både normale arbejdsdage og weekender med automatiske jobs. Efter perioden filtrer jeg sign-in loggen på Report-only: Failure for at se hvilke brugere der ville være blevet blokeret.

Typisk finder jeg:

• 2-5 service-konti der bruger legacy authentication og skal migreres først
• 1-2 medarbejdere der pendler internationalt og udløser location-conditions
• Multifunktions-printere der scanner til e-mail
• Et enkelt gammelt CRM-system der stadig bruger IMAP

Først når alle disse er håndteret (enten migreret, ekskluderet, eller varslet), skifter jeg politikken til On. Denne fremgangsmåde har reduceret produktions-blokader med >90% på de tenants jeg administrerer.

Gæstebrugere og cross-tenant sign-in scenarier

Cross-tenant scenarier er der hvor mange helpdesk-teknikere bliver forvirrede. Når en gæst fra partner.com prøver at tilgå din tenants SharePoint, evalueres Conditional Access på begge sider: både gæstens hjem-tenant og din ressource-tenant.

Sådan finder du hvilken tenant der blokerer

1. Bed gæsten om Correlation ID fra deres fejl-skærm.
2. Søg i din tenants sign-in log på Correlation ID. Hvis du finder begivenheden, blokeres gæsten af din tenants politikker.
3. Hvis du ikke finder begivenheden, kontakt gæstens IT-team og bed dem søge i deres sign-in log. Så blokerer deres hjem-tenant.

Cross-tenant access settings

Fra 2023 og fremad understøtter Entra ID Cross-tenant access settings, som lader dig eksplicit stole på gæste-tenants' MFA og device-compliance-krav. Konfigureres under Identity → External identities → Cross-tenant access settings. Uden dette skal gæsten udføre MFA igen i din tenant, selv hvis de netop har gjort det derhjemme, hvilket ofte fejler for gæster der ikke har registreret MFA-metoder i din tenant.

Se også vores tidligere guide til VPN-fejlfinding i Windows 11, fordi mange cross-tenant issues opstår når gæster kommer ind via en split-tunnel VPN, hvilket ændrer deres opfattede location.

Helpdesk-tjekliste ved AADSTS53003-tickets

Print denne, hæng den op ved din skærm, og gå den igennem hver gang en ticket kommer ind med "kan ikke logge ind" og fejlkode 53003.

1. Bekræft brugerens UPN og fejltidspunktet, helst med et screenshot af fejlskærmen der viser Correlation ID.
2. Åbn Entra admin center → Sign-in logs og filtrer på brugerens UPN + Status: Failure + sidste 24 timer.
3. Klik på den fejlede begivenhed → Conditional Access-fanen. Notér politiknavnet der viser Failure med Block.
4. Åbn politikken og læs conditions: hvilken app, hvilken location, hvilken device platform, hvilken client-app blev evalueret?
5. Sammenlign med brugerens faktiske kontekst (Location-fanen og Device info-fanen i sign-in loggen).
6. Beslut fix:
   • Uddannelse, hvis brugeren bare skal enrollere sin enhed eller registrere MFA.
   • Midlertidig udelukkelse, tilføj brugeren til udelukkelsesgruppen med tidsbegrænset PIM-medlemskab.
   • TAP, hvis autentificerings-metoden er problemet.
   • Politik-justering, hvis politikken er fejlkonfigureret (eskaleres til CA-owner).
7. Dokumentér i ticketen: politiknavn, Correlation ID, valgt fix, og eventuelle langsigtede anbefalinger til CA-owner.
8. Verificér fix ved at bede brugeren prøve igen mens du overvåger sign-in loggen live.

Hvis du håndterer mange af disse tickets, kan du med fordel automatisere trin 2-4 via et PowerShell-script der kalder Get-MgAuditLogSignIn. Se vores tidligere gennemgang i OneDrive-synkroniserings-guide som viser et lignende Microsoft Graph pattern.

Ofte stillede spørgsmål

Hvordan finder jeg hvilken Conditional Access-politik der blokerer en bruger?

Åbn Microsoft Entra admin center, gå til Identity → Monitoring & health → Sign-in logs, filtrer på brugerens UPN og Status: Failure, klik på den fejlede begivenhed og åbn fanen Conditional Access. Politikker der viser "Failure" med Grant Controls sat til "Block" er dem der blokerer sign-in'et.

Hvad betyder fejlkoden AADSTS53003?

AADSTS53003 betyder at Microsoft Entra ID har blokeret et sign-in på grund af en Conditional Access-politik. Brugeren er korrekt autentificeret, men opfylder ikke de conditions politikken kræver, typisk device compliance, trusted location, eller en godkendt klient-app.

Kan man omgå Conditional Access for én enkelt bruger midlertidigt?

Ja. Opret en dedikeret udelukkelsesgruppe (fx "CA-Emergency-Exclude") som er eksplicit ekskluderet fra den relevante politik, og tilføj brugeren til gruppen midlertidigt, helst via Privileged Identity Management (PIM) for Groups med en tidsbegrænset aktivering på fx 8 timer. Fjern brugeren igen efter fejlen er løst.

Hvad er forskellen på Report-only og Enabled i Conditional Access?

Report-only tilstand evaluerer politikken mod alle sign-ins og logger resultatet, men anvender ikke Grant Controls, så ingen brugere blokeres. Enabled aktiverer politikken helt. Kør altid nye politikker i Report-only i mindst 7 dage før du skifter til Enabled, så du fanger utilsigtede blokader.

Hvorfor virker Temporary Access Pass ikke for min bruger?

De to hyppigste årsager er: TAP-metoden er ikke aktiveret i tenanten (Protection → Authentication methods → Temporary Access Pass), eller brugeren er blokeret af en device-relateret Conditional Access-politik (som kræver compliant device). TAP løser kun autentificerings-blokader, ikke device- eller location-baserede blokader.

Hvor mange break-glass konti bør en tenant have?

Mindst to. Microsoft anbefaler eksplicit to cloud-only Global Administrator-konti med lange tilfældige passwords opbevaret sikkert offline, ekskluderet fra alle Conditional Access-politikker, og overvåget med Azure Monitor-alerts på ethvert sign-in. To konti giver redundans hvis den ene bliver kompromitteret eller den ene administrator er utilgængelig.