Pühendatud PowerShelli kasutamisele AD haldamiseks. Lähtepunktiks otsustas autor võtta 10 tüüpilist AD haldusülesannet ja vaadata, kuidas neid PowerShelli abil lihtsustada:

1. Lähtesta kasutaja parool
2. Kontode aktiveerimine ja deaktiveerimine
3. Avage kasutajakonto
4. Kustutage oma konto
5. Otsige tühjad rühmad
6. Kasutajate lisamine gruppi
7. Loetlege rühma liikmed
8. Otsige aegunud arvutikontosid
9. Deaktiveerige arvutikonto
10. Otsige arvuteid tüübi järgi

Lisaks peab autor blogi (loomulikult PowerShellis), soovitame pilk peale visata - jdhitsolutions.com/blog. Ja kõige värskem, mida saate tema twitterist twitter.com/jeffhicks.
Niisiis, allpool on tõlge artiklist "PowerShelli abil lahendatud 10 parimat Active Directory ülesannet".

Active Directory (AD) haldamine Windows PowerShelliga on lihtsam, kui arvate, ja ma tahan seda teile tõestada. Võite lihtsalt võtta allolevad skriptid ja kasutada neid mitmete AD-haldusülesannete lahendamiseks.

Nõuded

PowerShelli kasutamiseks AD haldamiseks peavad olema täidetud mõned nõuded. Näitan Windows 7 näites, kuidas AD cmdlet-käsud töötavad.
cmdlet-käskude kasutamiseks peab teil olema Windows Server 2008 R2 domeenikontroller või saate alla laadida ja installida Active Directory halduslüüsi teenuse pärand-DC-desse. Enne paigaldamist lugege hoolikalt läbi dokumentatsioon; Taaskäivitamine on nõutav.
Kliendi poolel laadige alla ja installige (RSAT) kas Windows 7 või Windows 8 jaoks. Operatsioonisüsteemis Windows 7 peate avama Juhtpaneelid peatükk Programmid ja vali Lülitage Windowsi funktsioonid sisse või välja. Otsi Serveri kaughaldustööriistad ja laiendage jaotist Rollihaldustööriistad. Valige AD DS-i ja AD LDS-i tööriistade jaoks sobivad üksused, eriti pange tähele, et üksus tuleb valida Active Directory moodul Windows PowerShelli jaoks, nagu on näidatud joonisel 1. (Windows 8-s on kõik tööriistad vaikimisi valitud). Nüüd oleme valmis tööle.

Joonis 1 AD DS ja AD LDS tööriistade lubamine

Olen sisse logitud domeeni administraatoriõigustega kontoga. Enamik cmdlet-käske, mida ma teile näitan, võimaldab teil määrata alternatiivseid mandaate. Igal juhul soovitan abi lugeda ( Hankige abi) ja näited, mida ma allpool demonstreerin.
Käivitage PowerShelli seanss ja importige moodul:

PS C:\> Impordi moodul ActiveDirectory

Importimine loob uue PSDrive'i, kuid me ei kasuta seda. Küll aga näete, millised käsud on imporditud moodulis.

PS C:\> get-command -moodul ActiveDirectory

Nende käskude ilu seisneb selles, et kui ma saan kasutada käsku ühe AD-objekti jaoks, siis seda saab kasutada 10, 100 ja isegi 1000 jaoks. Vaatame, kuidas mõned neist cmdlet-käskudest töötavad.

Ülesanne 1: lähtestage kasutaja parool

Alustame tüüpilise ülesandega: kasutaja parooli lähtestamine. Seda saate teha lihtsalt ja lihtsalt cmdleti kaudu Set-ADAccountPassword. Keeruline osa on see, et uus parool peab olema kvalifitseeritud turvaliseks stringiks: tekstiosaks, mis on krüptitud ja salvestatud mällu PowerShelli seansi ajaks. Kõigepealt loome uue parooliga muutuja:
PS C:\> $new=Read-Host "Sisesta uus parool" -AsSecureString

Seejärel sisestage uus parool:

Nüüd saame konto ekstraktida (kasutades samAccountname on parim valik) ja määrake uus parool. Siin on näide kasutaja Jack Frosti kohta:

PS C:\> Set-ADAccountPassword jfrost -UusParool $uus

Kahjuks on selles cmdletis viga: -läbipääsu, -mis siis kui, Ja – Kinnita ei tööta. Kui eelistate otseteed, proovige järgmist.

PS C:\>Set-ADAccountPassword jfrost -NewPassword(ConvertTo-SecureString -AsPlainText -String" [e-postiga kaitstud]"-jõud)

Pean Jackil järgmisel sisselogimisel oma parooli muutma ja värskendan kontot kasutades Set-ADUser.

PS C:\> Set-ADUser jfrost -ChangePasswordAtLogon $True

cmdleti käivitamise tulemusi konsooli ei kirjutata. Kui seda on vaja teha, kasutage -Tõsi. Kuid ma saan teada, kas toiming õnnestus või mitte, eemaldades cmdleti abil kasutajanime Hankige ADUser ja vara täpsustamine Parool Aegunud nagu on näidatud joonisel 2.

Riis. 2. Get-ADUser cmdleti tulemused atribuudiga PasswordExpired

Alumine rida: kasutaja parooli lähtestamine PowerShelli abil pole üldse keeruline. Tunnistan, et ka parooli lähtestamine on hetkega lihtne. Active Directory kasutajad ja arvutid konsoolid Microsofti halduskonsool (MMC). Kuid PowerShelli kasutamine on hea, kui teil on vaja ülesannet delegeerida, te ei soovi eelnimetatud lisandmoodulit juurutada või parooli lähtestada suure automatiseeritud IT-protsessi osana.

Ülesanne 2: kontode aktiveerimine ja deaktiveerimine

Nüüd deaktiveerime konto. Jätkame koostööd Jack Frostiga. See kood kasutab parameetrit -mis siis kui, mida võite näha teistes cmdlet-käskudes, mis teevad muudatusi minu käsu testimiseks ilma seda käivitamata.

PS C:\> Disable-ADAccount jfrost -whatif Mis siis, kui: toimingu "Set" sooritamine sihtmärgil "CN=Jack Frost, OU=personal,OU=Testing,DC=GLOBOMANTICS,DC=local".

Ja nüüd deaktiveerime päriselt:

PS C:\> Disable-ADAccount jfrost

Ja kui on aeg konto aktiveerida, siis milline cmdlet meid aitab?

PS C:\> Enable-ADAccount jfrost

Neid cmdlet-käske saab kasutada konveieravaldisena, mis võimaldab teil aktiveerida või deaktiveerida nii palju kontosid, kui soovite. Näiteks deaktiveerib see kood kõik müügiosakonna kontod (Müük)

PS C:\> get-aduser -filter "osakond -eq "müük"" | konto keelamine

Muidugi, kirjutades filtri Hankige ADUserüsna keeruline, kuid see on koht, kus parameetri kasutamine -mis siis kui koos cmdletiga Keela-ADA-konto tuleb appi.

Ülesanne 3: avage kasutajakonto

Mõelge olukorrale, kus Jack on uut parooli sisestades oma konto lukustanud. Selle asemel, et proovida oma kontot GUI kaudu leida, saab avamisprotseduuri teha lihtsa käsuga.

PS C:\> Unlock-ADAccount jfrost

cmdlet toetab ka parameetreid -mis siis kui Ja - Kinnita.

Ülesanne 4: konto kustutamine

Pole tähtis, kui palju kasutajaid kustutate – seda on lihtne teha cmdleti abil Eemalda-ADUser. Ma ei taha Jack Frosti eemaldada, kuid kui tahaksin, kasutaksin seda koodi:

PS C:\> Remove-ADUser jfrost -whatif Mis siis, kui: toimingu "Remove" sooritamine sihtmärgil "CN=Jack Frost,OU=personal,OU=Testing,DC=GLOBOMANTICS,DC=local".

Või saan sisestada mitu kasutajat ja eemaldada need ühe lihtsa käsuga:

PS C:\> get-aduser -filter "enabled -eq "false"" -omadus WhenChanged -SearchBase "OU=Töötajad, DC=Globomantika,DC=Kohalik" | kus ($_.WhenChanged -le (Get-Date).AddDays(-180)) | Eemalda-ADuser -Whatif

See käsk otsib ja eemaldab kõik inaktiveeritud töötajate OU-kontod, mis pole muutunud 180 päeva või kauem.

Ülesanne 5: tühjade rühmade leidmine

Grupi juhtimine on lõputu ja tänamatu ülesanne. Tühjade rühmade leidmiseks on palju võimalusi. Mõned väljendid võivad teie organisatsioonist olenevalt toimida paremini kui teised. Allolev kood leiab kõik domeeni rühmad, sealhulgas sisseehitatud rühmad.

PS C:\> get-adgroup -filter * | kus (-Not ($_ | get-adgroupmember)) | vali nimi

Kui teil on sadade liikmetega gruppe, võib selle käsu kasutamine võtta kaua aega; Hangi reklaamirühma liige kontrollib iga rühma. Kui saate piirata või kohandada, on see parem.
Siin on veel üks lähenemine:

PS C:\> get-adgroup -filter "liikmed -notlike "*" -AND GroupScope -eq "Universal"" -SearchBase "OU=Groups,OU=Töötajad,DC=Globomantika, DC=kohalik" | Valige nimi, rühm*

See käsk leiab kõik universaalsed rühmad, millel ei ole OU rühmade liikmesust, ja prindib mõned atribuudid. Tulemus on näidatud joonisel 3.


Riis. 3. Otsige ja filtreerige universaalseid rühmi

Ülesanne 6: kasutajate lisamine rühma

Lisame Jack Frosti Chicago IT-gruppi:

PS C:\> add-adgroupmember "chicago IT" -liikmed jfrost

Jah, see on nii lihtne. Saate hõlpsasti lisada gruppidesse sadu kasutajaid, kuigi see on minu arvates veidi ebamugav:

PS C:\> Add-ADGroupMember "Chicago töötajad" -liige (get-aduser -filter "city -eq "Chicago")

Kasutasin sulgidega konveieriga avaldist, et leida kõik kasutajad, kellel on Chicagos atribuut City. Sulgudes olev kood käivitatakse ja saadud objektid edastatakse parameetrile –Member. Iga kasutajaobjekt lisatakse Chicago töötajate rühma. Pole vahet, kas tegemist on 5 või 5000 kasutajaga, grupiliikmete värskendamiseks kulub vaid mõni sekund. Seda väljendit saab kirjutada ka kasutades Iga objekti jaoks mis võib olla mugavam:

PS C:\> Get-ADUser -filter "city -eq "Chicago"" | foreach (Add-ADGroupLiige "Chicago töötajad" -liige $_)

Ülesanne 7: rühmaliikmete loendi kuvamine

Võib-olla soovite teada, kes konkreetsesse rühma kuuluvad. Näiteks peaksite perioodiliselt kontrollima, kes on domeeni administraatorite rühmas:

PS C:\> Get-ADGroupMember "Domeeni administraatorid"

Joonis 4 näitab tulemust.

Riis. 4. Domeeniadministraatorite rühma liikmed

cmdlet väljastab iga rühmaliikme jaoks AD-objekti. Aga pesastatud rühmad? Minu Chicago kõigi kasutajate rühm on pesastatud rühmade kogu. Kõigi kontode loendi saamiseks pean lihtsalt parameetrit kasutama -Korduv.

PS C:\> Get-ADGroupMember "Chicago kõik kasutajad" -Rekursiivne | Valige DistinguishedName

Kui soovite minna teist teed, et leida, millistesse rühmadesse kasutaja kuulub, kasutage kasutaja atribuuti Liige:

PS C:\> get-aduser jfrost -property Memberof | Valige -ExpandProperty memberOf CN=NewTest,OU=Groups,OU=Töötajad, DC=GLOBOMANTICS,DC=kohalik CN=Chicago test,OU=Grupid,OU=Töötajad, DC=GLOBOMANTICS,DC=kohalik CN=Chicago IT,OU= Grupid,OU=töötajad, DC=GLOBOMANTICS,DC=kohalik CN=Chicago müügikasutajad,OU=grupid,OU=töötajad, DC=GLOBOMANTICS,DC=kohalik

Kasutasin parameetrit -Laienda Property nimede kuvamiseks Liige nagu stringid.

Ülesanne 8: leidke aegunud arvutikontod

Minult küsitakse sageli järgmist küsimust: "Kuidas leida aegunud arvutikontosid?". Ja ma vastan alati: "Mis on teie jaoks vananenud?" Ettevõtted erinevad oma määratluses selle kohta, millal arvutikonto (või kasutajakonto, mis iganes) loetakse aegunuks ja enam kasutatavaks. Mina pööran tähelepanu nendele kontodele, mille paroole pole teatud aja jooksul muudetud. Minu jaoks on see periood 90 päeva - kui arvuti pole selle perioodi jooksul parooli koos domeeniga vahetanud, on see tõenäoliselt võrguühenduseta ja aegunud. Kasutatud cmdlet Hangi-ADComputer:

PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -omadused *| Valige nimi, parooli viimane komplekt

Filter töötab kõva väärtusega suurepäraselt, kuid seda koodi värskendatakse kõigi arvutikontode puhul, mis pole pärast 1. jaanuari 2012 oma paroole muutnud. Tulemused on näidatud joonisel 5.

Riis. 5. Otsige üles aegunud arvutikontod

Teise võimalusena oletame, et olete vähemalt Windows 2003 domeeni funktsionaalsel tasemel. Filtreerige atribuudi järgi LastLogontimeStamp. See väärtus on 100 nanosekundiliste intervallide arv alates 1. jaanuarist 1601 ja see on salvestatud GMT-s, seega on selle väärtusega töötamine pisut keeruline.

PS C:\> get-adcomputer -filter "LastlogonTimestamp -gt 0" -properties * | vali nimi,lastlogontimestamp, @(Name="LastLogon";Expression=(::FromFileTime ($_.Lastlogontimestamp))),passwordlastset | SortLastLogonTimeStamp

Riis. 6. Teisendage LastLogonTimeStamp väärtus tuttavasse vormingusse

Filtri loomiseks pean teisendama kuupäeva (nt 1. jaanuar 2012) õigesse vormingusse. Teisendamine toimub FileTime'is:

PS C:\> $cutoff=(Get-Date "1/1/2012").ToFileTime() PS C:\> $cutoff 129698676000000000

Nüüd saan seda muutujat filtris kasutada Hangi-ADComputer:

PS C:\> Get-ADComputer -Filter "(lastlogontimestamp -lt $cutoff) -või (lastlogontimestamp -notlike "*")" -omadus * | Valige nimi, viimane sisselogimise ajatempel, parool, viimane komplekt

Ülaltoodud kood leiab samad arvutid, mis olid näidatud joonisel 5.

Ülesanne 9: desaktiveerige arvutikonto

Kui leiate passiivseid või aegunud kontosid, võite need desaktiveerida. Selle tegemine on üsna lihtne. Kasutame sama cmdlet-i, mida kasutasime kasutajakontode puhul. Saate seda täpsustada kasutades samAccountname konto.

PS C:\> Disable-ADAccount -Identity "chi-srv01$" -Whatif Mis siis, kui: toimingu "Set" sooritamine sihtmärgil "CN=CHI-SRV01, CN=Computers,DC=GLOBOMANTICS,DC=local".

Või kasutades konveieri avaldist:

PS C:\> get-adcomputer "chi-srv01" | Keela-ADA-konto

Samuti saan kasutada oma koodi aegunud kontode leidmiseks ja kõigi nende desaktiveerimiseks:

PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -omadused *| Keela-ADA-konto

Ülesanne 10: Otsige arvutid tüübi järgi

Samuti küsitakse minult sageli, kuidas leida arvutikontosid tüübi järgi, näiteks serverid või tööjaamad. See nõuab teielt teatud loovust. AD-s pole midagi, mis eristaks serverit kliendist, välja arvatud võib-olla OS. Kui teie arvutis töötab Windows Server 2008, peate tegema mõned lisatoimingud.
Kõigepealt peate hankima OS-i loendi ja seejärel filtreerime kontod saadaoleva OS-i järgi.

PS C:\> Get-ADComputer -Filter * -Operties OperatingSystem | Valige Operatsioonisüsteem -unikaalne | Sorteeri operatsioonisüsteem

Tulemused on näidatud joonisel 7.

Riis. 7. Ekstraktige OS-i loend

Soovin leida kõik arvutid, milles töötab serveri OS:

PS C:\> Get-ADComputer -Filter "OperatingSystem -nagu "*Server*"" -omadused Operatsioonisüsteem,Operatsioonisüsteemi hoolduspakett | Valige Nimi,Op* | formaat-loend

Tulemused on näidatud joonisel 8.

Nagu teistegi AD Get-cmdlet-käskude puhul, saate kohandada otsinguparameetreid ja piirata päringut vajaduse korral konkreetsete OU-dega. Kõiki minu näidatud väljendeid saab integreerida suurtesse PowerShelli avaldistesse. Näiteks saate sortida, rühmitada, rakendada filtreid, eksportida CSV-vormingusse või luua ja meilida HTML-aruandeid – kõike seda PowerShellist! Sel juhul ei pea te kirjutama ühte skripti.
Siin on teile boonus: kasutaja parooli vanuse aruanne, mis on salvestatud HTML-faili:

PS C:\> Get-ADUser -Filter "Lubatud -eq "True" -AND PasswordNeverExpires -eq "False"" -Atribuudid ParoolLastSet,PasswordNeverExpires,PasswordExpired | Valige DistinguishedName,Name,pass*,@(Nimi="ParooliAge"; Väljend=((Hankimiskuupäev)-$_.Parooli viimane komplekt)) |sorteeri ParooliVaus -Kahanev | ConvertTo-Html -Title "Parooli vanuse aruanne" | Out-File c:\Work\pwage.htm !}

Kuigi see väljend võib tunduda pisut hirmutav, on PowerShelli minimaalsete teadmistega seda lihtne kasutada. Ja on ainult viimane näpunäide: kuidas määratleda kohandatud atribuut nimega ParoolAge. Väärtus on lõhe tänase ja atribuudi PasswordLastSet vahel. Seejärel sorteerin oma uue kinnisvara tulemused. Joonis 9 näitab minu väikese testdomeeni väljundit.

Värskendus:
Postitus sisaldab portaalis oleva artikli tõlget

Kui Active Directory on installitud, saate alustada objektide loomist ja haldamist.

6.5.1. Osakondade ja objektide loomine neis

6.5.1.1. Organisatsiooniüksuste loomine (OD)

RO saab luua domeenis, domeenikontrolleri objektis või muus RO-s (joonis 6.3). Loodud OP-le saab objekte lisada.

OU loomiseks peab teil olema õigus lisada osakondi emaüksuse OU, domeeni või domeenikontrolleri sõlme, kus OU luuakse. Vaikimisi antakse see luba administraatorite rühmale.

strataatorid).

Enamikus standardsetes konteinerites ei saa OP-d luua

näiteks arvutid või kasutajad.

Riis. 6.3. OTSI OP osakond domeenikontrolleri sõlmes

OP-d luuakse võrgu haldamise lihtsustamiseks. Euroopa Parlamendi struktuur peaks põhinema konkreetsetel reklaamiülesannetel.

minister. Saate hõlpsasti muuta OP struktuuri või teisaldada objekte OP-de vahel.

OP-d luuakse järgmistel juhtudel:

anda teistele kasutajatele või administraatoritele haldusvolitused;

rühmitada objekte, mille suhtes tehakse sarnaseid haldustoiminguid; see hõlbustab sarnaste võrguressursside otsimist ja nende hooldamist - seega saate ühendada kõik objektid ühte OP-sse Ajutiste töötajate kasutaja;

võrguressursside nähtavuse piiramiseks Active Directory salvestusruumis näevad kasutajad ainult neid objekte, millele neil on juurdepääs; OP õigusi saab hõlpsasti muuta, et piirata juurdepääsu tundlikule teabele.

6.5.1.2. Objektide lisamine OP-sse

Objektide lisamiseks OP-sse peavad teil olema vastavad õigused. Vaikimisi antakse need õigused administraatorite rühmale. Loodetavate objektide tüübid sõltuvad skeemireeglitest, viisardist või kasutatavast lisandmoodulist. Osa objekti atribuute saab määratleda alles pärast selle loomist.

6.5.2. Active Directory objektide haldamine

Active Directory objektihaldus hõlmab objektide leidmist, muutmist, hävitamist või teisaldamist. Kahel viimasel juhul peavad teil olema vastavad õigused objektile või OP-le, kus te objekti teisaldate. Vaikimisi on see õigus kõigil administraatorite rühma liikmetel.

6.5.2.1. Otsige objekte

Globaalne kataloog (GC) sisaldab kogu kataloogi osalist koopiat ja salvestab teabe kõigi domeenipuu või metsa objektide kohta. Seetõttu leiab kasutaja objekti üles sõltumata selle asukohast domeenis või metsas. GK sisu genereeritakse automaatselt vastavalt kataloogi moodustavate domeenide teabele.

Objektide otsimiseks avage lisandmoodul, mille otsetee asub programmigrupis Administrative Tools. Paremklõpsake konsoolipuus

klõpsake domeenil või OU-l ja valige kontekstimenüüst Otsi. Avaneb dialoogiboks Otsi.

(Otsi) (Joon. 6.4).

Riis. 6.4. Otsige üles dialoogiboks

Kui avate objekti kontekstimenüü Jagatud kaust ja valige Otsi

(Leia) nuppu, käivitatakse Windows Exploreri otsingufunktsioon ja saate otsida jagatud kaustast faile ja alamkaustu.

Otsimise dialoogiboks sisaldab GL-i otsingusuvandeid, mis võimaldavad teil leida kontosid, rühmi ja printereid.

6.5.2.2. Atribuutide väärtuste muutmine

Ja objektide kustutamine

Atribuudi väärtuste muutmiseks avage Ac-

tiivsed kataloogi kasutajad ja arvutid ja valige objekti eksemplar

et. Menüüst Toiming valige Atribuudid. Atribuutide dialoogiboksis

objekti, muutke objekti soovitud atribuute. Seejärel muutke objekti kirjeldust, näiteks muutke kasutajaobjekti, et muuta kasutaja nime, asukohta ja e-posti aadressi. Kui objekte pole enam vaja, kustutage need turvakaalutlustel: avage Active Directory kasutajad ja

Arvutid , valige kustutatava objekti eksemplar ja seejärel valige menüüst Toiming käsk Kustuta

(Kustuta).

6.5.2.3. Liikuvad objektid

Active Directory salvestusruumis saate objekte teisaldada, näiteks OP-de vahel, et kajastada muutusi ettevõtte struktuuris, kui töötaja viiakse ühest osakonnast teise.

goy. Selleks avage snap Active Directory kasutajad ja kom-

puters , vali teisaldatav objekt, menüüst Action (Action) vali käsk Move (Move) ja

määrake objekti uus asukoht.

6.5.3. Active Directory objektidele juurdepääsu haldamine

Active Directory objektide juurdepääsu kontroll kasutab objektorienteeritud turbemudelit, mis sarnaneb NTFS-i turbemudeliga.

Igal Active Directory objektil on turbedeskriptor, mis määrab, kellel on juurdepääs objektile ja mis tüüpi juurdepääs see on. Windows Server kasutab objektidele juurdepääsu kontrollimiseks turbedeskriptoreid.

Haldamise lihtsustamiseks saate OU-s rühmitada samade turvanõuetega objekte ning määrata juurdepääsuõigused kogu OU-le ja kõikidele selles sisalduvatele objektidele.

6.5.3.1. Active Directory õiguste haldamine

Active Directory õigused pakuvad ressursside kaitset, võimaldades teil kontrollida juurdepääsu objekti eksemplaridele või objekti atribuutidele ja määrata juurdepääsu tüübi.

Active Directory kaitse

Objekti administraator või omanik peab määrama objektile juurdepääsuõigused, enne kui kasutajad saavad objektile juurde pääseda. Windows Server haldab igaühe jaoks juurdepääsukontrolli loendit (ACL).

th Active Directory objekt.

Objekti ACL sisaldab kasutajate loendit, kellel on objektile juurdepääs, ning objektil lubatud toimingute komplekti.

Saate kasutada õigusi administraatoriõiguste määramiseks konkreetsele kasutajale või rühmale OU, RO hierarhias või üksikus objektis ilma teise haldamiseks administraatoriõigusi määramata.

muud Active Directory objektid.

Objekti juurdepääsuõigused

Sõltub objekti tüübist – näiteks parooli lähtestamise luba kehtib kasutajaobjektide puhul, kuid mitte objektide puhul

arvuti.

Kasutaja võib olla mitme grupi liige, kellel on iga rühma jaoks erinevad õigused, pakkudes objektidele erinevat juurdepääsutaset. Kui määrate objektile loa grupi liikmele, kellel on muud õigused, on kasutaja kehtivad õigused kasutaja lubade ja rühma õiguste summa.

Saate lubasid anda või tühistada. Kasutajate ja rühmade tühistatud load on antud lubade suhtes ülimuslikud.

Kui kasutajal ei ole lubatud objektile juurde pääseda, ei pääse ta sellele ligi isegi autoriteetse rühma liikmena.

Active Directory õiguste määramine

Lisandmoodul võimaldab konfigureerida objektide ja nende atribuutide õigusi. Active Directory kasutajad ja arvutid. Määra ajad -

lahendused on saadaval ka vahekaardil turvalisus objekti omaduste dialoogiboks.

Tavalistest õigustest piisab enamiku haldusülesannete täitmiseks.

2002. aastal oma lemmikülikooli arvutiteaduse osakonna koridoris kõndides nägin NT Systemsi kontori uksel värsket plakatit. Plakatil olid gruppidesse koondatud kasutajakontode ikoonid, millest omakorda läksid nooled teistele ikoonidele. Kõik see ühendati skemaatiliselt teatud struktuuriks, kirjutati midagi ühtse sisenemissüsteemi, autoriseerimise jms kohta. Niipalju kui ma nüüd aru saan, kujutas see plakat Windows NT 4.0 domeenide ja Windows 2000 Active Directory süsteemide arhitektuuri. Sellest hetkest algas ja kohe lõppes minu esimene tutvus Active Directoryga, sest siis oli raske seanss, lõbus puhkus, pärast mida sõber jagas FreeBSD 4 ja Red Hat Linuxi kettaid ning järgmisteks aastateks sukeldusin Unixi-laadsete süsteemide maailm , kuid ma ei unustanud kunagi plakati sisu.
Pidin tagasi minema ja Windows Serveri süsteemidega rohkem tuttavaks saama, kui siirdusin tööle ettevõttesse, kus kogu IT-taristu haldamine põhines Active Directoryl. Mäletan, et selle ettevõtte peaadministraator rääkis igal koosolekul midagi Active Directory parimate tavade kohta. Nüüd, pärast 8-aastast perioodilist suhtlemist Active Directoryga, saan ma üsna hästi aru, kuidas see süsteem töötab ja millised on Active Directory parimad tavad.
Nagu te ilmselt juba arvasite, räägime Active Directoryst.
Kõik, keda see teema huvitab, tere tulemast kassi.

Need soovitused kehtivad Windows 7-st ja uuemast versioonist algavatele klientsüsteemidele ning Windows Server 2008/R2 ja kõrgema taseme domeenidele ja metsadele.

Standardimine
Active Directory planeerimine peaks algama oma standardite väljatöötamisega objektide nimetamiseks ja nende asukohaks kataloogis. On vaja koostada dokument, milles määratleda kõik vajalikud standardid. Loomulikult on see IT-spetsialistide jaoks üsna tavaline soovitus. Põhimõte “kõigepealt kirjutame dokumentatsiooni ja siis ehitame selle dokumentatsiooni põhjal süsteemi” on väga hea, kuid praktikas rakendatakse seda mitmel põhjusel harva. Nende põhjuste hulgas - lihtne inimlik laiskus või vastava pädevuse puudumine, ülejäänud põhjused tulenevad kahest esimesest.
Soovitan - kõigepealt kirjuta dokumentatsioon, mõtle läbi ja alles siis jätka esimese domeenikontrolleri paigaldusega.
Näiteks annan dokumendist osa Active Directory objektide nimetamise standardite kohta.
Objektide nimetamine.

• Kasutajarühmade nimed peavad algama eesliitega GRUS_ (GR - Group, US - Users)
• Arvutirühmade nimed ei tohi alata eesliitega GRCP_ (GR - rühm, CP - arvutid)
• Delegatsioonirühmade nimed peavad algama eesliitega GRDL_ (GR - rühm, DL - delegatsioon)
• Ressursi juurdepääsurühmade nimi peab algama eesliitega GRRS_ (GR - rühm, RS - ressursid)
• Poliitikarühmade nimed peavad algama eesliidetega GPUS_, GPCP_ (GP - rühmapoliitika, USA - kasutajad, CP - arvutid)
• Klientarvutite nimi peaks koosnema kahest või kolmest organisatsiooni nimest pärinevast tähest, millele järgneb sidekriipsu kaudu number, näiteks nnt-01.
• Serverite nimed peavad algama ainult kahe tähega, millele järgneb sidekriips, millele järgneb serveri roll ja serveri number, näiteks nn-dc01.

Soovitan nimetada Active Directory objektid nii, et ei peaks täitma välja "Kirjeldus". Näiteks grupi GPCP_Restricted_Groups nimest selgub, et see on poliitika rühm, mida rakendatakse arvutitele ja mis täidab Piiratud rühmade mehhanismi tööd.
Teie lähenemine dokumentatsiooni kirjutamisele peaks olema väga põhjalik, see säästab hiljem palju aega.

Lihtsustage kõike võimalikku, püüdke saavutada tasakaal
Active Directory loomisel peate järgima tasakaalu saavutamise põhimõtet, valides lihtsad ja arusaadavad mehhanismid.
Tasakaalu põhimõte on saavutada vajalik funktsionaalsus ja turvalisus lahenduse maksimaalse lihtsusega.
Tuleb püüda süsteem üles ehitada nii, et selle struktuur oleks arusaadav ka kogenematumale administraatorile või isegi kasutajale. Näiteks omal ajal soovitati metsastruktuur luua mitmest domeenist. Lisaks soovitati kasutada mitte ainult mitme domeeniga struktuure, vaid ka mitme metsa struktuure. Võib-olla oli selline soovitus "jaga ja valluta" põhimõtte tõttu või Microsoft ütles kõigile, et domeen on turvapiir ja organisatsiooni domeenideks jagades saame eraldi struktuurid, mida on lihtsam individuaalselt juhtida. Kuid nagu praktika on näidanud, on lihtsam hooldada ja juhtida ühe domeeniga süsteeme, kus turvapiirideks on organisatsiooniüksused (OU), mitte domeenid. Seetõttu vältige keerukate mitme domeeni struktuuride loomist, parem on objekte rühmitada OU järgi.
Loomulikult tuleks tegutseda ilma fanatismita – kui ilma mitme domeenita ei saa, siis tuleb luua mitu domeeni, ka metsadega. Peaasi, et sa mõistaksid, mida teed ja milleni see võib viia.
Oluline on mõista, et lihtsat Active Directory infrastruktuuri on lihtsam hallata ja juhtida. Ma isegi ütleks, et mida lihtsam, seda turvalisem.
Rakendage lihtsustamise põhimõtet. Püüdke saavutada tasakaal.

Järgige põhimõtet - "objekt - rühm"
Alustage Active Directory objektide loomist, luues selle objekti jaoks rühma ja määrake rühmale juba vajalikud õigused. Vaatame näidet. Peate looma peaadministraatori konto. Esmalt looge grupp Head Admins ja alles seejärel looge konto ise ja lisage see sellesse gruppi. Määrake peaadministraatorite rühmale peaadministraatori õigused, lisades selle näiteks domeeni administraatorite gruppi. Peaaegu alati selgub, et mõne aja pärast tuleb tööle mõni teine ​​töötaja, kes vajab sarnaseid õigusi ja selle asemel, et delegeerida õigusi Active Directory erinevatesse sektsioonidesse, on võimalik ta lihtsalt lisada vajalikku gruppi, mille jaoks süsteem juba on rolli ja delegeeris vajalikud volitused.
Üks näide veel. Peate delegeerima õigused OU-le, mille kasutajad kuuluvad süsteemiadministraatorite rühma. Ärge delegeerige õigusi otse administraatorite rühmale, vaid looge spetsiaalne rühm, nagu GRDL_OUName_Operator_Accounts, millele määrate õigused. Seejärel lisage lihtsalt vastutavate administraatorite rühm gruppi GRDL_OUName_Operator_Accounts. Kindlasti selgub, et lähitulevikus peate selle OU õigused delegeerima teisele administraatorite rühmale. Ja sel juhul lisate lihtsalt administraatori andmerühma delegeerimisrühma GRDL_OUName_Operator_Accounts.
Pakun välja järgmise rühmastruktuuri.

• Kasutajarühmad (GRUS_)
• Administraatorirühmad (GRAD_)
• Delegatsioonirühmad (GRDL_)
• Eeskirjade rühmad (GRGP_)

Arvutirühmad

• Serverirühmad (GRSR_)
• Kliendi arvutirühmad (GRCP_)

Ressursi juurdepääsurühmad

• Jagatud ressursside juurdepääsurühmad (GRRS_)
• Printeri juurdepääsurühmad (GRPR_)

Nende juhiste ümber ehitatud süsteemis lisavad peaaegu kõik administratsioonid rühmadesse rühmi.
Säilitage tasakaal, piirake rühmade rollide arvu ja pidage meeles, et grupi nimi peaks ideaalis kirjeldama selle rolli täielikult.

OU arhitektuur.
OU arhitektuur tuleks eelkõige läbi mõelda turvalisuse ja selle OU õiguste delegeerimise seisukohalt süsteemiadministraatoritele. Ma ei soovita OU arhitektuuri planeerida grupipoliitika nendega sidumise mõttes (kuigi seda enamasti tehakse). Mõne jaoks tundub minu soovitus veidi kummaline, kuid ma ei soovita üldse siduda rühmapoliitikat OU-ga. Loe lähemalt jaotisest Grupipoliitikad.
OU administraatorid
Soovitan administraatorikontodele ja gruppidele eraldada eraldi OU, kuhu paigutada kõikide administraatorite ja tehnilise toe inseneride kontod ja rühmad. Juurdepääs sellele OU-le peaks olema piiratud tavakasutajatele ja selle OU objektide haldamine tuleks delegeerida ainult peamistele administraatoritele.
OU Arvutid
Arvuti OU-sid on kõige parem planeerida arvutigeograafia ja arvutitüüpide osas. Jaotage erinevatest geograafilistest asukohtadest pärit arvutid erinevatesse OU-desse ja jagage need omakorda klientarvutiteks ja serveriteks. Serverid saab veel jagada Exchange'iks, SQL-iks ja teisteks.

Kasutajad, õigused Active Directory's
Erilist tähelepanu tuleks pöörata Active Directory kasutajakontodele. Nagu OU-de osas mainitud, tuleks kasutajakontod rühmitada nendele kontodele volituste delegeerimise põhimõtte alusel. Samuti on oluline järgida vähimate privileegide põhimõtet – mida vähem õigusi kasutajal süsteemis on, seda parem. Soovitan koheselt panna kasutaja privileegitase tema konto nimele. Igapäevatöö konto peaks koosnema kasutaja perekonnanimest ja ladinakeelsetest initsiaalidest (näiteks IvanovIV või IVIvanov). Kohustuslikud väljad on: eesnimi, initsiaalid, perekonnanimi, kuvatav nimi (vene keeles), e-post, mobiil, ametinimetus, juhataja.
Administraatorikontod peavad olema järgmist tüüpi:

• Administraatoriõigustega kasutajaarvutitele, kuid mitte serveritele. Peab koosnema omaniku initsiaalidest, millele järgneb eesliide local (nt iivlocal)
• Serverite ja Active Directory administreerimise õigustega. Peab koosnema ainult initsiaalidest (näiteks iiv).

Mõlemat tüüpi halduskontode väli Perekonnanimi peaks algama tähega I (näiteks iPetrov P Vasily)
Lubage mul selgitada, miks peaksite administraatorikontod eraldama serveriadministraatoriteks ja klientarvutite administraatoriteks. See on turvakaalutlustel vajalik. Klientarvutite administraatoritel on õigus klientarvutitesse tarkvara installida. Mida ja miks tarkvara installitakse, ei saa kunagi kindlalt öelda. Seetõttu ei ole programmi installimine domeeni administraatori õigustega turvaline, võite kahjustada kogu domeeni. Klientarvuteid peate administreerima ainult selle arvuti kohaliku administraatori õigustega. See muudab võimatuks mitmed domeeniadministraatorite kontode rünnakud, näiteks "Pass The Hash". Lisaks peavad klientarvutite administraatorid sulgema terminaliteenuste ühenduse ja võrguühenduse arvutiga. Tehnilise toe ja administraatorite arvutid tuleks paigutada eraldi VLAN-i, et piirata neile juurdepääsu klientarvutite võrgust.
Kasutajatele administraatoriõiguste andmine
Kui teil on vaja kasutajale administraatoriõigusi anda, ärge mingil juhul lisage tema igapäevast kontot arvuti kohalike administraatorite rühma. Igapäevase töö konto õigused peaksid alati olema piiratud. Looge selle jaoks eraldi nimelist tüüpi administraatorikonto ja lisage see konto poliitika abil kohalike administraatorite rühma, piirates selle kasutamist ainult kasutaja arvutis, kasutades üksuse tasemel sihtimist. Kasutaja saab seda kontot kasutada mehhanismi Run AS abil.
Paroolipoliitikad
Looge kasutajatele ja administraatoritele eraldi paroolipoliitikad, kasutades peeneteralist paroolipoliitikat. Soovitav on, et kasutaja parool oleks vähemalt 8 tähemärgi pikkune ja seda muudetaks vähemalt kord kvartalis. Administraatoritel on soovitav parooli vahetada iga kahe kuu tagant ning see peaks olema vähemalt 10-15 tähemärki pikk ja vastama keerukuse nõuetele.

Domeeni ja kohalike rühmade koosseis. Piiratud rühmade mehhanism
Domeeni ja kohalike rühmade koostist domeeniarvutites tuleks juhtida ainult automaatrežiimis, kasutades piiratud rühmade mehhanismi. Miks on vaja seda teha ainult sel viisil, selgitan järgmise näitega. Tavaliselt lisavad administraatorid pärast Active Directory domeeni purunemist end domeenigruppidesse nagu domeeniadministraatorid, ettevõtteadministraatorid, lisavad vajalikesse rühmadesse tehnilise toe insenerid ja jaotavad ka teised kasutajad rühmadesse. Selle domeeni haldamise käigus korratakse õiguste väljastamise protsessi mitu korda ja on äärmiselt raske meeles pidada, et eile lisasite ajutiselt 1C administraatorite gruppi raamatupidaja Nina Petrovna ja täna peate ta sellest grupist eemaldama. Olukorda halvendab see, kui ettevõttel on mitu administraatorit ja igaüks annab aeg-ajalt kasutajatele sarnases stiilis õigusi. Aasta pärast on peaaegu võimatu aru saada, millised õigused kellele on määratud. Seetõttu tuleks rühmade koosseisu kontrollida ainult grupipoliitikatega, mis seavad iga rakendusega kõik korda.
Sisseehitatud rühmade koosseis
Tasub öelda, et sisseehitatud rühmad nagu kontohaldurid, varuoperaatorid, krüptioperaatorid, külalised, prindioperaatorid, serverioperaatorid peavad olema tühjad nii domeenis kui ka klientarvutites. Neid gruppe on eelkõige vaja tagasiühildumiseks vanemate süsteemidega ning nende rühmade kasutajatele antakse süsteemis liiga palju õigusi ning võimalikuks saavad privileegide eskalatsioonirünnakud.

Kohaliku administraatori kontod
Piiratud rühmade mehhanismi kasutades peate lukustama kohalikes arvutites kohaliku administraatori kontod, lukustama külaliste kontod ja tühjendama kohalikes arvutites kohalike administraatorite rühma. Ärge kunagi kasutage kohaliku administraatori kontode paroolide määramiseks rühmareegleid. See mehhanism ei ole turvaline, parooli saab otse poliitikast hankida. Kui aga otsustate kohalikke administraatorikontosid mitte blokeerida, kasutage paroolide õigeks määramiseks ja nende pööramiseks LAPS-i mehhanismi. Kahjuks pole LAPS-i konfiguratsioon täielikult automatiseeritud ja seetõttu tuleb Active Directory skeemi atribuute käsitsi lisada, neile õigusi anda, rühmi määrata jne. Seetõttu on kohalike administraatorite kontode blokeerimine lihtsam.
Teenusekontod.
Teenuste käivitamiseks kasutage teenusekontosid ja gMSA mehhanismi (saadaval Windows 2012 ja uuemates süsteemides)

Grupipoliitikad
Enne loomist/muutmist dokumenteerige eeskirjad.
Poliitika loomisel kasutage põhimõtet "Poliitika – grupp". See tähendab, et enne poliitika loomist looge selle reegli jaoks esmalt rühm, eemaldage poliitika ulatust rühm Authenticed users ja lisage loodud rühm. Siduge poliitika mitte OU-ga, vaid domeeni juurega ja reguleerige selle rakenduse ulatust, lisades poliitikarühma objekte. Pean sellist mehhanismi paindlikumaks ja arusaadavamaks kui poliitika sidumist OU-ga. (Sellest ma kirjutasin OU Arhitektuuri rubriigis).
Reguleerige alati poliitika ulatust. Kui olete loonud reegli ainult kasutajatele, siis keelake arvuti struktuur ja vastupidi, keelake kasutajastruktuur, kui olete loonud reegli ainult arvutitele. Tänu nendele seadetele rakendatakse eeskirju kiiremini.
Seadistage Power Shelli abil poliitikate igapäevased varukoopiad, et konfiguratsioonitõrgete korral saaksite seaded alati algsetele taastada.
Keskpoe mallid (keskpood)
Alates operatsioonisüsteemist Windows 2008 sai võimalikuks salvestada rühmapoliitika ADMX malle keskses poes, SYSVOLis. Enne seda salvestati kõik poliitikamallid vaikimisi lokaalselt klientidele. ADMX-mallide paigutamiseks kesksalve kopeerige kausta %SystemDrive%\Windows\PolicyDefinitions sisu koos alamkaustadega kliendisüsteemidest (Windows 7/8/8.1) domeenikontrolleri kausta %SystemDrive%\Windows\SYSVOL\domeen Kataloog \Policies\PolicyDefinitions, mille sisu on liidetud, kuid mitte asendatud. Järgmiseks tuleks teha sama koopia serverisüsteemidest, alustades vanimast. Lõpuks tehke kaustade ja failide kopeerimisel serveri uusimast versioonist koopia Ühenda ja ASENDA.

ADMX mallide kopeerimine

Lisaks saab keskmällu paigutada ADMX-malle mis tahes tarkvaratoodete jaoks, nagu Microsoft Office, Adobe'i tooted, Google'i tooted ja teised. Minge tarkvaratootja veebisaidile, laadige alla rühmapoliitika ADMX-mall ja ekstraktige see mis tahes domeenikontrolleri kausta %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions. Nüüd saate hallata vajalikku tarkvaratoodet rühmapoliitika kaudu.
WMI filtrid
WMI-filtrid ei ole väga kiired, seega on eelistatav üksuse tasemel sihtimine. Aga kui üksuse tasemel sihtimist ei saa kasutada ja otsustate kasutada WMI-d, siis soovitan teil kohe luua enda jaoks mitu levinumat filtrit: filter "Ainult kliendi operatsioonisüsteemid", "Ainult serveri operatsioonisüsteemid", filtrid "Windows 7", filtrid "Windows 8", "Windows 8.1", "Windows 10". Kui teil on valmis WMI-filtrite komplektid, on hiljem lihtsam soovitud filtrit soovitud poliitikale rakendada.

Active Directory sündmuste auditeerimine
Lubage kindlasti domeenikontrollerites ja muudes serverites sündmuste auditeerimine. Soovitan lubada järgmiste objektide auditi:

• Arvutikonto haldamise audit – edu, ebaõnnestumine
• Muude kontohalduse sündmuste auditeerimine – edu, ebaõnnestumine
• Audit turvagrupi juhtimine – edu, ebaõnnestumine
• Kasutajakonto haldamise audit – edu, ebaõnnestumine

• Audit Kerberose autentimisteenust – tõrge
• Muude konto sisselogimise sündmuste auditeerimine – ebaõnnestumine
• Auditi auditipoliitika muudatus – edu, ebaõnnestumine

Audit tuleb konfigureerida jaotises Täpsem auditipoliitika konfiguratsioon ja lisage seade kindlasti jaotisesse Kohalikud poliitika/turvasuvandid – sundige auditipoliitika alamkategooria sätteid (Windows Vista või uuem), et alistada auditipoliitika kategooria sätted, mis alistab ülataseme sätted ja rakendab täpsemad sätted.

Täpsemad auditi seaded

Ma ei peatu üksikasjalikult auditi seadetel, kuna veebis on sellele teemale pühendatud piisavalt artikleid. Lisan vaid, et lisaks auditeerimise lubamisele tuleks konfigureerida e-posti märguandeid kriitiliste turvasündmuste kohta. Samuti tasub arvestada, et süsteemides, kus on ohtralt sündmusi, tasub logifailide kogumiseks ja analüüsimiseks pühendada eraldi serverid.

Haldus- ja puhastusskriptid
Kõik sama tüüpi ja sageli korduvad toimingud tuleb teha haldusskripte kasutades. Nende toimingute hulgas on kasutajakontode loomine, administraatorikontode loomine, rühmade loomine, OU-de loomine jne. Skriptimisobjektid võimaldavad teil austada oma Active Directory objektide nimetamise loogikat, luues süntaksikontrollid otse oma skriptidesse.
Samuti tasub kirjutada puhastusskripte, mis kontrollivad automaatselt gruppide koosseisu, tuvastavad kasutajad ja arvutid, kes pole domeeniga pikka aega ühendust võtnud, tuvastavad teie muude standardite rikkumisi jne.
Ma ei ole näinud selgesõnalise ametliku soovitusena haldusskriptide kasutamist standardite järgimise jälgimiseks ja taustatoimingute tegemiseks. Aga ma ise eelistan kontrolle ja protseduure automaatrežiimis skriptide abil, kuna see säästab palju aega ja välistab palju vigu ning loomulikult mõjutab siin minu veidi unixi lähenemine administreerimisele, kui paar käsku on lihtsam sisestada kui klõpsata akendel.

Manuaalne haldus
Osa haldustoimingutest peate teie ja teie kolleegid tegema käsitsi. Nendel eesmärkidel soovitan kasutada mmc-konsooli, millele on lisatud lisandmoodulid.
Nagu hiljem arutatakse, peavad teie domeenikontrollerid töötama Server Core režiimis, see tähendab, et kogu AD keskkonna administreerimine peaks toimuma ainult teie arvutist konsoolide abil. Active Directory haldamiseks peate oma arvutisse installima serveri kaughaldustööriistad. Konsoole tuleks teie arvutis käivitada Active Directory administraatoriõigustega kasutajana, kellele juhtimine on delegeeritud.
Active Directory haldamise kunst konsoolide abil nõuab eraldi artiklit ja võib-olla isegi eraldi koolitusvideot, nii et siin räägin ainult põhimõttest endast.

Domeenikontrollerid
Igas domeenis peab olema vähemalt kaks kontrollerit. Domeenikontrolleritel peaks olema võimalikult vähe teenuseid. Te ei tohiks domeenikontrollerist failiserverit teha ega, jumal hoidku, tõsta selles terminaliserveri rolli. Käivitage domeenikontrolleritel Server Core operatsioonisüsteeme, eemaldades täielikult WoW64 toe. See vähendab oluliselt vajalike värskenduste arvu ja suurendab nende turvalisust.
Microsoft ei soovitanud varem domeenikontrollerite virtualiseerimist seetõttu, et hetktõmmistest taastamisel olid võimalikud raskesti lahendatavad replikatsioonikonfliktid. Põhjuseid võis olla ka muid, ei oska kindlalt öelda. Nüüd on hüperviisorid õppinud kontrolleritele käskima need hetktõmmistest taastada ja see probleem on kadunud. Virtualiseerisin kontrollereid kogu aeg, ilma hetktõmmiseid tegemata, sest ma ei saa aru, miks võib seda domeenikontrolleritel üldse vaja teha. Minu arvates on tavaliste tööriistade abil lihtsam domeenikontrollerit varundada. Seetõttu soovitan virtualiseerida kõik võimalikud domeenikontrollerid. See konfiguratsioon on paindlikum. Domeenikontrollerite virtualiseerimisel asetage need erinevatele füüsilistele hostidele.
Kui teil on vaja paigutada domeenikontroller turvamata füüsilisse keskkonda või oma organisatsiooni harusse, kasutage selleks RODC-d.

FSMO rollid, esmased ja sekundaarsed kontrollerid
Domeenikontrolleri FSMO rollid tekitavad algajate administraatorite meelest jätkuvalt hirmu. Sageli õpivad algajad Active Directoryt vananenud dokumentatsiooni abil või kuulavad lugusid teistelt administraatoritelt, kes on kuskilt midagi lugenud.
Kõigi viie + 1 rolli kohta tuleks lühidalt öelda järgmist. Alates operatsioonisüsteemist Windows Server 2008 pole enam esmaseid ja sekundaarseid domeenikontrollereid. Kõik viis domeenikontrolleri rolli on kaasaskantavad, kuid neid ei saa korraga majutada rohkem kui ühes domeenikontrolleris. Kui võtame ühe kontrolleritest, mis oli näiteks 4 rolli omanik, ja kustutame selle, siis saame kõik need rollid lihtsalt teistele kontrolleritele üle kanda ja domeenis ei juhtu midagi kohutavat, midagi ei lähe katki. See on võimalik, kuna kogu teabe konkreetse rolliga seotud töö kohta salvestab selle omanik otse Active Directorysse. Ja kui me anname rolli üle teisele kontrollerile, küsib see kõigepealt Active Directorysse salvestatud teavet ja hakkab teenima. Domeen võib eksisteerida üsna pikka aega ilma rolliomaniketa. Ainus "roll", mis peaks alati Active Directorys olema ja ilma milleta oleks kõik väga halb, on globaalse kataloogi (GC) roll, seda saavad kanda kõik domeeni kontrollerid. Soovitan määrata GC roll igale domeeni kontrollerile, mida rohkem, seda parem. Muidugi võite leida juhtumeid, kus te ei tohiks domeenikontrollerisse GC rolli installida. No kui ei pea, siis ei pea. Järgige soovitusi ilma fanatismita.

DNS-teenus
DNS-teenus on Active Directory toimimise jaoks ülioluline ja peaks töötama tõrgeteta. DNS-teenus on kõige parem paigutada igasse domeenikontrollerisse ja salvestada DNS-tsoonid Active Directorysse endasse. Kui kasutate DNS-tsoonide salvestamiseks Active Directoryt, peaksite domeenikontrollerites konfigureerima TCP / IP-ühenduse atribuudid nii, et igal kontrolleril oleks esmase DNS-serverina mis tahes muu DNS-server ja saate määrata sekundaarse DNS-serveri. aadress 127.0.0.1. See konfiguratsioon on vajalik, kuna Active Directory teenuse tavapäraseks käivitamiseks on vaja töötavat DNS-i ja DNS-i käivitamiseks peab Active Directory teenus töötama, kuna see sisaldab DNS-tsooni ennast.
Seadistage kindlasti kõigi võrkude jaoks pöördotsingu tsoonid ja lubage PTR-kirjete automaatne turvaline värskendamine.
Soovitan lisaks lubada tsooni automaatne puhastamine vananenud DNS-kirjetest (dns scavenging).
Soovitan määrata turvalised Yandexi serverid DNS-i edasisaatjatena, kui teie geograafilises asukohas pole muid kiiremaid servereid.

Saidid ja replikatsioon
Paljud administraatorid kipuvad mõtlema saitidele kui arvutite geograafilisele rühmale. Näiteks Moskva sait, Peterburi sait. See vaade ilmnes seetõttu, et Active Directory algne jagamine saitideks tehti replikatsioonivõrgu liikluse tasakaalustamiseks ja eraldamiseks. Moskva domeenikontrollerid ei pea teadma, et nüüdseks on Peterburis loodud kümme arvutikontot. Ja seetõttu saab sellist teavet muudatuste kohta graafiku alusel edastada kord tunnis. Või isegi korrake muudatusi üks kord päevas ja ainult öösel, et ribalaiust säästa.
Saitide kohta ütleksin nii: saidid on arvutite loogilised rühmad. Arvutid, mis on omavahel ühendatud hea võrguühendusega. Ja saidid ise on omavahel ühendatud väikese ribalaiusega ühendusega, mis on meie ajal haruldus. Seetõttu jagan Active Directory saitideks mitte replikatsiooniliikluse tasakaalustamiseks, vaid üldiselt võrgu koormuse tasakaalustamiseks ja saidiarvutite kliendipäringute kiiremaks töötlemiseks. Lubage mul selgitada näitega. Seal on organisatsiooni 100-megabitine kohtvõrk, mida teenindavad kaks domeenikontrollerit, ja on pilv, kus asuvad selle organisatsiooni rakendusserverid koos kahe teise pilvekontrolleriga. Jagan sellise võrgu kaheks saidiks, nii et kohtvõrgu kontrollerid töötlevad kliendi päringuid kohalikust võrgust ja pilves olevad kontrollerid töötlevad rakendusserveritelt päringuid. Lisaks eraldab see päringud DFS-i ja Exchange'i teenustele. Ja kuna praegu näen harva alla 10 megabiti sekundis Interneti-kanalit, luban teavituspõhise replikatsiooni, see on siis, kui andmed kopeeritakse kohe, kui Active Directory'is on muudatusi.

Järeldus
Täna hommikul mõtlesin selle üle, miks inimese isekus pole ühiskonnas teretulnud ja kuskil sügaval tajutasandil tekitab äärmiselt negatiivseid emotsioone. Ja ainus vastus, mis mulle pähe tuli, on see, et inimkond poleks sellel planeedil püsima jäänud, kui ta poleks õppinud füüsilisi ja intellektuaalseid ressursse jagama. Seetõttu jagan seda artiklit teiega ja loodan, et minu soovitused aitavad teil oma süsteeme täiustada ja kulutate veaotsingule palju vähem aega. Kõik see toob kaasa rohkem aega ja energiat loovuse jaoks. Loovate ja vabade inimeste maailmas on palju meeldivam elada.
Hea, kui jagad võimalusel kommentaarides oma teadmisi ja praktikaid Active Directory loomisest.
Rahu ja headust kõigile!

Saate saidi arendamiseks aidata ja raha üle kanda

Iga algaja kasutaja, kes seisab silmitsi lühendiga AD, mõtleb, mis on Active Directory? Active Directory on kataloogiteenus, mille Microsoft on välja töötanud Windowsi domeenivõrkude jaoks. Sisaldub enamikus Windows Serveri operatsioonisüsteemides protsesside ja teenuste komplektina. Esialgu tegeles teenus ainult domeenidega. Kuid alates Windows Server 2008-st on AD-st saanud paljude kataloogipõhiste identiteediteenuste nimi. See muudab Active Directory algajatele õppimiseks optimaalsemaks.

Põhidefinitsioon

Serverit, mis käitab Active Directory domeeniteenuseid, nimetatakse domeenikontrolleriks. See autentib ja volitab kõiki Windowsi võrgudomeeni kasutajaid ja arvuteid, määrates ja rakendades turvapoliitikat kõikidele arvutitele ning installides või värskendades tarkvara. Näiteks kui kasutaja logib sisse Windowsi domeeniga ühendatud arvutisse, kontrollib Active Directory antud parooli ja määrab, kas objekt on süsteemiadministraator või tavakasutaja. Samuti võimaldab see hallata ja salvestada teavet, pakub autentimis- ja autoriseerimismehhanisme ning pakub raamistikku muude seotud teenuste juurutamiseks: sertifikaaditeenused, liit- ja kergekaalulised kataloogiteenused ning õiguste haldus.

Active Directory kasutab LDAP versioone 2 ja 3, Microsofti Kerberose versiooni ja DNS-i.

Active Directory – mis see on? Lihtsate sõnadega keerulisest

Võrguandmete jälgimine on aeganõudev ülesanne. Isegi väiksemates võrkudes on kasutajatel tavaliselt raskusi võrgufailide ja printerite leidmisega. Ilma mingi kataloogita ei saa keskmisi ja suuri võrke hallata ning sageli on neil raskusi ressursside leidmisega.

Microsoft Windowsi varasemad versioonid sisaldasid teenuseid, mis aitasid kasutajatel ja administraatoritel teavet leida. Network Neighborhood on kasulik paljudes keskkondades, kuid ilmselgeks puuduseks on ebamugav liides ja selle ettearvamatus. WINS-haldurit ja serverihaldurit saab kasutada süsteemide loendi vaatamiseks, kuid need polnud lõppkasutajatele saadaval. Administraatorid kasutasid kasutajahaldurit täiesti erinevat tüüpi võrguobjekti andmete lisamiseks ja eemaldamiseks. Need rakendused osutusid suurte võrkude jaoks ebaefektiivseks ja tekitasid küsimuse, miks just ettevõttes Active Directory?

Kataloog kõige üldisemas tähenduses on täielik objektide loend. Telefoniraamat on teatud tüüpi kataloog, mis salvestab teavet inimeste, ettevõtete ja valitsusasutuste ningneed sisaldavad tavaliselt nimesid, aadresse ja telefoninumbreid. imestades Active Directory - mis see on, lihtsate sõnadega võib öelda, et see tehnoloogia sarnaneb kataloogiga, kuid on palju paindlikum. AD salvestab teavet organisatsioonide, saitide, süsteemide, kasutajate, aktsiate ja muude võrguobjektide kohta.

Sissejuhatus Active Directory põhikontseptsioonidesse

Miks vajab organisatsioon Active Directoryt? Nagu Active Directory sissejuhatuses mainitud, salvestab teenus teavet võrgukomponentide kohta. Juhendis "Aktiivne kataloog algajatele" öeldakse, et see on nii võimaldab klientidel leida oma nimeruumist objekte. See t termin (nimetatakse ka konsoolipuuks) viitab alale, kus võrgukomponent võib paikneda. Näiteks loob raamatu sisukord nimeruumi, milles saab peatükke vastendada leheküljenumbritega.

DNS on konsoolipuu, mis lahendab hostinimed IP-aadressideks, nttelefoniraamatud pakuvad telefoninumbrite nimede lahendamiseks nimeruumi. Ja kuidas see Active Directorys toimub? AD pakub konsoolipuud võrguobjektide nimede lahendamiseks objektidele endile jasuudab lahendada mitmesuguseid objekte, sealhulgas võrgu kasutajaid, süsteeme ja teenuseid.

Objektid ja atribuudid

Kõik, mida Active Directory jälgib, loetakse objektiks. Võite öelda lihtsate sõnadega, et see on Active Directory'is on mis tahes kasutaja, süsteem, ressurss või teenus. Levinud termineid objekt kasutatakse seetõttu, et AD suudab jälgida paljusid elemente ja paljudel objektidel võivad olla ühised atribuudid. Mida see tähendab?

Atribuudid kirjeldavad Active Directory objekte, näiteks jagavad kõik kasutajaobjektid atribuute kasutaja nime salvestamiseks. See kehtib ka nende kirjelduste kohta. Süsteemid on samuti objektid, kuid neil on eraldi atribuutide komplekt, mis sisaldab hostinime, IP-aadressi ja asukohta.

Iga konkreetse objektitüübi jaoks saadaolevat atribuutide komplekti nimetatakse skeemiks. See muudab objektiklassid üksteisest eristatavaks. Skeemiteave salvestatakse tegelikult Active Directorysse. See, et turvaprotokolli selline käitumine on väga oluline, on asjaolu, et skeem võimaldab administraatoritel lisada objektiklassidesse atribuute ja levitada neid võrgu kaudu domeeni kõikidesse nurkadesse ilma domeenikontrollereid taaskäivitamata.

LDAP-konteiner ja nimi

Konteiner on eritüüpi objekt, mida kasutatakse teenuse toimimise korraldamiseks. See ei esinda füüsilist olemit, nagu kasutaja või süsteem. Selle asemel kasutatakse seda muude elementide rühmitamiseks. Konteinerobjekte saab pesastada teistesse konteineritesse.

Igal AD elemendil on nimi. Need pole need, millega olete harjunud, näiteks Ivan või Olga. Need on LDAP-i eristavad nimed. LDAP-i eristavad nimed on keerulised, kuid võimaldavad teil kataloogis mis tahes objekti unikaalselt tuvastada, olenemata selle tüübist.

Terminipuu ja veebisait

Terminipuud kasutatakse Active Directory objektide komplekti kirjeldamiseks. Mis see on? Lihtsamalt öeldes saab seda seletada puuühenduse abil. Kui konteinereid ja objekte hierarhiliselt kombineerida, kipuvad nad moodustama harusid – sellest ka nimi. Seotud termin on külgnev alampuu, mis viitab puu katkematule põhitüvele.

Metafoori jätkates kirjeldab mõiste "mets" kollektsiooni, mis ei kuulu samasse nimeruumi, kuid millel on ühine skeem, konfiguratsioon ja globaalne kataloog. Nendes struktuurides olevad objektid on turvalisuse korral kättesaadavad kõigile kasutajatele. Organisatsioonid, mis on jagatud mitmeks domeeniks, peaksid rühmitama puud ühte metsa.

Sait on Active Directorys määratletud geograafiline asukoht. Saidid vastavad loogilistele IP-alamvõrkudele ja seetõttu saavad rakendused neid kasutada võrgu lähima serveri leidmiseks. Active Directory saidi teabe kasutamine võib oluliselt vähendada WAN-liiklust.

Active Directory haldus

Active Directory lisandmoodul – kasutajad. See on Active Directory haldamiseks kõige mugavam tööriist. See on otse juurdepääsetav menüü Start jaotisest Haldustööriistad. See asendab ja täiustab Windows NT 4.0 serverihaldurit ja kasutajahaldurit.

Ohutus

Active Directory mängib Windowsi võrgunduse tulevikus olulist rolli. Administraatorid peavad suutma kaitsta oma kataloogi sissetungijate ja kasutajate eest, delegeerides samal ajal ülesandeid teistele administraatoritele. Kõik see on võimalik Active Directory turbemudeli abil, mis seob juurdepääsukontrolli loendi (ACL) iga kataloogi konteineri ja objekti atribuudiga.

Kõrge kontrollitase võimaldab administraatoril anda üksikutele kasutajatele ja rühmadele objektidele ja nende omadustele erineva tasemega õigusi. Nad võivad isegi lisada objektidele atribuute ja peita need atribuudid teatud kasutajarühmade eest. Näiteks saate määrata ACL-i nii, et ainult haldurid saaksid vaadata teiste kasutajate kodutelefone.

Delegeeritud haldus

Windows 2000 Serveri uus kontseptsioon on delegeeritud haldus. See võimaldab määrata teistele kasutajatele ülesandeid ilma täiendavaid juurdepääsuõigusi andmata. Delegeeritud haldust saab määrata konkreetsete objektide või külgnevate kataloogi alampuude kaudu. See on palju tõhusam viis võrkudes lubade andmiseks.

IN sihtkoht kellegi jaoks, kellel on kõik globaalse domeeni administraatori õigused, saab kasutajale õigusi anda ainult konkreetse alampuu piires. Active Directory toetab pärimist, nii et kõik uued objektid pärivad oma konteineri ACL-id.

Mõiste "usaldus"

Mõistet "usaldus" kasutatakse endiselt, kuid sellel on erinevad funktsioonid. Ei tehta vahet ühepoolsete ja kahepoolsete usaldusfondide vahel. Lõppude lõpuks on kõik Active Directory usaldusfondid kahesuunalised. Pealegi on need kõik transitiivsed. Seega, kui domeen A usaldab domeeni B ja B usaldab C, on domeeni A ja domeeni C vahel automaatne kaudne usaldussuhe.

Audit Active Directorys – mis see lihtsate sõnadega on? See on turvafunktsioon, mis võimaldab teil määrata, kes üritab objektidele juurde pääseda ja kui edukas see katse on.

DNS-i (domeeninimede süsteemi) kasutamine

Süsteem, teisiti tuntud kui DNS, on hädavajalik iga Interneti-ühendusega organisatsiooni jaoks. DNS pakub nimede eraldusvõimet levinud nimede (nt mspress.microsoft.com) ja töötlemata IP-aadresside vahel, mis kasutavad suhtlemiseks võrgukihi komponente.

Active Directory kasutab objektide otsimiseks laialdaselt DNS-tehnoloogiat. See on märkimisväärne muudatus võrreldes varasemate Windowsi operatsioonisüsteemidega, mis nõuavad NetBIOS-i nimede lahendamist IP-aadresside järgi ja tuginevad WINS-ile või muudele NetBIOS-i nimelahenduse tehnikatele.

Active Directory töötab kõige paremini, kui seda kasutatakse Windows 2000 töötavate DNS-serveritega. Microsoft on muutnud administraatoritel Windows 2000 DNS-serveritele ülemineku lihtsaks, pakkudes migreerimisviisardeid, mis juhendavad administraatorit protsessi käigus.

Võib kasutada ka teisi DNS-servereid. Kuid sel juhul peavad administraatorid kulutama rohkem aega DNS-andmebaaside haldamisele. Millised on nüansid? Kui otsustate Windows 2000 DNS-servereid mitte kasutada, peate tagama, et teie DNS-serverid järgiksid uut DNS-i dünaamilise värskendusprotokolli. Serverid toetuvad domeenikontrollerite leidmiseks oma kirjete dünaamilisele värskendamisele. See ei ole mugav. Lõppude lõpuks, eKui dünaamilist värskendamist ei toetata, tuleb andmebaase käsitsi värskendada.

Windowsi domeenid ja Interneti-domeenid on nüüd täielikult ühilduvad. Näiteks nimi, nagu mspress.microsoft.com, tuvastab domeeni eest vastutavad Active Directory domeenikontrollerid, nii et iga DNS-juurdepääsuga klient võib domeenikontrolleri leida.Kliendid saavad DNS-i eraldusvõimet kasutada mis tahes arvu teenuste otsimiseks, kuna Active Directory serverid avaldavad DNS-i aadresside loendi, kasutades uusi dünaamilisi värskendusfunktsioone. Need andmed on määratletud domeenina ja avaldatud teenuseressursside kirjete kaudu. SRV RR järgi vormingut service.protocol.domain.

Active Directory serverid pakuvad objekti majutamiseks LDAP-teenust ja LDAP kasutab aluseks oleva transpordikihi protokollina TCP-d. Seetõttu otsib klient, kes otsib Active Directory serverit domeenis mspress.microsoft.com, DNS-i kirje ldap.tcp.mspress.microsoft.com.

Globaalne kataloog

Active Directory pakub globaalset kataloogi (GC) japakub ühtset allikat mis tahes objekti otsimiseks organisatsiooni võrgus.

Globaalne kataloog on Windows 2000 Serveri teenus, mis võimaldab kasutajatel leida mis tahes objekti, millele on antud juurdepääs. See funktsioon on palju parem kui Windowsi eelmiste versioonidega kaasas olnud rakendus Otsi arvuti. Lõppude lõpuks saavad kasutajad Active Directoryst otsida mis tahes objekte: servereid, printereid, kasutajaid ja rakendusi.

Active Directory on Microsofti kataloogiteenus Windows NT operatsioonisüsteemide perekonnale.

See teenus võimaldab administraatoritel kasutada rühmapoliitikaid, et tagada ühtsed kasutaja tööruumi sätted, tarkvara installimised, värskendused ja palju muud.

Mis on Active Directory olemus ja milliseid ülesandeid see lahendab? Loe edasi.

Peer-to-peer ja multi-peer võrkude korraldamise põhimõtted

Kuid tekib veel üks probleem, mis saab siis, kui PC2 kasutaja2 otsustab oma parooli muuta? Kui kasutaja1 muudab konto parooli, ei pääse kasutaja2 arvutis 1 ressursile juurde.

Teine näide: meil on 20 tööjaama 20 kontoga, millele tahame anda juurdepääsu teatud ühele, selleks peame failiserveris looma 20 kontot ja andma juurdepääsu vajalikule ressursile.

Ja kui neid pole mitte 20, vaid 200?

Nagu aru saate, muutub võrguhaldus sellise lähenemisviisiga täielikuks põrguks.

Seetõttu sobib töörühma lähenemisviis väikestele kontorivõrkudele, kus on kuni 10 arvutit.

Kui võrgus on rohkem kui 10 tööjaama, muutub ratsionaalselt põhjendatuks lähenemine, kus ühele võrgusõlmele delegeeritakse õigused autentimiseks ja autoriseerimiseks.

See sõlm on domeenikontroller – Active Directory.

Domeenikontroller

Vastutav töötleja peab kontode andmebaasi, s.o. see hoiab kontot nii PC1 kui ka PC2 jaoks.

Nüüd registreeritakse kõik kontod kontrolleris üks kord ja vajadus kohalike kontode järele muutub mõttetuks.

Nüüd, kui kasutaja logib arvutisse sisse, sisestades oma kasutajanime ja parooli, edastatakse need andmed krüpteeritud kujul domeenikontrollerile, mis teostab autentimis- ja autoriseerimisprotseduure.

Pärast seda, kui kontroller annab sisse loginud kasutajale midagi passi taolist, millega ta hiljem võrgus töötab ja mida ta esitab teiste võrgus olevate arvutite nõudmisel, serverid, mille ressurssidega ta soovib ühendust luua.

Tähtis! Domeenikontroller on arvuti, kus töötab Active Directory ja mis haldab kasutajate juurdepääsu võrguressurssidele. See salvestab ressursse (nt printerid, jagatud kaustad), teenuseid (nt e-post), inimesi (kasutajate ja kasutajarühmade kontod), arvuteid (arvutikontod).

Säästetud ressursside arv võib ulatuda miljonite objektideni.

Domeenikontrollerina võivad toimida järgmised MS Windowsi versioonid: Windows Server 2000/2003/2008/2012, välja arvatud Web-Editioni väljaanded.

Domeenikontroller on lisaks võrgu autentimiskeskusele ka kõigi arvutite juhtimiskeskus.

Kohe pärast arvuti sisselülitamist hakkab see domeenikontrolleriga ühendust võtma juba ammu enne autentimisakna ilmumist.

Seega autentitakse mitte ainult sisselogimise ja parooli sisestanud kasutaja, vaid ka klientarvuti autentimine.

Active Directory installimine

Vaadake näidet Active Directory installimisest Windows Server 2008 R2-sse. Nii et Active Directory rolli installimiseks minge "Serverihaldurisse":

Lisage roll "Lisa rollid":

Valige Active Directory domeeniteenuste roll:

Ja alustame installimist:

Seejärel kuvatakse installitud rolli kohta teavitusaken:

Pärast domeenikontrolleri rolli installimist jätkame kontrolleri enda installimisega.

Klõpsake programmi otsinguväljal "Start", sisestage DCPromo viisardi nimi, käivitage see ja märkige ruut täpsemate installisätete jaoks:

Klõpsake pakutud valikute hulgast "Järgmine", valige uue domeeni ja metsa loomine.

Sisestage domeeninimi, näiteks example.net.

Kirjutame NetBIOS-i domeeninime ilma tsoonita:

Valime oma domeeni funktsionaalse taseme:

Domeenikontrolleri toimimise iseärasuste tõttu paigaldame ka DNS-serveri.

Andmebaasi, logifaili, süsteemimahu asukoht jäetakse muutmata:

Sisestage domeeni administraatori parool:

Kontrollime täitmise õigsust ja kui kõik on korras, vajuta "Edasi".

Pärast seda algab installiprotsess, mille lõpus ilmub aken, mis teatab edukast installimisest:

Sissejuhatus Active Directorysse

Aruandes käsitletakse kahte tüüpi arvutivõrke, mida saab luua Microsofti operatsioonisüsteemide abil: töörühm (töörühm) ja Active Directory domeen.