AADSTS53003 – Ehdollinen käyttöoikeus estää kirjautumisen: Entra ID -vianmääritysopas 2026

Päivitetty: 15. heinäkuuta 2026

AADSTS53003 tarkoittaa, että Microsoft Entra ID -todennus onnistui, mutta Ehdollisen käyttöoikeuden (Conditional Access) käytäntö esti tunnuksen (token) myöntämisen. Toisin sanoen käyttäjä on se, keneksi hän ilmoittaa olevansa, mutta jokin sinun asettamastasi ehdosta ei täyttynyt. Käytännössä syy löytyy lähes aina neljästä paikasta: laitteen compliance-tila, sijaintirajoitus, MFA-vahvuuden vaatimus tai vanha asiakassovellus. Kerron tässä oppaassa täsmällisen työjärjestyksen, jolla saan tikettijonossa palautuvan AADSTS53003-virheen ratkaistua yleensä alle 20 minuutissa.

• AADSTS53003 on aina valtuutusvirhe, ei todennusvirhe. Salasana ja MFA menivät läpi, mutta CA-käytäntö esti tokenin.
• Ensimmäinen askel on Entra-kirjautumisloki ja sen Conditional Access -välilehti; ne kertovat käytännön nimeltä.
• Yleisin todellinen syy vuoden 2026 tiketeissä on laitteen compliance, ei MFA. Erityisesti uudelleenkuvatut Windows 11 24H2 -koneet ja iPadit, joiden Intune Company Portal on vanhentunut.
• Käytä What If -työkalua aina ennen käytäntöjen muutosta, ei sen jälkeen kun kolme myyjäedustajaa on jo tikettijonossa.
• Jokaisessa vuokraajassa on oltava vähintään yksi break-glass -tili, joka on suljettu pois kaikista rajoittavista CA-käytännöistä. Muuten voit lukita itsesi ulos.
• Kesäkuussa 2026 Microsoft muutti kahta asiaa (approved client app -kontrollin poisto ja OIDC-poissulkujen laajempi vaikutus), ja nämä muutokset selittävät osan uudesta AADSTS53003-piikistä.

Mitä AADSTS53003 tarkoittaa?

Virheilmoituksen tekninen sanamuoto on "AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance." Suomeksi käyttäjä näkee usein selaimessa lauseen "Et voi käyttää tätä juuri nyt" tai "Kirjautuminen ei onnistunut, koska organisaation käyttöoikeuskäytäntö esti sen." Molemmat viittaavat samaan taustatapahtumaan.

Tärkein käsitteellinen ero, jonka olen huomannut Tier 1 -tiimieni sisäistävän hitaasti, on tämä: todennus onnistui. Käyttäjä on jo todistanut henkilöllisyytensä salasanalla, MFA-hyväksynnällä tai FIDO2-avaimella. AADSTS53003 syntyy vasta seuraavassa vaiheessa, kun Entra ID arvioi Conditional Access -käytännön ehdot ja päättää, että vaikka kuka on selvillä, mistä, millä laitteella tai millä sovelluksella ei täytä vaatimuksia. Token jää myöntämättä ja käyttäjä työntyy takaisin kirjautumisruutuun.

Tästä syystä tavallinen "kokeile salasanan vaihtoa" tai "tyhjennä selaimen välimuisti" -kierros harvoin auttaa. Ongelma ei ole tunnistautumisessa vaan siinä, mitä tunnistautumisen jälkeen tapahtuu. Muutamia lähisukulaisia virhekoodissa on hyvä tuntea: AADSTS50158 koskee ulkoisen todennusprovaiderin epäonnistumista, AADSTS50076 viittaa MFA-vaatimukseen, jota ei täytetty, ja AADSTS53000 tarkoittaa erityisesti "laite ei ole vaatimustenmukainen". Näiden erottaminen säästää tunnin väärää etsintää.

Yleisimmät syyt kirjautumisen estolle

Kun katson viimeisen 12 kuukauden CDW-tikettejä, AADSTS53003:n perimmäiset syyt jakautuvat karkeasti seuraavasti: laitteen compliance-vika (noin 45 %), sijainti- tai IP-poissulku (noin 20 %), MFA-vahvuusvaatimus, joka ei täyty vanhalla asiakassovelluksella (noin 15 %), kolmannen osapuolen MFA:n Custom Control -integraation kaatuminen (noin 10 %) ja loppu jakautuu common-päätepisteen käytön, palvelutunnusten ja Terms of Use -sivun välille.

Käytännössä nämä tarkoittavat seuraavia konkreettisia tilanteita, jotka toistuvat viikoittain:

• Uudelleenkuvattu tai uusi laite: Autopilotin jälkeen laite ei ehdi rekisteröityä Intuneen ennen kuin käyttäjä yrittää avata Teamsin. CA-käytäntö "Vaadi vaatimustenmukainen laite" torjuu tokenin. Käyn Autopilot-virheitä syvemmin läpi Windows Autopilot -käyttöönoton vianmääritysoppaassa.
• Vanhentunut Intune Company Portal iPadilla: App Storen sovellus on päivittämättä, MDM-sertifikaatti on umpeutunut, ja laite raportoituu "not compliant" -tilassa.
• Yhtäkkinen VPN-ulostulon vaihtuminen: uusi VPN-yhdyskäytävä lisättiin, mutta CA-käytännön Trusted Locations -listaa ei päivitetty. Katso myös Windows 11 VPN-yhteysongelmat -opas.
• Legacy-todennuksen esto: POP/IMAP-asiakas yrittää basic-authia ja saa oston yhteydessä 53003:n oikean 401:n sijaan.
• Palvelutunnukset: automaatioskripti käyttää common-päätepistettä tenantin oman GUIDin sijaan, ja MFA-vaatimusta ei voi täyttää.

Se, että syy on lähes aina konfiguraatiovirhe eikä Microsoftin bugi, on rehellisesti sanottuna sekä hyvä että huono uutinen: hyvä siksi, että voit korjata sen itse; huono siksi, että ratkaisut ovat aina tapauskohtaisia.

Löydä estävä käytäntö kirjautumislokista

Ensimmäinen askel jokaisessa 53003-tapauksessa on Entra ID:n kirjautumisloki. Älä ryhdy muuttamaan käytäntöjä ennen kuin tiedät nimeltä, mikä käytäntö torjui pyynnön. Toimi näin:

1. Avaa Microsoft Entra admin center osoitteessa entra.microsoft.com.
2. Siirry kohtaan Identity → Monitoring & health → Sign-in logs.
3. Suodata käyttäjän UPN:llä (esim. [email protected]) ja aikavälillä, joka kattaa hänen viimeisimmän yritysajankohtansa. Käytä paikallisaikaa, sillä kello Entrassa on UTC.
4. Etsi rivi, jossa Status = Failure ja Error code = 53003. Klikkaa auki.
5. Avaa Conditional Access -välilehti. Näet luettelon kaikista käytännöistä, joita evaluoitiin. Se, jossa lukee Result: Failure ja Grant controls: Block (tai puuttuva vaatimustäyttö), on syyllinen.
6. Kirjoita Policy ID muistiin, sitä tarvitset seuraavassa vaiheessa Policies-näkymässä.

Myös Troubleshooting and support -välilehti kannattaa avata. Sieltä löytyy usein selväkielinen "Device didn't meet compliance requirements" tai "User failed multi-factor authentication" -syy. Tämä on nopein tapa erottaa laite-, MFA- ja sijaintiongelmat toisistaan.

PowerShellillä sama tieto irtoaa Graph API:n kautta ilman selailua:

# Vaatii Microsoft.Graph.Beta -moduulin ja AuditLog.Read.All -oikeuden
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

$upn = "[email protected]"
$since = (Get-Date).AddHours(-4).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgBetaAuditLogSignIn `
    -Filter "userPrincipalName eq '$upn' and status/errorCode eq 53003 and createdDateTime ge $since" `
    -Top 20 |
    Select-Object CreatedDateTime, AppDisplayName, IpAddress, `
        @{n='FailedPolicy';e={($_.AppliedConditionalAccessPolicies |
            Where-Object Result -eq 'failure').DisplayName -join ', '}}

Skripti listaa viimeisen neljän tunnin 53003-yritykset ja nimeää epäonnistuneet käytännöt suoraan sarakkeeksi. Ajan sen aina, kun useampi käyttäjä samasta ryhmästä valittaa. Näet heti, onko kyseessä sama vai eri käytäntö.

What If -työkalu käytäntöjen simulointiin

What If on ainoa oikea tapa testata, mitä käyttäjälle tapahtuu ennen kuin muutat mitään tuotannossa. Se elää Entra-portaalissa polulla Protection → Conditional Access → Policies → What If.

Anna työkalulle vähintään seuraavat parametrit: User or workload identity (koodattu käyttäjä), Cloud apps or actions, Device platform, Client app, Sign-in risk level (jos Identity Protection on käytössä) ja Country. Klikkaa What If ja saat kaksi listaa: Policies that will apply ja Policies that will not apply. Jokainen käytäntö näyttää myös vaadittavat kontrollit (esim. "Require MFA", "Require compliant device").

Käytännön käyttötapaus: kun myyntiedustaja soittaa Ranskasta iPadillaan eikä pääse Outlookiin, en enää arvaa mikä käytäntö osui. Ajatan What If -simuloinnin parametreilla iOS + Outlook mobile + Ranska + kyseinen käyttäjä. Sekunneissa näen, että "Require Approved Client App – Mobile" osuu ja vaatii Outlook-appin, joka on ehkä poistettu tai vanhentunut. Ilman simulointia menisi 20 minuuttia lokien selaamista.

Korjaus 1: Laitteen vaatimustenmukaisuus (compliance)

Compliance-vikoja on karkeasti kaksi tyyppiä. Ensimmäinen: laite ei ole rekisteröity Entra-liittymään lainkaan. Toinen: laite on rekisteröity, mutta Intune-compliance-käytäntö raportoituu "not compliant". Molemmat aiheuttavat 53003:n, jos CA-käytäntö vaatii "compliant device" -kontrollia.

Windows 11:llä tarkista järjestyksessä:

# 1) Onko laite rekisteröity Entraan ja Intuneen?
dsregcmd /status

# Etsi lohkot Device State ja SSO State:
#   AzureAdJoined : YES     ← muuten laite ei ole hallinnassa
#   TenantName    : YourOrg
#   MdmUrl        : https://enrollment.manage.microsoft.com/...
# Jos MdmUrl on tyhjä, laite EI ole Intunessa vaikka olisi Entra-joined.

# 2) Pakota compliance-arviointi
Get-ScheduledTask -TaskName "PushLaunch" |
    Where-Object TaskPath -like "*EnterpriseMgmt*" |
    Start-ScheduledTask

# 3) Katso viimeisin tulos
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" `
    -MaxEvents 20 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

Jos dsregcmd raportoi AzureAdJoined : NO, laite ei ole vaatimustenmukainen millään käytännöllä. Aja rekisteröinti uudelleen tai käytä Autopilot Resettiä. Yksityiskohdat Intune-rekisteröinnin virheille löydät Intune-laiterekisteröinnin virheet Windows 11:ssä -oppaasta.

Jos laite on rekisteröity mutta not compliant, avaa Intune admin center → Devices → All devices → valitse laite → Device compliance. Näet, mikä yksittäinen ehto (BitLocker, Defender, salasanapolitiikka, minimikäyttöjärjestelmä) epäonnistui. Korjaa se ja aja Sync Company Portal -sovelluksesta. Compliance-tilan päivittyminen kestää yleensä 5–30 minuuttia.

AADSTS53000 vs AADSTS53003: jos näet lokissa 53000:n eikä 53003:a, kyseessä on nimenomaan compliance-vika ("Device not compliant"). 53003 on yleisluontoisempi ja voi tarkoittaa mitä tahansa CA-ehdon täyttymättömyyttä. Käytännössä ratkaisu on kuitenkin usein sama.

Korjaus 2: Käytä tenant-kohtaista päätepistettä

Kun automaatioskripti tai kolmannen osapuolen sovellus autentikoituu https://login.microsoftonline.com/common -päätepisteeseen, Entra yrittää arvata, mihin vuokraajaan käyttäjä kuuluu. Tämä toimii interaktiivisissa selainkirjautumisissa, mutta rikkoo automaation, kun CA-käytäntö on ankarampi. Vaihda päätepiste vuokraajan GUIDiin:

# Ennen (rikki 53003:n kanssa)
$authority = "https://login.microsoftonline.com/common"

# Jälkeen (käyttää tenant-kohtaista päätepistettä)
$tenantId  = "8f7c9d10-1234-4b5c-9d6e-abcdef012345"
$authority = "https://login.microsoftonline.com/$tenantId"

# MSAL.PS -esimerkki
Import-Module MSAL.PS
$token = Get-MsalToken `
    -ClientId "11111111-2222-3333-4444-555555555555" `
    -TenantId $tenantId `
    -Scopes "https://graph.microsoft.com/.default"

Sama pätee C#-koodiin (ConfidentialClientApplicationBuilder.Create(...).WithAuthority(AzureCloudInstance.AzurePublic, tenantId)) ja Python-msal-kirjastoon (authority="https://login.microsoftonline.com/{tenantId}"). Tenant-kohtainen päätepiste ohittaa "unknown tenant" -tulkinnan, joka joskus ohjaa CA-arvioinnin väärään vuokraajakontekstiin.

Korjaus 3: Kolmannen osapuolen MFA (DUO Custom Control)

DUO Custom Control ei täytä Microsoftin natiivia MFA-claimia. Tämä on 2026:n toistuvin sudenkuoppa, kun asiakas migratoituu Duon Traditional Promptista Universal Promptiin. Jos CA-käytäntö vaatii "Require multifactor authentication", DUO-hyväksyntä ei riitä. Ei siksi että käyttäjä olisi tehnyt jotain väärin, vaan siksi että Entra ei näe MFA-suoritettua-claimia tokenissa.

Vaihtoehtoja on käytännössä kolme:

1. Vaihda DUO SSO -federaatioon: DUO SSO välittää MFA-claimin AD FS:n tai SAML:n kautta, jolloin Entra hyväksyy sen natiivina MFA:na. Suositeltavin ratkaisu isoille organisaatioille.
2. Käytä DUO External Authentication Methods (EAM) -integraatiota: vuodesta 2024 GA, korvaa Custom Controlin. Vaatii Entra ID P1 -lisenssin ja EAM-esikatselukäyttäjien testausvaiheen.
3. Rakenna CA-käytäntö niin, että se hyväksyy Custom Controlin: lisää DUO Custom Control Grant-osioon "Require one of the selected controls" -tilassa. Toimii, mutta menetät MFA-claimin näkyvyyden lokeissa ja Sentinelissä.

Suosittelen vaihtoehtoa 1 tai 2. Vaihtoehto 3 tulee vastaan sisäisenä tikettinä ennemmin tai myöhemmin, kun joku yrittää raportoida MFA-adoption Entra-sisäänrakennetuista raporteista.

Korjaus 4: Break-glass ja käytäntöjen poissulut

Yleisin katastrofiskenaario, jonka olen nähnyt, on tenant-laajuinen Block-käytäntö, joka luodaan "kaikki käyttäjät + kaikki resurssit" -laajuudella ilman poissulkuja. Kun se otetaan käyttöön, myös luoja lukitaan ulos, eikä käytäntöä voi enää muuttaa portaalissa. Ainoa palautuskeino on Microsoft Support ja tenant-omistajuuden todistaminen — tämä kestää tunneista päiviin.

Estä tämä luomalla vähintään yksi break-glass -tili per vuokraaja seuraavasti. Microsoft dokumentoi mallin myös Emergency access accounts -ohjeessa:

• Anna sille pitkä (32+ merkkiä) satunnainen salasana, tallenna se fyysisesti kassakaappiin.
• Anna sille Global Administrator -rooli pysyvästi (ei PIM-eligible, muuten et pääse aktivoimaan roolia hätätilanteessa).
• Sulje se pois kaikista CA-käytännöistä poissuljettujen käyttäjien listalla.
• Konfiguroi hälytys, joka lähettää SOC-tiimille tekstiviestin aina, kun tili kirjautuu sisään. Toteuta se Entra Workbookilla tai Sentinelin analytic rulella.
• Testaa kirjautuminen kerran neljännesvuodessa, ja rotatoi salasana.

Jos olet jo lukossa ilman break-glass -tiliä, avaa Microsoft-tukitiketti severity A -tasolla. Valmistele todistus tenant-omistajuudesta (verified domain, GA-tilit, laskutustiedot). Palautus on manuaalinen ja edellyttää useamman Microsoftin insinöörin osallistumista.

Kesäkuu 2026: Conditional Access -muutokset

Microsoft toi kaksi merkittävää muutosta kesäkuussa 2026, ja molemmat ovat aiheuttaneet 53003-piikin monissa ympäristöissä:

1. 15.6.2026 – "All resources" -käytännöt vaikuttavat aiempiin ohitettuihin OIDC-kirjautumisiin. Aiemmin tietyt OpenID Connect -flow'it eivät osuneet "All cloud apps" -laajuisiin käytäntöihin. Muutoksen jälkeen ne osuvat, mikä yllättää ne, joilla on poissulut vain nimetyillä sovelluksilla.
2. 30.6.2026 – Require Approved Client App -kontrolli poistuu käytöstä. Se korvataan App Protection Policy (MAM) -kontrollilla. Käytännöt, joissa on vielä approved-client-app-vaatimus, alkavat aiheuttaa AADSTS53003:a, kunnes ne migratoidaan.

Auditoi näiden osalta koko käytäntösi Microsoft Graph -PowerShellillä:

Connect-MgGraph -Scopes "Policy.Read.All"

# Etsi käytännöt, jotka vielä käyttävät approvedApplication-grantia
Get-MgIdentityConditionalAccessPolicy |
    Where-Object { $_.GrantControls.BuiltInControls -contains "approvedApplication" } |
    Select-Object DisplayName, State, Id

Testaa muutokset aina report-only -tilassa ennen enforcementia. Report-only kirjaa lokiin, mitä olisi tapahtunut, muttei estä käyttäjää. Yhdistettynä Conditional Access Insights and Reporting -työkirjaan Log Analytics -työtilassa saat rinnakkaisnäkymän uuden ja vanhan käytännön vaikutuksesta.

Vianmääritys iPad- ja iPhone-laitteille

Kentän myyntitiimin iPadit ovat oma taide-alansa. Rehellisesti, iOS-liittymien kanssa menee joskus kaksi kolmasosaa aamusta. Nämä ovat viisi useimmin toistuvaa syytä, joiden takia iOS-laite saa AADSTS53003:n vaikka Windows-käyttäjät samassa CA-käytännössä pääsevät läpi:

1. Company Portal on vanhentunut App Storessa. Pakota päivitys ja käynnistä uudelleen. Applen App Store ei aina päivitä yritysjulkaistuja versioita.
2. MDM-sertifikaatti on umpeutunut. Katso Settings → General → VPN & Device Management → Management Profile → Certificates. Jos päivämäärä on menneisyydessä, rekisteröi laite uudelleen.
3. Outlook-sovellus vs. Safari: jos CA vaatii "Require App Protection Policy", Safari ei koskaan pääse läpi. Vain Outlook, Teams ja muut Intune-suojatut sovellukset kelpaavat, joten käyttäjä on ohjattava natiiviin appiin.
4. Location Services pois päältä: jos CA-käytännössä on maasuljku, Entra ei saa sijaintia iOS:ltä silloin kun käyttäjä on estänyt sijaintioikeuden. Käytäntö tulkitsee sen "unknown location" -riskiksi ja estää.
5. Vanha iOS-versio: iOS 16 ja sitä vanhemmat eivät tue joitain uusia auth-metodeja. Vaadi vähintään iOS 17 (elokuu 2026 baseline).

Nopea kentällä toimiva tsekkilista: Company Portal → Sign out → Sign in → Sync. Se korjaa noin 60 % iPad-liittymien 53003-tapauksista, koska se pakottaa MDM-sertin päivityksen ja compliance-arvioinnin uudelleen. Jos siitäkään ei apua, laite pitää poistaa Intunesta ja rekisteröidä uudelleen.

Sama pätee soveltuvin osin Android Enterprise -laitteisiin. Siellä käytännön esto näkyy usein Company Portalin "This device is not compliant" -banneriksi, ei suoraan AADSTS53003:na. Aiheeseen liittyen kannattaa lukea myös Active Directory -tilien lukituksen vianmääritysopas, jos näet toistuvia epäonnistuneita kirjautumisia ennen 53003-lopputulosta.

Usein kysytyt kysymykset

Miten ohitan Conditional Access -käytännön hätätilanteessa?

Käytä break-glass -tiliä, joka on suljettu pois kaikista rajoittavista CA-käytännöistä. Jos tällaista ei ole luotu ennalta, tavallinen käyttäjä ei voi ohittaa käytäntöä. Microsoft Support on ainoa reitti. Älä koskaan luo "All users + All resources + Block" -käytäntöä ilman poissulkuja tai sen alle putoaa myös itse.

Mikä ero on AADSTS53000:n ja AADSTS53003:n välillä?

AADSTS53000 tarkoittaa erityisesti "laite ei ole vaatimustenmukainen", eli kyseessä on compliance-vika. AADSTS53003 on yleisempi Conditional Access -esto, joka voi johtua myös MFA:sta, sijainnista, client appista tai muusta CA-ehdosta. Jos näet 53000:n, katso Intune compliance ensin; 53003:n kohdalla aloita sign-in-lokista.

Miksi Conditional Access estää kirjautumiseni vaikka MFA hyväksyttiin?

MFA-hyväksyntä täyttää vain MFA-vaatimuksen. Käytäntö saattaa vaatia myös vaatimustenmukaista laitetta, sallittua sijaintia tai hyväksyttyä sovellusta. Katso Entra-kirjautumislokin Conditional Access -välilehdeltä, mikä kontrolli näyttää "Not satisfied" -tilaa. Se on todellinen syy.

Miten näen, mikä Conditional Access -käytäntö estää tietyn käyttäjän?

Avaa Entra admin center → Sign-in logs → suodata käyttäjän UPN:llä → löydä 53003-rivi → avaa Conditional Access -välilehti. Käytäntö, jonka Result on "Failure" ja Grant control "Block" (tai tyydyttämätön), on estäjä. Voit myös simuloida What If -työkalulla tulevat kirjautumiset ennen käytännön käyttöönottoa.

Poistaako laitteen uudelleenkäynnistys AADSTS53003-virheen?

Ei suoraan, mutta se voi laukaista compliance-arvioinnin uudelleen ja päivittää MDM-sertifikaatin. Jos ainoa syy oli hetkellinen compliance-drift (esim. BitLocker-avainten kirjaus kesken), uudelleenkäynnistys ja Company Portalin Sync-nappi voivat riittää. Muissa tapauksissa käytäntö tai laitteen tila on korjattava manuaalisesti.

Voiko AADSTS53003 johtua PowerShell-skriptistä tai automaatiosta?

Kyllä, erittäin usein. Non-interaktiiviset auth-flow'it (client credentials, ROPC, device code) eivät voi täyttää MFA- tai compliant-device-vaatimuksia. Sulje palvelutunnukset pois asianmukaisilta CA-käytännöiltä nimenomaan sen palvelutunnuksen kohdalla, älä koko käytäntöä pois päältä.

Lisätietoja Microsoftin omista lähteistä: Troubleshoot sign-in problems with Conditional Access, Conditional Access report-only mode ja Microsoft Q&A: AADSTS53003 -keskustelu.