Kasutajate paroolid ja nende aegumine

Mõni aeg tagasi sai kirjutatud sellest, kuidas avastada domeenist kontosid, mida pole ammu kasutatud.  Muuhulgas sai siis ka mainitud, et selliseid kontosid leiab näiteks selle järgi, et nad pole ammu oma parooli muutnud. Parooli muutmine ja selle regulaarne nõudmine on tänapäeval üpris tavaline.  Selle tõttu aga tekivad pidevalt probleemid inimsete (või teenuste) sisselogimisega.  Seda eriti juhul, kui inimene kasutab veebipõhist rakendust, mis ei oska parooli aegumisel pakkuda paroolivahetust. Või siis on probleemid inimestel, kes lähevad natuke pikemaks ajaks kontorist ära ning parool aegub just sel ajavahemikul. Kuidas siis tuvastada, et inimese parool hakkab kohe (varsti) aeguma.  Esimese hooga võiks ju pakkudua, et Powershelli käsk Search-ADAccount on hea mõte.  Ent natuke edasi vaadates tuleb välja, et see oskab otsida juba aegunud parooliga kodanikke, kes enam ei saa sisse.  Meie aga tahaks hoopis teada, kellel varsti hakkab parool aeguma. Ega siin ei jäägi muud üle, kui otsida domeenist kasutajaid ning vaadata, millal nende parool viimasti muudetud sai:

#Requires -Modules ActiveDirectory
Get-ADUser -filter * -Properties PasswordLastSet

Nüüd tuleb vaid juurde vaadata, et milline on paroolipoliitika:

$passwordAge = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge

Ja siis saab arvutada kuupäeva, millal parool aegub ehk siis mitu päeva tänasest veel parool kehtib:

$user = Get-ADUser mati –Properties Mail,PasswordLastSet

$expiresTime = $user.PasswordLastSet.Add($passwordAge) - (Get-Date)

Edasi tuleb tuvastada teavitamisvajadus.  Ütleme, et kasutajat tuleb teavitada, kui parool aegub 5 või vähema päeva pärast:

if ($expiresTime.Days -le 5 ) {
  #teavitame
}

Kas teavitus on ekraani peal tekstiaken või saadetud e-mail, sõltub juba sellest, et kuidas me teavitada soovime. Kui ise ei suuda otsustada, et mitu päeva ette tuleks teavitada, siis võib kasutada ka Windowsi registrisse kirjutatud väärtust:

$notifyDays = Get-ItemProperty -Name PasswordExpiryWarning `
  -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' |
  Select-Object -ExpandProperty PasswordExpiryWarning

if ($expiresTime.Days -le $notifyDays ) {
  # ...
}

Mainitud registri väärtust saab muuta ka Group Policy abil. Ülaltoodu on piisav, kui ettevõttes ei ole kasutusel Fine-Grained Password Policy.  Kui aga on, siis tuleb parooli aegumise tähtaega hoopis kasutaja küljest otsida:

$domainFunctionalLevel = (get-addomain).DomainMode

if ($domainFunctionalLevel -ge 3) {
  ## Windows2008 domain functional level or greater
  $accountFGPP = Get-ADUserResultantPasswordPolicy $user
  if ($accountFGPP) {
    $passwordAge = $accountFGPP.MaxPasswordAge
  }
}

Kui tuvastada ühe kasutaja parooli aegumist näiteks Logon skripti abil, siis tuleks ülatoodud kasutaja leida ühel järgmistest viisidest:

$user = Get-ADUser ([Security.Principal.WindowsIdentity]::GetCurrent().user)

$user = Get-ADUser ("{0}\{1}" -f $env:USERDOMAIN, $env:USERNAME)

Kui tuvastada kõik kasutajad, kelle parool aegub teatud aja pärast, siis peaks tegema midagi sarnast:

$users = Get-ADUser  –Properties PasswordLastSet `
  –Filter {Enabled –eq $true -and PasswordNeverExpires -eq $false -and PasswordExpired -eq $false -and logonCount -ge 1}  |
  Where-Object {! $_.CannotChangePassword}

foreach ($user in $users) {
  # …
}

Mõned aastad tagasi sai kirjutatud Powershelli script, mille eesmärgiks oligi tuvastada kasutajad, kelle parool aegub teatud arvu päevade pärast, ning saata neile e-maili teel teavitus.  Nimetatud skript sai hiljuti laetud ka Techneti skriptide galeriisse.  Nii et kui selle artikli järgi ise omale sobivat skritpti kokku ei oska/taha/suuda panna, siis võib juba valmis skripti alla laadida.

Advertisements

Exchange Server ja e-mail Address Policy

E-mail Address Policy on väga pikka aega olnud viis, kuidas adressaatidele (sealhulgas postkastid) automaatselt e-maili aadresse genereerida.  Ning Exchange Server 2007 tõi siia ühe olulise muudatuse.  Nimelt on alates Exchange 2007-st muutunud poliitika rakendamise loogika.  Enam ei rakendata seda taustal ja mõne aja pärast, vaid muudatused toimuvad kohe.

Kuid tuleb välja, et päris nii see ka ei ole.  Exchange dokumentatsioon väidab, et poliitika rakendatakse kahel juhul:

Esimese juhuga on asi lihtne.  Poliitika rakendub siis, kui seda rakendatakse.  Teise juhuga on asi keerulisem.  Poliitika rakendub kohe, kui adressaati muudetakse Exchange haldusvahenditega.  Ent kui tegemist on kasutajakonto või grupiga, mida sageli muudetakse hoopis Active Directory (AD) haldusvahenditega.  Ja sellisel juhul aadressipoliitika ei rakendu.

Toome lihtsa näite:  ettevõttel on kasutajad/postkastid mitmes linnas laiali ning e-maili aadressid kajastavad linna, kus kasutaja paikneb.  Kui nüüd kasutaja kolib ühest linnast teise, siis aadressi muutumiseks tuleb muuta kasutaja objekti AD-s.  Ja kui seda tehakse näiteks Active Directory Users and Computers konsooliga, siis e-maili aadressid ei muutu.  Kui sama muudatus teha Exchange Management Console’i kaudu, siis muudetakse ära ka e-maili aadress.  Ja seda ka sel juhul, kui Exchange haldusvahendiga muudeti mõnd muud atribuuti, kui seda mis aadressi muudatuse tingib.  Kõik sama kehtib ka skriptitavate liideste kohta.

Ülaltoodud jutus on üks erand.  Nimelt on võimalik luua aadressipoliitika, mis kontrollib kasutaja atribuuti Description.  Nimetatud atribuuti ei suuda Exchange käsk Get-User kuvada ning käsk Set-User muuta.  Sellest tulenevalt ei rakenda selle atribuudi muutmine ka automaatselt e-maili aadressipoliitikat.  Mis veel halvem, ka muude atribuutide muutmine (Set-User abil) ei käivita aadresspoliitika rakendamist.  Ainuke viis selliseid aadressipoliitikaid rakendada on Update-EmailAddressPolicy.

Sama probleem on tegelikult ka Exchange aadressiraamatutega.  Nende puhul tuleb lihtsalt kasutada teist käsku (Update-AddressList).

Ülaltoodud jutust tasub teha järgmised järeldused:

  1. Adressaatide atribuute tuleb reeglina muuta kasutades Exchange haldusvahendeid;
  2. Kui on võimalik situatsioon, et muudatusi sooritatakse muude vahenditega, siis tasuks ajastatud toimingutesse lisada üks skript, mis iga aadresspoliitika (või aadressraamatu) peal käivitaks käsu Update-EmailAddressPolicy (või Update-AddressList);
  3. Aadressipoliitikas tasub vältida atribuudi Description kasutamist.

Eemaldatud funktsionaalsuse lehel on sellest õnneks isegi juttu, et Recipient Update Service on pärast Exchange 2003 eemaldatud ning nimetatud funktsionaalsuse täielikus jätkamiseks on vaja kasutada ajastatud toimingute abi.  Kahjuks aga ei mainita, et mis tingimustel ajastatud toiminguid vaja on.

Siia jutu sisse poetatud lingid viitavad Exchange 2013 dokumentatsioonile, ent sealtsamast saab kiiresti kätte ka Exchange 2010 dokumentatsiooni. Ja kui 2010 lingid on juba käes, siis saab neid ise muuta nii, et nad näitaksid Exchange 2007 dokumentatsioonile (vihje: v=exch.80).