Miten jäljität ja ratkaiset lukitun Active Directory -tilin? Selvitä, mitä tapahtuu, miten löydät tietyt tapahtumat ja miten analysoit tapahtumia.
Active Directory (AD) on hieno palvelu. Voit kirjautua sisään mistä tahansa verkossa käyttäen samaa käyttäjätunnusta ja salasanaa. Se ei voisi olla helpompaa — siis siihen asti, kunnes unohdat sulkea etätyöpöytäistunnon, tai mato leviää verkossa, tai unohdat, että suoritat ajastetun tehtävän käyttäjätililläsi, tai… No, ymmärrät kyllä. AD on erittäin hyödyllinen tuote, ja siksi sen käyttöaste on niin korkea. Ongelma on silloin, kun tili alkaa lukkiutua ilman mitään syytä. Tai niin ainakin luulet.
AD-tilien lukituskäytännöt
Monilla organisaatioilla on (tai pitäisi olla) tilien lukituskäytännöt. Tämä käytäntö on turvatoimenpide, jolla estetään luvattomia osapuolia yrittämästä jatkuvasti arvata salasanaa tai murtautumasta salasanaan brute force -menetelmällä. Tilien lukitsemiskäytännöt ovat yleisiä Active Directoryssa, ja ne koostuvat yksinkertaisesta lähestymistavasta merkittävän tietoturvaongelman torjumiseen. Yritä väärää salasanaa tietty määrä kertoja, ja tili on käyttökelvoton, kunnes järjestelmänvalvoja ottaa sen manuaalisesti uudelleen käyttöön. Tarkoitus on totta, mutta joissakin tapauksissa toteutus ei ole.
Jossain tilanteissa, varsinkin kun salasana vaihdetaan, tili voi yhtäkkiä alkaa lukittua jatkuvasti ilman näkyvää syytä. Käyttäjä soittaa helpdeskiin, helpdesk ottaa tilin uudelleen käyttöön, ja vähän myöhemmin tili on taas lukittu. Se on turhauttava kokemus sekä käyttäjälle että help deskille. Joskus ongelmaa pahentaa lukitusten tuntematon alkuperä. Jossain on henkilö, skripti tai prosessi, joka yrittää jatkuvasti samaa väärää salasanaa uudestaan ja uudestaan, mutta kukaan ei tiedä, missä.
Miten nämä ärsyttävät lukkiutumiset siis jäljitetään? Yksi tapa on käyttää PowerShell-skriptiä. Mutta käydään ensin läpi, mitä tapahtuu, kun tili on lukittu.
Lukitun AD-tilin ratkaiseminen
Windows Server 2008- tai uudemmassa ympäristössä asiakasjärjestelmän, asiakasjärjestelmän toimialueohjaimen ja toimialueohjaimen, jolla on ensisijaisen toimialueohjaimen (Primary Domain Controller, PDC) emulaattorirooli, välillä on lyhyt edestakainen yhteys. Tämä tapahtuu seuraavasti:
- Kun käyttäjätilin todennusta yritetään, tunnistetiedot lähetetään ylöspäin asiakasjärjestelmän aliverkon vastaavalle toimialueohjaimelle.
- Jos salasana on väärä, asiakasjärjestelmän toimialueen valvoja välittää pyynnön sille toimialueen valvojalle, jolla on PDC-emulaattorin rooli. Tämä johtuu siitä, että asiakasjärjestelmän toimialueenvalvojalla ei välttämättä ole viimeisintä salasanaa, ja Active Directoryn suunnittelun ansiosta PDC-emulaattorin roolin omaava toimialueenvalvoja tietää sen aina.
- PDC-emulaattori yrittää salasanaa uudelleen, ja jos se todetaan edelleen vääräksi, PDC-emulaattori kasvattaa käyttäjätilin badPwdCount-attribuuttia.
- PDC-emulaattoriin luodaan tapahtuma ID 4740, jossa on alkuperäisen pyynnön käynnistäneen asiakasjärjestelmän IP-osoite ja käyttäjätili.
- Tämän jälkeen PDC-emulaattori ilmoittaa asiakasjärjestelmän toimialueenvalvojalle, että salasana on itse asiassa väärä.
- Tämän jälkeen asiakasjärjestelmän toimialueenvalvoja ilmoittaa asiakasjärjestelmälle, että salasana oli väärä.
Missä olisi paras paikka löytää lähde? Vastaus on PDC-emulaattorissa. Syy tähän on se, että jokainen tilin lukkiutuminen kirjataan siellä tietoturvatapahtumalokiin. PDC-emulaattori on keskeinen paikka, josta voidaan kysyä kaikkia tililukitustapahtumia.
PowerShellin käyttäminen AD-tilien lukitusten lähteen jäljittämiseen
PDC-emulaattorin kyselyyn käytetään PowerShellin Get-WinEvent-komentoa. Tämä on erittäin hyödyllinen cmdlet yhden tai useamman palvelimen tapahtumalokin nopeaan läpikäyntiin. Etsimme tapahtumatunnusta 4740. Ensin on löydettävä toimialueen ohjain, jolla on PDC-emulaattorirooli. Yksi tapa tehdä tämä on käyttää Get-AdDomain-senttimerkkiä.
Kun tiedämme PDC-emulaattorin, on vain kysyttävä sen tietoturvatapahtumalokista tapahtumatunnusta 4740.
Minulla on tili nimeltä abertram, joka on lukittu ulos. Katsotaanpa, miten syyllinen saadaan jäljitettyä.
Meillä on nyt PDC-emulaattori, joten kysytään sen tietoturvaloki PowerShell-skriptillä.
## Määritellään käyttäjänimi, joka on lukittu ulos
$Username = ’abertram’
## Etsitään toimialueohjaimen PDCe-rooli
$Pdce = (Get-AdDomain).PDCEmulator
## Rakennetaan parametrit, jotka välitetään Get-WinEventille
$GweParams = @{
’Computername’ = $Pdce
’LogName’ = ’Security’
’FilterXPath’ = ”* ja EventData=’$Username’]]”
}
## Kysytään tietoturvatapahtumalokilta
$Events = Get-alkuiset tapahtumat.WinEvent @GweParams
Tämä antaa meille lukitustapahtuman.
Mutta meillä ei ole vielä alkuperäistä asiakasjärjestelmää. Saadaksemme sen, meidän on kaivettava hieman syvemmältä. Varsinainen käyttäjänimi on haudattu kunkin tapahtuman Properties-arvoon. Löytääksemme käyttäjänimen jokaisesta tapahtumasta voimme yksinkertaisesti käyttää tätä riviä.
$Events.Properties.Value
Tämä löytää käyttäjänimen ensimmäisestä tapahtumasta ja Properties-arvon ensimmäisestä esiintymästä. Onneksi asiakasjärjestelmä on juuri Properties-arvon toisessa instanssissa.
$Events.Properties.Value
Kun tiedetään, missä asiakasjärjestelmän nimi sijaitsee, se on vain lisättävä silmukkaan, ja syyllinen on löytynyt.
Nyt olet aseistettu ja valmis toimimaan seuraavan kerran, kun helpdesk soittaa sinulle, koska AD-käyttäjätili lukkiutuu jatkuvasti.