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

Group Policy ja User Account Control (UAC)

Hiljuti juhtus selline probleem: miskipärast ei võetud kasutajale Group Policy logon skriptiga külge võrguketast.  Täpselt sama juhtus ka siis, kui skripti asemel sai proovitud Group Policy Preferences funktsionaalsust.  Lähemal uurimisel selgus, et võrguketas võetakse külge küll, aga Windows Explorer ei tea sellest midagi.  Edasine uurimine viis KB artiklini, mis tõi asjasse valgust.

Nimelt tuleb välja, et võrguketaste külgevõtmine käib kasutaja mandaadi järgi.  Ja alates Windows Vistast on admin-õigustega kasutajatel (sisselülitatud UAC korral) alati kaks mandaati: üks administraatori õigustega ja teine ilma nendeta.  Ehk siis nagu ülalmainitud artikkel väidab, et kui võtta võrguketas külge admin-õigustes, siis tavaõigustes seda võrguketast näha ei ole.  Ja vastupidi.

Probleem aga on hoopis selles, et sama efekt tekib ka siis, kui võrguketas külge võtta Group Policy abiga.  See viitab sellele, et Group Policy rakendamine toimub arvutis enne, kui admin-õigustega kasutajale luuakse ilma admin-õigusteta mandaat ning käivitatakse töölaud.  Kes teab, mis seal veel võib tegemata jääda või vale mandaadi küljes olla…

Et asi veel keerulisem oleks, tuli välja, et kui Group Policy rakendamisel kasutati loopback processing režiimi, siis tulid võrgukettad kasutajale külge.  Seega rakendatakse loopback processing režiimis juba käivitatud töölaua seest (ehk siis mitte-admin õigustes).

Ülalmainitud artikkel väidab, et probleem esineb Windows Vista sees.  Tegelikult ilmneb see ka Server 2008 ja 2008 R2 (seega ka Windows 7) sees.  Ning väidetavasti on sama mure veel ka Windows 8 sees.  Nii et kui võrguketaste külgevõtmisega on probleeme, siis tasub otsida abi ülaltoodud artikli soovitustest.

Core Configurator 2.0

Server 2008 võimaldab paigaldust ilma suurema osa graafilise liidese koodita.  Seda kutsutakse Server Core’iks.  See, et kettaruumi kulub 4 korda vähem, on tore, ent see et kogu häälestus tuleb nüüd ise käsurealt ära teha, nii tore enam ei ole.  Siin tuleb appi Core Configurator.  Server 2008 jaoks tuleb kasutada varasemat versiooni, mis on sisuliselt hulk kasutajaliidesega (tekstirežiimis küsimused-vastused, mitte mingi menüüpõhine asi).

Server 2008 R2 jaoks on Core Configurator’il juba palju ilusam liides.  Hunnik Powershelli skripte näitavad, et nad saavad ilusti graafilise kasutajaliidese jooksutamisega hakkama.  Ja häälestaja elu on selle võrra kergem, et ei pea enam Server Core häälestamisel palju aega raiskama.