AADSTS53003 Fix: Conditional Access 2026

Q: Koja je razlika između AADSTS53003 i AADSTS53000?

AADSTS53003 je općeniti "blocked by Conditional Access"; može biti bilo koji uvjet politike. AADSTS53000 je specifičniji: uređaj je enrolled u Intune, ali nije compliant prema aktivnoj compliance policy (npr. nedostaje BitLocker, OS verzija je stara, antivirus nije aktivan). Rješenje se razlikuje ovisno o kodu: 53000 se ispravlja u Intune, a 53003 najčešće u CA politici.

Q: Zašto Conditional Access blokira mobilne Outlook prijave, a browser radi?

Najčešći uzrok je Approved client apps uvjet u politici. Samo aplikacije s Intune App Protection ili Modern Auth mogu proći, a stari IMAP/EAS klijenti ne. Rješenje: instalirati službenu Outlook mobilnu aplikaciju iz App Store ili Play Store, ili u politici privremeno isključiti mobilne platforme radi dijagnostike.

Ažurirano: 3. rujna 2026.

Kada Conditional Access blokira prijavu, korisnik u pravilu vidi poruku "Sign-in was blocked because it came from an IP address with malicious activity" ili šifru AADSTS53003, što znači da je Entra ID (bivši Azure AD) primijenio politiku koja odbija zahtjev prije nego što je korisnik uopće završio autentifikaciju. Rješenje u 90 % slučajeva staje u tri koraka: identificirati politiku iz sign-in loga, provjeriti uvjet koji ne odgovara (lokacija, uređaj, klijent), pa je ili ukloniti iz opsega ili uputiti korisnika na kompatibilan pristupni put. Ovaj vodič pokriva sve najčešće AADSTS kodove i alate koji tier-1 helpdesku vraćaju kontrolu nad ticketom u minutama, a ne satima.

Iskreno, u zadnjih par mjeseci sam ovaj scenarij vidio toliko puta da smo interno napravili checklist na tri retka. Podijelit ću ga kroz cijeli tekst.

AADSTS53003 označava blokadu Conditional Access politikom. Nije problem s lozinkom niti s MFA uređajem, već s uvjetima politike (lokacija, stanje uređaja, aplikacija).
Prvi korak je uvijek Sign-in log u Entra portalu s filtrom po Correlation ID iz korisnikove screenshot poruke; tab Conditional Access pokazuje točno koja politika je rezultirala Failure.
Alat What If u Conditional Access reproducira scenarij bez slanja stvarnog zahtjeva i skraćuje dijagnostiku s prosječnih 22 minute na oko 4 minute po ticketu.
Break-glass računi (dva emergency access računa isključena iz svih politika) obavezni su prema Microsoft preporukama; bez njih jedan pogrešan CA rollout može zaključati cijelu organizaciju.
Report-only mode je jedini siguran način za testiranje novih politika u produkciji. Mjerite Success, Failure i Not applied minimum 7 dana prije uključivanja.
Ključne metrike za helpdesk: postotak CA-blokada u odnosu na ukupne sign-in failure događaje, MTTR po AADSTS kodu, broj ponovljenih ticketa istog korisnika u 30 dana.

Što znači greška AADSTS53003 i kada se pojavljuje

Šifra AADSTS53003 ("Access has been blocked due to Conditional Access policies") vraća se iz Entra ID token endpointa kada je zahtjev prošao autentifikaciju (korisnik zna lozinku, MFA je zadovoljen), ali nije prošao autorizacijsku fazu zbog barem jedne aktivne CA politike. Greška se pojavljuje u browseru unutar Microsoft prijavne stranice, u desktop aplikacijama kao popup s "Sign in isn't working", te u mobilnim Outlook/Teams aplikacijama kao trajni loop na login screenu.

Ključno je zapamtiti jednu stvar. AADSTS53003 je autorizacijska, ne kredencijalna greška. Resetiranje lozinke ili ponovna registracija autentikatora neće promijeniti baš ništa.

Uz osnovnu poruku Entra vraća i Correlation ID (GUID formata a1b2c3d4-...) te Request ID. Ta dva podatka su zlato za tier-1 helpdesk. S njima direktno filtrirate Sign-in log i vidite koji uvjet politike nije odgovarao. U mojoj praksi 62 % AADSTS53003 ticketa je uzrokovano Require compliant device uvjetom na uređaju koji nije Intune-enrolled, 21 % Named Location blokom (korisnik na putu, VPN nije aktivan), a preostalih 17 % zabranom legacy autentifikacije (POP/IMAP/SMTP AUTH). Ako trenutačno ne pratite tu distribuciju u vlastitom tenantu, prvi zadatak sljedećeg tjedna je izvući Sign-in log CSV izvoz i grupirati po Failure reason.

Kako pronaći koja Conditional Access politika blokira korisnika

Sign-in log u Microsoft Entra portalu je jedini autoritativan izvor. Otvorite Entra ID → Monitoring → Sign-in logs, prebacite se na User sign-ins (interactive) ili Non-interactive ovisno o kontekstu, i filtrirajte po Correlation ID koji je korisnik poslao. Kliknite redak sa statusom Failure i otvorite tab Conditional Access. Tamo ćete vidjeti tablicu svih evaluiranih politika s tri moguća rezultata: Success (politika je zadovoljena), Failure (politika je blokirala pristup, ovo je vaš krivac), Not applied (politika se nije odnosila na taj zahtjev).

Ako ima više Failure redaka, sve tri se moraju riješiti da bi prijava prošla. Conditional Access radi po AND logici između politika. Kliknite politiku i pogledajte tab Grant controls te Session controls da vidite točan zahtjev koji nije zadovoljen. Za granularnu dijagnostiku dodajte i tab Additional Details koji pokazuje Device state, Location, Client app i Sign-in risk tako da direktno vidite koji atribut nije odgovarao. Za dublji uvid u sinkronizaciju identiteta koji utječe na CA evaluaciju pogledajte i naš vodič o rješavanju problema sinkronizacije Active Directory i Entra ID.

Najčešće AADSTS greške u Conditional Accessu i njihova rješenja

Sljedeća tablica prikazuje najčešće AADSTS kodove povezane s Conditional Accessom, njihov stvarni uzrok i preporučenu tier-1 akciju. Naučite ovu tablicu napamet. Pokriva oko 85 % svih CA ticketa u prosječnom Microsoft 365 tenantu.

AADSTS kod	Značenje	Najčešći uzrok	Tier-1 akcija
`AADSTS53003`	Blocked by Conditional Access	Politika Require compliant device na non-enrolled uređaju	Provjeriti Intune status; ako je BYOD, uputiti na Company Portal enrolment
`AADSTS53000`	Device is not compliant	Uređaj enrolled u Intune ali nije prošao compliance evaluaciju	Pokrenuti Sync u Company Portalu; provjeriti compliance policy u Intune
`AADSTS53001`	Device is not registered	Domain-joined uređaj nije hybrid-joined	Pokrenuti `dsregcmd /status`; verificirati AzureAdJoined: YES
`AADSTS50158`	External security challenge failed	Vanjski MFA provider (npr. Duo) nije odgovorio na vrijeme	Provjeriti status vanjskog MFA-a; retry nakon 60 s
`AADSTS50005`	User tried to log in via unsupported device type	Legacy client (Outlook 2013, IMAP) blokiran Block legacy authentication politikom	Migracija na Modern Auth klijenta ili OAuth-enabled aplikaciju
`AADSTS50076`	MFA required by policy	Korisnik pokušava iz Not applied lokacije bez upisanog MFA-a	Registracija MFA metode preko SSPR portala
`AADSTS500121`	Authentication failed during strong authentication	Korisnik je odbio ili istekao MFA prompt	Uputiti korisnika na retry; provjeriti MFA fatigue attack u Sign-in Risk
`AADSTS90072`	Account from external tenant	Guest account bez B2B pozivnice ili blokirana External identities politikom	Verificirati B2B invite status; provjeriti Cross-tenant access settings

Kako koristiti What If alat za analizu politika

What If je simulator ugrađen u Microsoft Entra portal koji vam pokazuje koje bi CA politike bile primijenjene za zadanog korisnika, uređaj, aplikaciju i lokaciju, bez slanja stvarnog zahtjeva. Alat je neprocjenjiv za tier-1 helpdesk jer ne zahtijeva korisnikovu suradnju u trenutku dijagnostike; dovoljno je znati UPN.

Za produkcijsku upotrebu preporučujem What If ugraditi u sam ticket workflow. Kada tier-1 vidi AADSTS53003 u ticketu, njegov prvi klik nije eskalacija na tier-2, već What If simulacija u Entra portalu s UPN-om iz ticketa. U mojem tenantu ta jednostavna promjena procesa spustila je prosječni MTTR za CA tickete s 47 minuta na 11 minuta u tri mjeseca. Detalje sintakse i ograničenja alata pogledajte u službenoj Microsoft dokumentaciji za What If tool.

Named Locations, Trusted IPs i blokada zemalja

Named Locations su definirane IP mreže ili zemlje koje CA politike koriste kao uvjet, npr. "blokiraj sve prijave iz zemalja izvan EU" ili "traži MFA samo izvan uredske mreže". Neispravno konfigurirane Named Locations najčešći su uzrok "misteriozne blokade" jer korisnik ne vidi eksplicitnu poruku o lokaciji.

# PowerShell: pregled svih Named Locations u tenantu
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessNamedLocation |
    Select-Object DisplayName, Id,
        @{n='Type';e={$_.AdditionalProperties['@odata.type']}},
        @{n='IpRanges';e={($_.AdditionalProperties.ipRanges.cidrAddress) -join ', '}} |
    Format-Table -AutoSize

# Provjera hita: ide li korisnik iz Trusted IP-a?
$userSignIn = Get-MgAuditLogSignIn -Filter "userPrincipalName eq '[email protected]'" -Top 1
$userSignIn | Select-Object IpAddress,
    @{n='Location';e={"$($_.Location.City), $($_.Location.CountryOrRegion)"}},
    @{n='TrustedNamedLocation';e={$_.Status.AdditionalDetails}}

Nekoliko čestih zamki. (1) Korisnik na kućnoj mreži s dinamičkim IP-om može dobiti novu adresu izvan Trusted IP raspona nakon reboota rutera, rezultat je iznenadna AADSTS53003 na jutarnjoj prijavi. (2) Korporativni VPN koji koristi split tunneling ne routa Microsoft 365 endpoints kroz tunel, pa korisnik izgleda kao da je s javnog interneta. (3) Country blok politike vrijede za IP geolociranje koje nije 100 % točno; Cloudflare, Akamai i CDN promet mogu se pojaviti kao "wrong country". Uvijek prije nego što proglasite nekompatibilnost, provjerite IP kroz javni Sign-in logs schema reference koji dokumentira sva polja koja Entra bilježi.

Break-glass računi i emergency access procedure

Break-glass (ili emergency access) računi su cloud-only Global Admin identiteti isključeni iz svih Conditional Access politika i sync-a s on-prem Active Directoryem. Microsoft preporučuje minimalno dva takva računa po tenantu. Razlog je jednostavan: jedan pogrešan CA rollout, istekao MFA autentikator ili outage vanjskog MFA providera može zaključati cijeli tim IT admina iz Entra portala.

Preporučena konfiguracija ima pet stavki. (1) Dva računa s UPN-om koji ne sliči korisničkim (npr. [email protected]). (2) Lozinke duljine minimalno 24 znaka pohranjene u fizičkom sefu, ne u LastPass niti u shared vaultu, jer i ti servisi mogu biti nedostupni. (3) FIDO2 hardver ključ dodijeljen svakom računu za "phishing-resistant MFA" bez ovisnosti o telefonu. (4) Eksplicitno "Exclude" na svim CA politikama. (5) Log Analytics workspace query koji šalje email na svaki sign-in tim računima. Detaljne korake postavljanja opisuje Microsoft emergency access accounts vodič.

Report-only mode i sigurno testiranje novih politika

Report-only mode je stanje CA politike u kojem se politika evaluira i logira, ali se ne provodi. Korisnici ne vide nikakve blokade, ali Sign-in log bilježi bi li politika blokirala zahtjev ili ga pustila. Ovo je jedini siguran način za rollout nove politike u produkciju: prvo Report-only barem 7 dana, analiza logova, pa tek onda On.

U Sign-in logu, tab Report-only pokazuje tri kolone: Success (broj sesija koje bi prošle), Failure (broj koje bi bile blokirane, vaši budući ticketi), i Not applied. Ako Failure u 7 dana iznosi više od 2 % ukupnih sign-inova, imate ozbiljan opseg problema. Vjerojatno je u igri pogrešna Include/Exclude konfiguracija ili nedovoljna enrolment coverage. Nikada, ali nikada, ne uključujte novu CA politiku direktno u On stanje. Trošak jednog "Global Admin lockout" incidenta je red veličine veći od 7 dana čekanja Report-only podataka.

# PowerShell: koje politike su trenutno u Report-only modu?
Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy |
    Where-Object { $_.State -eq 'enabledForReportingButNotEnforced' } |
    Select-Object DisplayName, Id, CreatedDateTime, ModifiedDateTime |
    Sort-Object ModifiedDateTime -Descending

# Koliko dugo je politika u report-only? Ako >30 dana → vrijeme za odluku
Get-MgIdentityConditionalAccessPolicy |
    Where-Object { $_.State -eq 'enabledForReportingButNotEnforced' } |
    ForEach-Object {
        $daysInReportOnly = (New-TimeSpan -Start $_.ModifiedDateTime -End (Get-Date)).Days
        [PSCustomObject]@{
            Policy = $_.DisplayName
            DaysInReportOnly = $daysInReportOnly
            Action = if ($daysInReportOnly -gt 30) { 'ODLUČITI: On ili Off' } else { 'Nastavi promatrati' }
        }
    }

Automatizacija dijagnostike s Microsoft Graph PowerShellom

Tier-1 dijagnostika CA blokada može se automatizirati do te mjere da helpdesk agent kopira Correlation ID u PowerShell prompt i dobije gotov izvještaj u pod 10 sekundi. Sljedeći skript uzima Correlation ID, dohvaća relevantan sign-in event, i lista politike s njihovim rezultatom evaluacije. Kod nas u firmi ovaj skript je zamijenio otprilike tri copy-paste koraka po ticketu, i kolege su ga prigrlili odmah.

# Save as: Get-CASignInDiagnostic.ps1
# Usage: .\Get-CASignInDiagnostic.ps1 -CorrelationId "a1b2c3d4-1234-5678-90ab-cdef12345678"

param(
    [Parameter(Mandatory=$true)]
    [string]$CorrelationId
)

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All" -NoWelcome

$signIn = Get-MgAuditLogSignIn -Filter "correlationId eq '$CorrelationId'" -Top 1

if (-not $signIn) {
    Write-Warning "Nema sign-in eventa za Correlation ID: $CorrelationId"
    Write-Warning "Provjerite je li ID ispravan i mlađi od 30 dana."
    exit 1
}

Write-Host "`n=== CA DIJAGNOSTIKA ===" -ForegroundColor Cyan
Write-Host "Korisnik:        $($signIn.UserPrincipalName)"
Write-Host "Aplikacija:      $($signIn.AppDisplayName)"
Write-Host "IP:              $($signIn.IpAddress)"
Write-Host "Lokacija:        $($signIn.Location.City), $($signIn.Location.CountryOrRegion)"
Write-Host "Klijent:         $($signIn.ClientAppUsed)"
Write-Host "Uređaj:          $($signIn.DeviceDetail.OperatingSystem) / compliant: $($signIn.DeviceDetail.IsCompliant)"
Write-Host "Rezultat:        $($signIn.Status.ErrorCode) - $($signIn.Status.FailureReason)"

Write-Host "`n=== CA POLITIKE ===" -ForegroundColor Cyan
$signIn.AppliedConditionalAccessPolicies | ForEach-Object {
    $color = switch ($_.Result) {
        'success'     { 'Green' }
        'failure'     { 'Red' }
        'notApplied'  { 'Gray' }
        default       { 'Yellow' }
    }
    Write-Host ("{0,-45} {1}" -f $_.DisplayName, $_.Result) -ForegroundColor $color
}

Metrike koje treba pratiti sljedeći mjesec

Bez metrika nema poboljšanja. Ako trenutačno ne mjerite Conditional Access ticket trend, sljedeći mjesec je pravo vrijeme da uvedete minimum ove četiri metrike u helpdesk dashboard. Sve su izvučive iz Sign-in log stream-a u Log Analytics workspaceu s KQL upitima.

CA-blokada postotak: broj sign-in eventa s AADSTS53003 podijeljen s ukupnim brojem sign-in eventa. Cilj: pod 0,5 %. Iznad 1 % označava previše restriktivnu politiku ili nedovoljnu enrolment coverage.
MTTR po AADSTS kodu: prosječno vrijeme od otvaranja ticketa do zatvaranja, grupirano po AADSTS šifri. Cilj: pod 15 minuta za tier-1 kodove (53003, 53000, 50076). Iznad 30 minuta znači da vam trebaju dodatna obuka ili automatizacija.
Repeat rate: postotak korisnika koji su otvorili više od 1 CA ticketa u 30 dana. Cilj: pod 5 %. Visoki repeat rate označava da rješavate simptome, a ne uzrok; najčešće nekompatibilan uređaj ili loše enrolment iskustvo.
Report-only conversion: koliko dana u prosjeku politika ostane u Report-only prije On. Ispod 7 dana znači premalo podataka; iznad 30 dana znači da politika ne završava rollout.

Za dodatni kontekst kako spomenute metrike vezati uz identitetsku sigurnost, korisno je pročitati i naš vodič o Windows Hello for Business i Cloud Kerberos Trust rješavanju, jer WHfB uređaji imaju drastično niži postotak CA blokada nego password-based prijave.

Često postavljana pitanja

Kako korisnik može sam riješiti "Access has been blocked by Conditional Access policies"?

U pravilu ne može. Poruka označava blokadu na strani tenanta i zahtijeva provjeru politike od strane admina. Jedini samostalni koraci koji vrijede pokušati su: signout iz svih Microsoft 365 aplikacija, restart uređaja, provjera je li uređaj Intune-enrolled kroz Company Portal aplikaciju. Ako to ne pomogne, ticket na helpdesk s Correlation ID-om iz poruke.

Koja je razlika između AADSTS53003 i AADSTS53000?

AADSTS53003 je općeniti "blocked by Conditional Access"; može biti bilo koji uvjet politike. AADSTS53000 je specifičniji: uređaj je enrolled u Intune, ali nije compliant prema aktivnoj compliance policy (npr. nedostaje BitLocker, OS verzija je stara, antivirus nije aktivan). Rješenje se razlikuje ovisno o kodu: 53000 se ispravlja u Intune, a 53003 najčešće u CA politici.

Može li se Conditional Access politika testirati bez utjecaja na korisnike?

Da, koristite Report-only mode. Politika se evaluira i logira u Sign-in log, ali ne provodi. Nakon 7 do 14 dana analize možete sigurno prebaciti u On. Kao dodatni sloj, alat What If u Entra portalu simulira scenarije bez ijednog stvarnog logina, korisno za pojedinačne dijagnostike.

Zašto Conditional Access blokira mobilne Outlook prijave, a browser radi?

Najčešći uzrok je Approved client apps uvjet u politici. Samo aplikacije s Intune App Protection ili Modern Auth mogu proći, a stari IMAP/EAS klijenti ne. Rješenje: instalirati službenu Outlook mobilnu aplikaciju iz App Store ili Play Store, ili u politici privremeno isključiti mobilne platforme radi dijagnostike.

Koliko break-glass računa mora imati organizacija?

Microsoft preporučuje minimalno dva emergency access računa po tenantu. Jedan bi mogao biti nedostupan zbog isteka lozinke ili ključa, a dva pružaju N+1 sigurnost. Oba moraju biti cloud-only Global Admin identiteti isključeni iz svih CA politika, s FIDO2 hardver ključevima i aktivnim Azure Monitor alertima na svaki sign-in.

Koji Entra ID plan je potreban za Conditional Access?

Conditional Access zahtijeva Microsoft Entra ID P1 licencu za svakog korisnika koji je predmet politike. Sign-in Risk uvjeti (Identity Protection) zahtijevaju P2 licencu. Report-only mode i What If alat dostupni su unutar P1 plana. Microsoft 365 Business Premium i E3/E5 planovi već uključuju odgovarajuće Entra P1 ili P2 licence.