AD-tilien lukituksen vianmääritys – PowerShell, tapahtumalokien analyysi ja Entra ID

Miksi AD-tilit lukittuvat — ja miksi syyn löytäminen on niin vaikeaa?

Tilien lukittuminen on yksi IT-helpdeskin yleisimmistä tukipyynnöistä. Käyttäjä soittaa, kertoo ettei pääse kirjautumaan, ja sinun pitäisi jotenkin selvittää mistä ongelma johtuu. Salasana on vaihdettu viime viikolla, eikä käyttäjä muista syöttäneensä väärää salasanaa. Kuulostaako tutulta? Jos olet ollut helpdeskissä edes vuoden, tiedät tarkalleen mistä puhun.

Todellisuudessa lukittumisen syy harvoin on pelkästään väärä salasana. Vanhat välimuistissa olevat tunnistetiedot, taustalla pyörivät palvelut, mobiililaitteiden sähköpostisynkronointi tai jopa verkkolevyjen yhdistäminen voivat kaikki laukaista lukituksen. Ja usein ilman, että käyttäjä edes huomaa mitään tapahtuvan.

Eli, käydään tämä läpi järjestelmällisesti. Katsotaan miten lukituksen lähde löydetään, mitä PowerShell-komentoja tarvitset, ja miten hybriidiympäristön Entra ID Smart Lockout vaikuttaa kokonaisuuteen.

Tilien lukituskäytännön perusteet Active Directoryssa

Ennen kuin aletaan kaivella lokeja, on hyvä ymmärtää miten lukituskäytäntö oikeasti toimii. Active Directoryn salasanakäytäntö määrittelee kolme keskeistä asetusta:

• Account lockout threshold — kuinka monta virheellistä kirjautumisyritystä sallitaan ennen lukitusta (tyypillisesti 3–10)
• Account lockout duration — kuinka kauan tili pysyy lukittuna minuutteina (esim. 15–30 min, tai 0 = pysyvä lukitus kunnes admin avaa)
• Reset account lockout counter after — kuinka nopeasti epäonnistuneiden yritysten laskuri nollautuu

Nämä asetukset löytyvät ryhmäkäytännöstä polusta Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy.

Tarkista nykyiset asetukset nopeasti PowerShellillä:

# Näytä toimialueen lukituskäytäntö
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

Jos LockoutThreshold on 0, lukituskäytäntö ei ole käytössä. Useimmissa yritysympäristöissä suositellaan arvoa 5–10 — liian matala kynnys aiheuttaa turhia lukituksia, liian korkea heikentää tietoturvaa.

Lukittuneiden tilien tunnistaminen PowerShellillä

Ensimmäinen askel on selvittää, mitkä tilit ovat tällä hetkellä lukittuina. PowerShellin Search-ADAccount-komento on tähän ylivoimaisesti tehokkain työkalu.

Listaa kaikki lukitut tilit

# Näytä kaikki lukitut tilit toimialueella
Search-ADAccount -LockedOut | Select-Object SamAccountName, Name, LockedOut, LastLogonDate | Format-Table -AutoSize

Tarkista yksittäisen käyttäjän tila

# Tarkista tietyn käyttäjän lukitustila ja viimeinen salasananvaihto
Get-ADUser -Identity matti.meikalainen -Properties LockedOut, AccountLockoutTime, BadLogonCount, BadPasswordTime, PasswordLastSet |
  Select-Object SamAccountName, LockedOut, AccountLockoutTime, BadLogonCount, @{N="BadPasswordTime";E={[datetime]::FromFileTime($_.BadPasswordTime)}}, PasswordLastSet

Vinkki: BadLogonCount-arvo kertoo, kuinka monta virheellistä kirjautumisyritystä on kertynyt. Jos arvo on lähellä lukituskynnystä, tili lukittuu todennäköisesti uudelleen hyvin pian — vaikka juuri avaisit sen. Tähän kannattaa kiinnittää huomiota ennen kuin alkaa avaamaan tilejä sokkona.

Tilin avaaminen

# Avaa lukittu tili
Unlock-ADAccount -Identity matti.meikalainen

# Vahvista avauksen onnistuminen
Get-ADUser -Identity matti.meikalainen -Properties LockedOut | Select-Object SamAccountName, LockedOut

Tilin avaaminen on kuitenkin vasta ensimmäinen askel. Rehellisesti sanottuna — jos et selvitä lukituksen juurisyytä, tili lukittuu uudelleen minuuttien sisällä. Ja saat saman puhelun uudestaan.

Lukituksen lähteen selvittäminen — Event ID 4740 ja 4625

Tämä on koko vianmäärityksen tärkein vaihe. Tässä kohtaa selvitetään, mistä ne virheelliset kirjautumisyritykset oikeasti tulevat.

Active Directory kirjaa lukitustapahtuman (Event ID 4740) Security-lokiin sillä toimialueen ohjauskonella, joka toimii PDC Emulator -roolissa. Tämä on aina ensimmäinen paikka, josta kannattaa etsiä.

Vaihe 1: Etsi PDC Emulator

# Selvitä PDC Emulator -toimialueen ohjauskone
Get-ADDomain | Select-Object PDCEmulator

Vaihe 2: Hae lukitustapahtumat (Event ID 4740)

# Hae kaikki lukitustapahtumat PDC Emulatorilta
Get-WinEvent -ComputerName (Get-ADDomain).PDCEmulator -FilterHashtable @{
    LogName   = "Security"
    Id        = 4740
} -MaxEvents 20 | ForEach-Object {
    [PSCustomObject]@{
        Aika            = $_.TimeCreated
        Kayttaja        = $_.Properties[0].Value
        LahdeKone       = $_.Properties[1].Value
    }
} | Format-Table -AutoSize

Caller Computer Name -kenttä on tässä se avaintieto: se kertoo, miltä koneelta virheelliset kirjautumisyritykset tulivat. Kirjoita tämä ylös — tarvitset sitä ihan kohta.

Vaihe 3: Tutki lähdekone (Event ID 4625)

Kun tiedät lähdekoneen, siirry tutkimaan sen paikallista Security-lokia. Event ID 4625 kertoo epäonnistuneen kirjautumisen yksityiskohdat:

# Hae epäonnistuneet kirjautumiset lähdekonelta tietylle käyttäjälle
Get-WinEvent -ComputerName LAHDEKONEEN-NIMI -FilterHashtable @{
    LogName = "Security"
    Id      = 4625
} -MaxEvents 50 | Where-Object {
    $_.Properties[5].Value -eq "matti.meikalainen"
} | ForEach-Object {
    [PSCustomObject]@{
        Aika            = $_.TimeCreated
        Kayttaja        = $_.Properties[5].Value
        KirjautumisTyyppi = $_.Properties[10].Value
        ProsessinNimi   = $_.Properties[18].Value
        LahdeIP         = $_.Properties[19].Value
    }
} | Format-Table -AutoSize

Kiinnitä erityistä huomiota näihin kenttiin:

• Logon Type — kertoo kirjautumisen tyypin (2 = interaktiivinen, 3 = verkkoyhteys, 10 = etätyöpöytä)
• Process Name — paljastaa mikä sovellus tai palvelu yritti kirjautua
• Source Network Address — IP-osoite, josta yritys tuli

Yleisimmät Logon Type -arvot ja niiden merkitys

• Tyyppi 2 (Interactive): Käyttäjä kirjautui suoraan koneelle — tyypillisesti väärä salasana lukitusnäytöllä
• Tyyppi 3 (Network): Verkkoyhteys, esim. verkkolevyasema tai SharePoint — melkein aina vanhat tunnistetiedot välimuistissa
• Tyyppi 7 (Unlock): Työaseman lukituksen avaus — käyttäjä syöttää vanhan salasanan (tämä on yllättävän yleistä)
• Tyyppi 10 (RemoteInteractive): Etätyöpöytäyhteys (RDP) — joku yrittää kirjautua etäyhteydellä

Koottu diagnostiikkaskripti: Lukituksen syyn selvittäminen

Tässä on valmis skripti, joka yhdistää kaikki edellä mainitut vaiheet yhdeksi komennoksi. Oman kokemukseni perusteella tämä säästää valtavasti aikaa — tallenna se ja käytä aina kun lukitusongelma tulee vastaan:

# AD-tilien lukituksen diagnostiikkaskripti
# Käyttö: .\Get-LockoutSource.ps1 -Username "matti.meikalainen"
param(
    [Parameter(Mandatory=$true)]
    [string]$Username
)

# Hae PDC Emulator
$PDC = (Get-ADDomain).PDCEmulator
Write-Host "PDC Emulator: $PDC" -ForegroundColor Cyan

# Tarkista käyttäjän tila
$User = Get-ADUser -Identity $Username -Properties LockedOut, AccountLockoutTime, BadLogonCount, PasswordLastSet
Write-Host "`n--- Käyttäjän tila ---" -ForegroundColor Yellow
Write-Host "Tili lukittu: $($User.LockedOut)"
Write-Host "Lukitusaika: $($User.AccountLockoutTime)"
Write-Host "Virheelliset yritykset: $($User.BadLogonCount)"
Write-Host "Salasana vaihdettu: $($User.PasswordLastSet)"

# Hae lukitustapahtumat PDC:ltä
Write-Host "`n--- Lukitustapahtumat (Event ID 4740) ---" -ForegroundColor Yellow
$LockoutEvents = Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName = "Security"
    Id      = 4740
} -MaxEvents 100 | Where-Object {
    $_.Properties[0].Value -eq $Username
}

if ($LockoutEvents) {
    $LockoutEvents | ForEach-Object {
        [PSCustomObject]@{
            Aika       = $_.TimeCreated
            LahdeKone  = $_.Properties[1].Value
        }
    } | Format-Table -AutoSize
} else {
    Write-Host "Ei lukitustapahtumia löytynyt." -ForegroundColor Red
}

# Jos lähdekone löytyi, hae lisätiedot
if ($LockoutEvents) {
    $SourceComputer = $LockoutEvents[0].Properties[1].Value
    Write-Host "--- Epäonnistuneet kirjautumiset lähteeltä: $SourceComputer ---" -ForegroundColor Yellow
    try {
        Get-WinEvent -ComputerName $SourceComputer -FilterHashtable @{
            LogName = "Security"
            Id      = 4625
        } -MaxEvents 20 | Where-Object {
            $_.Properties[5].Value -eq $Username
        } | ForEach-Object {
            [PSCustomObject]@{
                Aika      = $_.TimeCreated
                Tyyppi    = $_.Properties[10].Value
                Prosessi  = $_.Properties[18].Value
                LahdeIP   = $_.Properties[19].Value
            }
        } | Format-Table -AutoSize
    } catch {
        Write-Host "Lähdekoneen lokeja ei voitu lukea: $_" -ForegroundColor Red
    }
}

Yleisimmät lukituksen syyt ja niiden ratkaisut

Kun olet selvittänyt lähdekoneen ja prosessin, ongelma yleensä paikantuu johonkin näistä. Käydään ne läpi yksitellen.

1. Välimuistissa olevat vanhat tunnistetiedot

Tämä on ylivoimaisesti yleisin syy. Ja tarkoitan ylivoimaisesti — omien havaintojeni mukaan noin 70 % lukitusongelmista johtuu tästä. Käyttäjä on vaihtanut salasanansa, mutta vanha salasana on edelleen tallennettuna johonkin.

Tarkistuskohteet:

• Windows Credential Manager: Avaa Ohjauspaneeli → Tunnistetietojen hallinta ja poista vanhentuneet merkinnät
• Selainten tallennetut salasanat: Chrome, Edge ja Firefox tallentavat kirjautumistietoja, jotka voivat yrittää todennusta automaattisesti
• Verkkolevyasemat: Tarkista, onko käyttäjällä yhdistettyjä verkkolevyjä, jotka käyttävät tallennettuja tunnistetietoja

# Näytä tallennetut tunnistetiedot komentoriviltä
cmdkey /list

# Poista tietty tallennettu tunniste
cmdkey /delete:Domain:interactive=TOIMIALUE\matti.meikalainen

2. Palvelut, jotka käyttävät käyttäjän tunnuksia

Windows-palvelut, jotka on konfiguroitu käynnistymään tietyn AD-tilin tunnuksilla, yrittävät todentautua automaattisesti. Jos salasana on vaihdettu eikä palvelua ole päivitetty, jokainen käynnistysyritys kasvattaa epäonnistuneiden kirjautumisten laskuria. Tämä on erityisen salakavala ongelma, koska se voi tapahtua täysin käyttäjän tietämättä.

# Etsi palvelut, jotka käyttävät tiettyä tiliä (suorita lähdekonella)
Get-WmiObject Win32_Service | Where-Object {
    $_.StartName -like "*matti.meikalainen*"
} | Select-Object Name, DisplayName, StartName, State | Format-Table -AutoSize

3. Ajoitetut tehtävät vanhoilla tunnistetiedoilla

Toinen klassikko. Joku on joskus luonut ajoitetun tehtävän käyttäjän tunnuksilla, ja nyt se hiljaisesti epäonnistuu taustalla.

# Etsi ajoitetut tehtävät, jotka käyttävät tiettyä tiliä
Get-ScheduledTask | Where-Object {
    $_.Principal.UserId -like "*matti.meikalainen*"
} | Select-Object TaskName, TaskPath, @{N="RunAs";E={$_.Principal.UserId}} | Format-Table -AutoSize

4. Mobiililaitteiden sähköpostisynkronointi

Älypuhelimet ja tabletit, joissa on konfiguroitu Exchange-sähköpostitili, yrittävät synkronoida säännöllisesti. Jos laitteeseen on tallennettu vanha salasana, se voi aiheuttaa useita epäonnistuneita todennusyrityksiä lyhyessä ajassa — jopa kymmeniä minuutissa.

Ratkaisu: Pyydä käyttäjää päivittämään salasana mobiililaitteen sähköpostiasetuksissa tai poistamaan tili ja lisäämään se uudelleen. Yksinkertaista, mutta yllättävän usein unohdetaan.

5. RDP-yhteydet vanhoilla tunnistetiedoilla

Etätyöpöytäyhteyden .rdp-tiedostot voivat sisältää tallennettuja tunnistetietoja. Jos näet Logon Type 10 Event ID 4625 -tapahtumassa, tämä on hyvin todennäköinen syy.

# Poista RDP:n tallennetut tunnistetiedot
cmdkey /list | Select-String "TERMSRV" | ForEach-Object {
    $target = ($_ -split ":")[1].Trim()
    cmdkey /delete:$target
}

6. Mahdollinen brute force -hyökkäys

Jos lukituksia tapahtuu epätavallisista IP-osoitteista tai lähdekoneilta, kyseessä voi olla hyökkäysyritys. Tarkista nämä hälytysmerkit:

• Tulevatko yritykset tuntemattomasta IP-osoitteesta?
• Kohdistuvatko lukitukset useisiin tileihin samanaikaisesti?
• Tapahtuvatko yritykset työajan ulkopuolella?

Jos vastaus on kyllä yhteenkin näistä, eskaloi asia tietoturvatiimille. Tässä ei kannata jäädä arvailemaan.

Hybriidiympäristö: Entra ID Smart Lockout ja AD-synkronointi

No niin, tässä mennään astetta monimutkaisemmaksi. Vuonna 2026 suurin osa organisaatioista toimii hybriidiympäristössä, jossa paikallinen Active Directory on synkronoitu Microsoft Entra ID:n (entinen Azure AD) kanssa. Tämä tuo lukituskäytäntöihin yhden lisäkerroksen, joka on syytä ymmärtää.

Entra ID Smart Lockout

Microsoft Entra ID käyttää älykästä lukitusta (Smart Lockout), joka osaa erottaa aidot käyttäjät hyökkääjistä. Oletusasetuksilla tili lukittuu 10 epäonnistuneen yrityksen jälkeen yhdeksi minuutiksi, ja lukitusaika kasvaa toistuvien epäonnistumisten myötä.

Smart Lockout toimii kahdella erillisellä laskurilla:

• Tuttu sijainti — kirjautumisyritykset tutuista laitteista tai sijainneista
• Tuntematon sijainti — uusista tai epätavallisista paikoista tulevat yritykset (tähän sovelletaan tiukempia rajoja)

Kriittiset kynnysarvot hybriidiympäristössä

Tämä on se kohta, jossa monet menevät metsään. Jos käytät pass-through-todennusta (PTA), lukituskäytännöt täytyy koordinoida huolellisesti paikallisen AD:n ja Entra ID:n välillä:

• Entra ID:n lukituskynnyksen tulee olla pienempi kuin paikallisen AD:n kynnyksen
• Entra ID:n lukitusajan tulee olla pidempi kuin AD:n lukitusajan
• Suositeltu suhde: AD:n kynnys vähintään 2–3 kertaa Entra ID:n kynnys

Esimerkki suositelluista asetuksista:

• Entra ID: lukituskynnys 10, lukitusaika 120 sekuntia
• Paikallinen AD: lukituskynnys 20–30, lukitusaika 1 minuutti

Näin Entra ID suodattaa suurimman osan hyökkäysyrityksistä ennen kuin ne pääsevät paikalliseen AD:hen asti. Aika näppärää, eikö?

Password Hash Sync (PHS) -rajoitus

Jos käytät salasanojen tiivisteiden synkronointia (PHS), paikallisen AD:n lukitustila ei synkronoidu Entra ID:hen. Käytännössä tämä tarkoittaa, että paikallisessa AD:ssä lukittu käyttäjä voi edelleen kirjautua Microsoft 365 -palveluihin pilven kautta. Jos tämä on riski organisaatiollesi, harkitse siirtymistä PTA-todennukseen.

Entra Connect -päivitys 2026

Tärkeä huomio, joka kannattaa laittaa muistiin: Microsoft vaatii kaikkia asiakkaita päivittämään Microsoft Entra Connect versioon 2.5.79.0 tai uudempaan 30.9.2026 mennessä. Päivittämättä jättäminen aiheuttaa synkronointipalveluiden katkeamisen — eli tämä ei ole valinnainen päivitys.

# Tarkista Entra Connect -versio (suorita Entra Connect -palvelimella)
Get-ADSyncGlobalSettings | Select-Object -ExpandProperty Parameters |
  Where-Object { $_.Name -eq "Microsoft.Synchronize.ServerConfigurationVersion" }

Auditointikäytännön varmistaminen

Lukitustapahtumien seuraaminen vaatii, että auditointikäytäntö on konfiguroitu oikein. Ilman sitä tapahtumalokeihin ei yksinkertaisesti kirjata tarvittavia tietoja, ja kaikki edellä mainitut komennot palauttavat tyhjää.

Tarkista nykyinen auditointikäytäntö

# Tarkista, onko tilien lukituksen auditointi käytössä
auditpol /get /subcategory:"User Account Management"

Tuloksessa pitäisi näkyä Success, Failure. Jos auditointi ei ole käytössä, ota se käyttöön ryhmäkäytännöllä:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Management → Audit User Account Management → Success and Failure

Varmista myös kirjautumisen auditointi

Event ID 4625 -tapahtumat vaativat kirjautumisen auditoinnin. Ilman tätä et näe epäonnistuneita kirjautumisyrityksiä lähdekoneen lokeissa:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Logon/Logoff → Audit Logon → Failure

Ennaltaehkäisy — miten vähentää tilien lukittumista

Jatkuva lukitusten selvittäminen on tehotonta ja turhauttavaa. Parempi lähestymistapa on vähentää lukittumisten tapahtumista alun perin.

Käytännön vinkit IT-tiimeille

• Salasanan vaihtuilmoitukset: Muistuta käyttäjiä salasanan vanhentumisesta 14, 7 ja 3 päivää ennen vanhenemista — yllättävän moni ei huomaa vanhenemisilmoitusta ilman erillistä muistutusta
• Self-service password reset (SSPR): Ota käyttöön Microsoft Entra ID:n itsepalvelusalasanan vaihto — tämä vähentää helpdesk-tikettejä merkittävästi
• Managed Service Accounts: Käytä ryhmähallittuja palvelutilejä (gMSA) palveluissa käyttäjätunnusten sijaan — AD hallitsee salasanaa automaattisesti, eikä kukaan unohda päivittää sitä
• Fine-Grained Password Policies: Eri käyttäjäryhmille eri lukituskäytännöt — esim. palvelutileille löysempi kynnys, ylläpitotileille tiukempi
• Dokumentoi palvelutilit: Pidä yllä luetteloa kaikista AD-tileistä, joita käytetään palveluissa, ajoitetuissa tehtävissä tai sovelluksissa — tämä kuulostaa itsestäänselvyydeltä, mutta käytännössä tämä dokumentaatio puuttuu hämmästyttävän usein

Usein kysytyt kysymykset

Miten löydän nopeasti, mikä kone aiheuttaa AD-tilin lukittumisen?

Tarkista Event ID 4740 PDC Emulator -toimialueen ohjauskoneelta. Tapahtuman Caller Computer Name -kenttä kertoo lähdekoneen. Käytä PowerShell-komentoa Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4740} ja suodata käyttäjänimellä.

Miksi tili lukittuu toistuvasti, vaikka käyttäjä syöttää oikean salasanan?

Lähes aina syynä ovat välimuistissa olevat vanhat tunnistetiedot. Tarkista Windows Credential Manager, selainten tallennetut salasanat, mobiililaitteiden sähköpostiasetukset, palvelut ja ajoitetut tehtävät, jotka käyttävät käyttäjän tiliä. Nämä voivat yrittää todennusta vanhalla salasanalla taustalla ilman että käyttäjä tietää asiasta.

Pitääkö Entra ID:n lukituskäytäntö synkronoida paikallisen AD:n kanssa?

Kyllä, hybriidiympäristössä käytännöt täytyy ehdottomasti koordinoida. Pass-through-todennusta käytettäessä Entra ID:n lukituskynnyksen tulee olla pienempi kuin AD:n (esim. Entra: 10, AD: 20–30) ja Entra ID:n lukitusajan tulee olla pidempi. Password Hash Sync -ympäristössä lukitustila ei synkronoidu automaattisesti.

Mitkä Event ID -koodit liittyvät tilien lukitukseen?

Tärkeimmät tapahtumatunnukset ovat: Event ID 4740 (tili lukittu — kirjataan DC:lle), Event ID 4625 (epäonnistunut kirjautuminen — kirjataan lähdekonelle), Event ID 4767 (tili avattu) ja Event ID 4771 (Kerberos-esitodennuksen epäonnistuminen).

Miten estän palvelutilien lukittumisen salasanan vaihdon jälkeen?

Paras ratkaisu on siirtyä käyttämään ryhmähallittuja palvelutilejä (Group Managed Service Accounts, gMSA), joissa Active Directory hallitsee salasanan vaihtoa automaattisesti. Jos gMSA ei ole mahdollinen, pidä yllä dokumentaatiota kaikista palveluista ja ajoitetuista tehtävistä, jotka käyttävät kyseistä tiliä, ja päivitä ne kaikki aina salasanan vaihdon yhteydessä.