Üksused on osa aktiivsest kataloogiteenusest. Sissejuhatus. Serveri ülendamine domeenikontrolleriks

Oma eelmistes artiklites oleme arutanud kataloogiteenuste ja Active Directoryga seotud levinud probleeme. Nüüd on aeg liikuda edasi harjutamise juurde. Kuid ärge kiirustage serverisse jooksma, enne domeenistruktuuri juurutamist oma võrgus peate selle planeerima ja omama selget ettekujutust üksikute serverite eesmärgist ja nendevahelise suhtluse protsessidest.

Enne esimese domeenikontrolleri loomist peate otsustama selle töörežiimi üle. Töörežiim määrab saadaolevad valikud ja sõltub kasutatava operatsioonisüsteemi versioonist. Me ei võta arvesse kõiki võimalikke režiime, välja arvatud need, mis on hetkel asjakohased. Selliseid režiime on kolm: Windows Server 2003, 2008 ja 2008 R2.

Windows Server 2003 režiim tuleks valida ainult siis, kui selle OS-i serverid on teie infrastruktuuris juba juurutatud ja kavatsete kasutada ühte või mitut neist serveritest domeenikontrolleritena. Muudel juhtudel peate sõltuvalt ostetud litsentsidest valima Windows Server 2008 või 2008 R2 režiimi. Tuleb meeles pidada, et domeeni töörežiimi saab alati suurendada, kuid seda pole võimalik alandada (välja arvatud varukoopiast taastamine), seega lähenege sellele probleemile ettevaatlikult, võttes arvesse võimalikke laiendusi, litsentse filiaalides jne. . ja nii edasi.

Me ei käsitle nüüd üksikasjalikult domeenikontrolleri loomise protsessi, tuleme selle probleemi juurde hiljem tagasi, kuid nüüd tahame juhtida teie tähelepanu asjaolule, et domeenikontrollerite täielikus Active Directory struktuuris peaks olema vähemalt kaks. Vastasel juhul seate end tarbetule riskile, sest ühe domeenikontrolleri rikke korral muutub teie AD struktuur täielikult hävitatud. Hea, kui on olemas ajakohane varukoopia ja saate sellest taastuda, igal juhul on teie võrk kogu selle aja täielikult halvatud.

Seetõttu peate kohe pärast esimese domeenikontrolleri loomist juurutama teise, olenemata võrgu suurusest ja eelarvest. Teine kontroller tuleks pakkuda planeerimisetapis ja ilma selleta ei tasu AD kasutuselevõttu isegi ette võtta. Samuti ärge kombineerige domeenikontrolleri rolli ühegi teise serverirolliga, AD-andmebaasiga töötamise usaldusväärsuse tagamiseks on kettale kirjutamise vahemällu salvestamine keelatud, mis toob kaasa ketta alamsüsteemi jõudluse järsu languse (see selgitab ka domeenikontrollerite pikka laadimist).

Selle tulemusena peaks meie võrk olema järgmisel kujul:

Vastupidiselt levinud arvamusele on kõik domeeni kontrollerid võrdsed; iga kontroller sisaldab täielikku teavet kõigi domeeniobjektide kohta ja suudab teenindada kliendi päringut. Kuid see ei tähenda, et kontrollerid on omavahel asendatavad, selle punkti valesti mõistmine põhjustab sageli AD tõrkeid ja ettevõtte võrgu seisakuid. Miks see juhtub? On aeg meenutada FSMO rolli.

Kui loome esimese kontrolleri, sisaldab see kõiki saadaolevaid rolle ja on ka globaalne kataloog, teise kontrolleri tulekuga kantakse sellele üle infrastruktuuri ülem-, RID-ülema- ja PDC-emulaatori rollid. Mis juhtub, kui administraator otsustab DC1 serveri ajutiselt keelata, näiteks selle tolmust puhastamiseks? Esmapilgul on kõik korras, domeen lülitub "kirjutuskaitstud" režiimi, kuid see töötab. Kuid unustasime globaalse kataloogi ja kui teie võrku on juurutatud seda vajavad rakendused, näiteks Exchange, saate sellest enne serveri kaane eemaldamist teada. Õpid rahulolematutelt kasutajatelt ja juhtkond tõenäoliselt ei rõõmusta.

Millest järeldub järeldus: metsas peaks olema vähemalt kaks globaalset kataloogi ja mis kõige parem, igas domeenis üks. Kuna meil on metsas üks domeen, peavad mõlemad serverid olema globaalsed kataloogid, see võimaldab teil ilma probleemideta kõik serverid hooldusesse viia, FSMO rollide ajutine puudumine ei too kaasa AD tõrkeid, vaid ainult muudab selle võimatu luua uusi objekte.

Domeeniadministraatorina peate selgelt mõistma, kuidas FSMO rollid teie serverite vahel jaotuvad, ning serveri pikemaks ajaks kasutusest kõrvaldamisel kandma need rollid üle teistele serveritele. Ja mis juhtub, kui FSMO rolle sisaldav server pöördumatult üles ütleb? Pole hullu, nagu me juba kirjutasime, sisaldab iga domeenikontroller kogu vajalikku teavet ja kui selline ebameeldivus ilmneb, peate ühe kontrolleri poolt vajalikud rollid hõivama, see taastab kataloogiteenuse täieliku toimimise. .

Aeg möödub, teie organisatsioon kasvab ja sellel on filiaal teisel pool linna ning muutub vajalikuks kaasata nende võrgustik ettevõtte üldisesse infrastruktuuri. Esmapilgul ei midagi keerulist, paned paika büroodevahelise suhtluskanali ja paigutad sinna lisakontrolleri. Kõik oleks hästi, kuid on üks asi. Te ei saa seda serverit juhtida ja seetõttu on volitamata juurdepääs sellele võimalik ning kohalik administraator paneb teid kahtlema tema kvalifikatsioonis. Kuidas olla sellises olukorras? Nendel eesmärkidel on spetsiaalselt spetsiaalne kontroller: kirjutuskaitstud domeenikontroller (RODC), on see funktsioon saadaval Windows Server 2008 ja uuemate versioonide domeeni funktsionaalrežiimides.

Kirjutuskaitstud domeenikontroller sisaldab kõigi domeeniobjektide täielikku koopiat ja võib olla globaalne kataloog, kuid ei võimalda teil AD struktuuris muudatusi teha, samuti võimaldab see määrata mis tahes kasutaja kohalikuks administraatoriks, mis luba tal seda serverit täielikult teenindada, kuid ilma juurdepääsuta AD-teenustele. Meie puhul on arst nii määranud.

Seadistasime RODC filiaalis, kõik töötab, olete rahulik, kuid kasutajad hakkavad kurtma pika sisselogimise üle ja kuu lõpus näitavad liiklusarved ülemäära. Mis toimub? On aeg veel kord meeles pidada domeenikontrollerite samaväärsust, klient saab saata oma päringu mis tahes domeenikontrollerile, isegi kui see asub teises filiaalis. Arvestage aeglase ja suure tõenäosusega hõivatud sidekanaliga – see on sisselogimisviivituste põhjus.

Järgmine tegur, mis meie elu selles olukorras mürgitab, on replikatsioon. Nagu teate, edastatakse kõik ühes domeenikontrolleris tehtud muudatused automaatselt teistele ja seda protsessi nimetatakse replikatsiooniks, see võimaldab teil saada iga kontrolleri andmetest ajakohase ja järjepideva koopia. Replikatsiooniteenus ei tea meie filiaalist ja aeglasest sidekanalist ning seetõttu kopeeritakse kõik kontoris tehtud muudatused kohe ka harusse, laadides kanalit ja suurendades liikluskulu.

Siin jõuame lähedale AD-saitide kontseptsioonile, mida ei tohiks segi ajada Interneti-saitidega. Active Directory saidid kujutavad endast viisi kataloogiteenuse struktuuri füüsiliseks jagamiseks piirkondadeks, mis on eraldatud teistest piirkondadest aeglaste ja/või ebastabiilsete linkidega. Saidid luuakse alamvõrkude alusel ja kõik klientide päringud saadetakse esmalt nende saidi kontrolleritele, samuti on väga soovitav, et igal saidil oleks globaalne kataloog. Meie puhul peame looma kaks saiti: AD 1. sait keskkontori jaoks ja AD 2. sait haru jaoks, täpsemalt üks, kuna vaikimisi sisaldab AD struktuur juba saiti, mis sisaldab kõiki varem loodud objekte. Nüüd vaatame, kuidas toimub replikatsioon mitme saidiga võrgus.

Eeldame, et meie organisatsioon on veidi kasvanud ja peakontoris on koguni neli domeenikontrollerit, ühe saidi kontrollerite vahelist replikatsiooni nimetatakse saidisiseselt ja juhtub koheselt. Replikatsiooni topoloogia on üles ehitatud rõngaskeemi järgi tingimusel, et ühegi domeenikontrolleri vahel ei ole rohkem kui kolm replikatsioonietappi. Rõngaskeem on salvestatud kuni 7 kontrollerini (kaasa arvatud), iga kontroller loob ühenduse kahe lähima naabriga, suurema arvu kontrollerite korral tekivad täiendavad ühendused ja ühine ring muutub justkui üksteise peale asetatud rõngaste rühmaks.

Intersite replikatsioon toimub erinevalt, igas domeenis valitakse automaatselt üks serveritest (sillapeaserver), mis loob ühenduse mõne teise saidi sarnase serveriga. Vaikimisi toimub replikatsioon iga 3 tunni (180 minuti) tagant, samas saame ise määrata replikatsioonigraafiku ja liikluse säästmiseks edastatakse kõik andmed kokkusurutud kujul. Kui saidil on ainult RODC, toimub replikatsioon ühesuunaliselt.

Loomulikult on käsitletud teemad väga sügavad ja selles materjalis puudutasime neid vaid veidi, kuid need on vajalikud miinimumteadmised, mis teil peavad olema enne Active Directory praktilist juurutamist ettevõtte infrastruktuuris. See väldib rumalaid vigu juurutamisel ja hädaolukordi konstruktsiooni hooldamisel ja laiendamisel ning iga tõstatatud teemat käsitletakse üksikasjalikumalt.

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

Märkus: See loeng kirjeldab Active Directory kataloogiteenuste põhikontseptsioone. Tuuakse praktilisi näiteid võrguturbe haldamisest. Kirjeldatakse grupipoliitikate mehhanismi. Annab ülevaate võrguadministraatori ülesannetest kataloogiteenuse infrastruktuuri haldamisel

Kaasaegsed võrgud koosnevad sageli paljudest erinevatest tarkvaraplatvormidest, laiast valikust riist- ja tarkvarast. Erinevatele võrguressurssidele juurdepääsuks on kasutajad sageli sunnitud meeles pidama suurt hulka paroole. Juurdepääsuõigused võivad sama töötaja puhul olla erinevad, olenevalt ressurssidest, millega ta töötab. Kõik need omavahelised seosed nõuavad administraatorilt ja kasutajalt tohutult aega analüüsimiseks, meeldejätmiseks ja õppimiseks.

Sellise heterogeense võrgu haldamise probleemile leiti lahendus kataloogiteenuse arendamisega. Kataloogiteenused pakuvad võimalust hallata mis tahes ressurssi või teenust kõikjal, sõltumata võrgu suurusest, operatsioonisüsteemidest või riistvara keerukusest. Teave kasutaja kohta sisestatakse kataloogiteenusesse üks kord ja pärast seda muutub see kättesaadavaks kogu võrgus. Meiliaadressid, grupiliikmed, vajalikud juurdepääsuõigused ja kontod erinevate operatsioonisüsteemidega töötamiseks – kõik see luuakse ja hoitakse ajakohasena automaatselt. Kõiki administraatori poolt kataloogiteenuses tehtud muudatusi värskendatakse kohe kogu võrgus. Administraatorid ei pea enam muretsema lõpetatud töötajate pärast – lihtsalt kustutades kataloogiteenusest kasutajakonto, saavad nad tagada, et kõik sellele töötajale varem antud võrguressurssidele juurdepääsuõigused eemaldatakse automaatselt.

Praegu põhineb enamik erinevate ettevõtete kataloogiteenuseid standardil X.500. Kataloogiteenustes salvestatud teabele juurdepääsuks kasutatakse tavaliselt protokolli. (LDAP). TCP/IP-võrkude kiire arenguga on LDAP-st saamas kataloogiteenuste ja kataloogile orienteeritud rakenduste standard.

Kataloogiteenus Active Directory on Windowsi süsteemil põhinevate ettevõtete võrkude loogilise struktuuri alus. Mõiste " Kataloog"laiemas mõttes tähendab" Kataloog", A kataloogiteenus ettevõtte võrk on tsentraliseeritud ettevõtte kataloog. Ettevõtte kataloog võib sisaldada teavet erinevat tüüpi objektide kohta. Kataloogiteenus Active Directory sisaldab peamiselt objekte, millel Windowsi võrguturbesüsteem põhineb – kasutaja-, grupi- ja arvutikontod. Kontod on organiseeritud loogilistesse struktuuridesse: domeen, puu, mets, organisatsiooniüksused.

Kursuse „Võrgustik administreerimine"Õpetus on täiesti võimalik läbida järgmiselt: kõigepealt uurige selle jaotise esimest osa (alates põhikontseptsioonidest kuni domeenikontrollerite installimiseni), seejärel minge jaotisse "Faili- ja printimisteenus" ja pärast tutvumist "Faili- ja printimisteenus" naaske "Active Directory Service Directory" juurde, et õppida kataloogiteenuste täpsemaid kontseptsioone.

6.1 Põhimõisted ja mõisted (mets, puu, domeen, organisatsiooniüksus). AD nimeruumi planeerimine. Domeenikontrollerite installimine

Turvahaldusmudelid: töörühmamudel ja tsentraliseeritud domeenimudel

Nagu eespool mainitud, on kataloogiteenuste peamine eesmärk võrguturbe haldamine. Võrguturbe aluseks on kasutajate, kasutajarühmade ja arvutite kontode (kontode) andmebaas, mille abil kontrollitakse juurdepääsu võrguressurssidele. Enne Active Directory kataloogiteenusest rääkimist võrdleme kahte mudelit kataloogiteenuste andmebaasi koostamiseks ja ressurssidele juurdepääsu haldamiseks.

Mudel "töörühm"

See ettevõtte võrguturbe haldusmudel on kõige primitiivsem. See on mõeldud kasutamiseks väikestes peer-to-peer võrgud(3–10 arvutit) ja põhineb asjaolul, et igal võrgus oleval arvutil operatsioonisüsteemidega Windows NT/2000/XP/2003 on oma kohalik kontode andmebaas ja see kohalik andmebaas kontrollib juurdepääsu selle arvuti ressurssidele. Kohalikku kontode andmebaasi nimetatakse andmebaasiks SAM (Turvakonto haldur) ja see on salvestatud operatsioonisüsteemi registrisse. Üksikute arvutite andmebaasid on üksteisest täielikult eraldatud ega ole omavahel seotud.

Sellist mudelit kasutava juurdepääsu juhtimise näide on näidatud joonisel fig. 6.1.


Riis. 6.1.

See näide näitab kahte serverit (SRV-1 ja SRV-2) ja kahte tööjaama (WS-1 ja WS-2). Nende SAM-andmebaasid on tähistatud vastavalt SAM-1, SAM-2, SAM-3 ja SAM-4 (SAM-andmebaasid on joonisel kujutatud ovaalsena). Igal andmebaasil on kasutajakontod Kasutaja1 ja Kasutaja2. Kasutaja1 täielik kasutajanimi SRV-1 serveris näeb välja kujul "SRV-1\User1" ja kasutaja1 täisnimi WS-1 tööjaamas näeb välja nagu "WS-1\Kasutaja1". Kujutagem ette, et SRV-1 serverisse luuakse kaust Folder, millele antakse üle võrgu juurdepääs kasutajatele Kasutaja1 - lugemiseks (R), Kasutaja2 - lugemiseks ja kirjutamiseks (RW). Selle mudeli põhipunkt on see, et SRV-1 arvuti "ei tea" midagi SRV-2, WS-1, WS-2 arvutite ja ka kõigi teiste võrgus olevate arvutite kontodest. Kui kasutaja nimega Kasutaja1 logib arvutisse, näiteks WS-2, lokaalselt sisse (või, nagu öeldakse, "logib sisse kohaliku nimega User1 arvutisse WS-2"), siis proovides sellest arvutist juurdepääsu võrku, SRV-1 serveri kausta, küsib server kasutajalt kasutajanime ja parooli (välja arvatud juhul, kui sama kasutajanimega kasutajatel on sama parool).

"Workgroup" mudelit on lihtsam õppida, pole vaja õppida Active Directory keerulisi kontseptsioone. Kuid kui seda kasutatakse võrgus, kus on palju arvuteid ja võrguressursse, muutub kasutajanimede ja nende paroolide haldamine väga keeruliseks – igas arvutis tuleb käsitsi luua samad kontod samade paroolidega (mis pakub oma ressursse jagamiseks võrk), mis on väga töömahukas, või luua kõigile kasutajatele üks konto, millel on kõigile üks parool (või ilma paroolita), mis vähendab oluliselt teabekaitse taset. Seetõttu on mudel "Töörühm" soovitatav ainult võrkude jaoks, kus on 3–10 arvutit (ja veelgi parem - mitte rohkem kui 5), eeldusel, et kõigi arvutite hulgas pole ühtegi Windows Serveri süsteemiga arvutit.

domeeni mudel

Domeenimudelis on üks kataloogiteenuste andmebaas, mis on saadaval kõigile võrgus olevatele arvutitele. Selleks installitakse võrku spetsiaalsed serverid, nn domeenikontrollerid mis salvestavad selle andmebaasi oma kõvakettale. Joonisel fig. 6.2. on näidatud domeenimudeli diagramm. Serverid DC-1 ja DC-2 on domeenikontrollerid, mis salvestavad kontode domeeniandmebaasi (iga kontroller säilitab andmebaasist oma koopia, kuid kõik ühes serveris andmebaasis tehtud muudatused kopeeritakse teistele kontrolleritele).


Riis. 6.2.

Kui selles mudelis on näiteks domeeni liikmes SRV-1 serveris jagatud juurdepääs kaustale Folder, siis saab sellele ressursile juurdepääsuõigusi määrata mitte ainult kohaliku omavalitsuse kontodele. Selle serveri SAM-i andmebaasi, kuid mis kõige tähtsam, domeeni andmebaasi salvestatud kontokirjetele. Joonisel kausta Folder pääsemiseks antakse juurdepääsuõigused ühele SRV-1 arvuti lokaalsele kontole ja mitmele domeenikontole (kasutaja ja kasutajagrupid). Domeeni turbehaldusmudelis logib kasutaja arvutisse sisse ("logib sisse") enda omaga domeeni konto ja olenemata arvutist, milles registreerimine tehti, pääseb juurde vajalikele võrguressurssidele. Ja igas arvutis pole vaja luua suurt hulka kohalikke kontosid, luuakse kõik kirjed üks kord domeeni andmebaasis. Ja domeeni andmebaasi abil viiakse läbi tsentraliseeritud juurdepääsukontroll võrguressurssidele sõltumata võrgus olevate arvutite arvust.

Active Directory kataloogiteenuse eesmärk

Kataloog (kataloog) võib salvestada mitmesugust teavet, mis on seotud kasutajate, rühmade, arvutite, võrguprinterite, failide ühiskasutusse ja muuga - me kutsume kõiki neid objekte. Kataloog salvestab ka teavet objekti enda või selle omaduste kohta, mida nimetatakse atribuutideks. Näiteks võivad kataloogi salvestatud atribuudid kasutaja kohta olla tema halduri nimi, telefoninumber, aadress, sisselogimisnimi, parool, rühmad, kuhu nad kuuluvad ja palju muud. Selleks, et muuta kataloogi salvestamine kasutajatele kasulikuks, peavad olema teenused, mis kataloogiga suhtlevad. Näiteks saate kataloogi kasutada teabehoidlana, mille alusel saab kasutajat autentida, või kohana, kuhu saata päring, et leida teavet objekti kohta.

Active Directory ei vastuta mitte ainult nende väikeste objektide loomise ja korraldamise eest, vaid ka suurte objektide (nt domeenid, OU-d (organisatsiooniüksused) ja saidid) eest.

Allpool lugege Active Directory kataloogiteenuse kontekstis kasutatavaid põhitermineid.

Kataloogiteenus Active Directory (lühendatult AD ) võimaldab keeruka ettevõtte keskkonna tõhusat toimimist, pakkudes järgmisi funktsioone:

  • Ühekordne sisselogimine võrgus; Kasutajad saavad võrku sisse logida ühe kasutajanime ja parooliga ning neil on endiselt juurdepääs kõigile võrguressurssidele ja teenustele (võrgu infrastruktuuri teenused, faili- ja printimisteenused, rakendus- ja andmebaasiserverid jne);
  • Infoturbe. Active Directorysse sisseehitatud autentimis- ja ressurssidele juurdepääsu juhtelemendid tagavad tsentraliseeritud võrguturbe;
  • Tsentraliseeritud juhtimine. Administraatorid saavad tsentraalselt hallata kõiki ettevõtte ressursse;
  • Haldus rühmapoliitika abil. Kui arvuti käivitub või kasutaja logib süsteemi sisse, on rühmapoliitika nõuded täidetud; nende seaded on salvestatud rühmapoliitika objektid( GPO ) ja rakendatakse kõikidele kasutaja- ja arvutikontodele, mis asuvad saitidel, domeenides või organisatsiooniüksustes;
  • DNS-i integreerimine. Kataloogiteenuste toimimine sõltub täielikult DNS-teenuse toimimisest. DNS-serverid saavad omakorda salvestada teavet tsoonide kohta Active Directory andmebaasis;
  • Kataloogi laiendatavus. Administraatorid saavad lisada kataloogiskeemile uusi objektiklasse või lisada olemasolevatele klassidele uusi atribuute;
  • Skaleeritavus. Active Directory teenus võib hõlmata nii ühte domeeni kui ka paljusid domeenide puuks kombineeritud domeene ning metsa saab ehitada mitmest domeenipuust;
  • Teabe replikatsioon. Active Directory kasutab multimasteriskeemis üldkulusid ( multi-master), mis võimaldab teil muuta Active Directory andmebaasi mis tahes domeenikontrolleris. Mitme kontrolleri olemasolu domeenis tagab tõrketaluvuse ja võimaluse jaotada võrgukoormust;
  • Kataloogipäringute paindlikkus. Active Directory andmebaasi saab kasutada mis tahes AD objekti kiireks otsimiseks, kasutades selle atribuute (näiteks kasutajanimi või meiliaadress, printeri tüüp või asukoht jne);
  • Standardsed programmeerimisliidesed. Tarkvaraarendajatele pakub kataloogiteenus juurdepääsu kõikidele kataloogi funktsioonidele (tööriistadele) ning toetab aktsepteeritud standardeid ja programmeerimisliideseid (API-sid).

Active Directory's saab luua laias valikus erinevaid objekte. Objekt on kataloogis ainulaadne olem ja sellel on tavaliselt palju atribuute, mis aitavad seda kirjeldada ja ära tunda. Kasutajakonto on objekti näide. Sellel objektitüübil võib olla palju atribuute, nagu eesnimi, perekonnanimi, parool, telefoninumber, aadress ja palju muud. Samamoodi võib jagatud printer olla ka Active Directory objekt ja selle atribuudid on selle nimi, asukoht jne. Objekti atribuudid mitte ainult ei aita objekti tuvastada, vaid võimaldavad teil ka kataloogist objekte otsida.

Terminoloogia

Kataloogiteenus Windows Server on üles ehitatud üldtunnustatud tehnoloogiastandarditele. Algne kataloogiteenuste standard oli X.500, mis oli mõeldud hierarhiliste puulaadsete skaleeritavate kataloogide loomiseks võimalusega laiendada nii objektiklasse kui ka iga üksiku klassi atribuutide (atribuutide) komplekte. Selle standardi praktiline rakendamine on aga osutunud jõudluse osas ebatõhusaks. Seejärel töötati X.500 standardi alusel välja kataloogihoone standardi lihtsustatud (kergekaaluline) versioon nn. LDAP (Kergekaaluline kataloogipääsu protokoll). LDAP-protokoll säilitab kõik X.500 põhiomadused (hierarhiline kataloogide koostamise süsteem, skaleeritavus, laiendatavus ), kuid samal ajal võimaldab teil seda standardit praktikas tõhusalt rakendada. Mõiste " kergekaaluline " (" kergekaaluline") peegeldab LDAP-i nimel protokolli arendamise peamist eesmärki: luua kataloogiteenuse ehitamiseks tööriistakomplekt, millel on küllaldane funktsionaalne võimsus põhiülesannete lahendamiseks, kuid mis ei ole ülekoormatud keerukate tehnoloogiatega, mis muudavad kataloogiteenuste rakendamise ebaefektiivseks. . Praegu on LDAP standardmeetod teabele juurdepääsuks võrgukataloogidele ja mängib olulist rolli paljudes toodetes, nagu näiteks autentimissüsteemid, meiliprogrammid ja e-kaubanduse rakendused. Tänapäeval on turul üle 60 kaubandusliku LDAP-serveri, millest umbes 90% on eraldiseisvad LDAP-kataloogiserverid, ülejäänud pakutakse muude rakenduste komponentidena.

LDAP-protokoll määratleb selgelt kataloogitoimingute vahemiku, mida klientrakendus saab teha. Need toimingud jagunevad viide rühma:

  • kataloogiga ühenduse loomine;
  • otsige sellest teavet;
  • selle sisu muutmine;
  • objekti lisamine;
  • objekti kustutamine.

Muud kui LDAP kataloogiteenus Active Directory kasutab ka autentimisprotokolli Kerberos ja DNS-teenus kataloogiteenuste komponentide (domeenikontrollerid, globaalsete kataloogide serverid, Kerberose teenus jne).

Domeen

Active Directory turvasüsteemi põhiüksus on domeeni. Domeen moodustab haldusvastutuse valdkonna. Domeeni andmebaas sisaldab kontosid kasutajad, rühmad Ja arvutid. Enamik kataloogihaldusfunktsioone töötab domeeni tasemel (kasutaja autentimine, ressurssidele juurdepääsu kontroll, teenuse kontroll, replikatsiooni juhtimine, turvapoliitikad).

Active Directory domeeninimed järgivad sama mustrit nagu DNS-i nimeruumis olevad nimed. Ja see pole juhus. DNS-teenus on vahend domeenikomponentide – eelkõige domeenikontrollerite – leidmiseks.

Domeenikontrollerid- spetsiaalsed serverid, mis salvestavad sellele domeenile vastava Active Directory andmebaasi osa. Domeenikontrollerite peamised funktsioonid:

  • Active Directory andmebaasi salvestamine(kataloogis sisalduvale teabele juurdepääsu korraldamine, sealhulgas selle teabe haldamine ja selle muutmine);
  • AD muutuste sünkroniseerimine(muudatusi AD andmebaasis saab teha mis tahes domeenikontrolleris, kõik ühes kontrollerites tehtud muudatused sünkroonitakse teistes kontrollerites salvestatud koopiatega);
  • kasutaja autentimine(ükskõik milline domeenikontroller kontrollib kliendisüsteemidesse sisse logivate kasutajate mandaate).

Soovitatav on paigaldada igasse domeeni vähemalt kaks domeenikontrollerit – esiteks kaitseks Active Directory andmebaasi kadumise eest kontrolleri rikke korral ja teiseks koormuse jaotamiseks controllers.it.company.ru vahel. omab alamdomeeni dev.it.company.ru , mis on loodud IT-teenuse tarkvaraarenduse osakonna jaoks.

  • kataloogiteenuste haldamise detsentraliseerimiseks (näiteks juhul, kui ettevõtte filiaalid asuvad üksteisest geograafiliselt kaugel ja tsentraliseeritud haldamine on tehnilistel põhjustel keeruline);
  • jõudluse parandamiseks (suure kasutajate ja serverite arvuga ettevõtete jaoks on domeenikontrollerite jõudluse suurendamise küsimus aktuaalne);
  • replikatsiooni tõhusamaks haldamiseks (kui domeenikontrollerid on üksteisest kaugel, võib replikatsioon ühes võtta kauem aega ja tekitada probleeme sünkroonimata andmete kasutamisel);
    • metsa juurdomeen ( metsa juurdomeen), ei saa seda domeeni kustutada (salvestab teavet metsa konfiguratsiooni ja selle moodustavate domeenipuude kohta).

Organisatsiooniüksused (OD).

Organisatsiooniüksused (Organisatsiooniüksused, ou) – AD-s olevad konteinerid, mis on loodud objektide rühmitamiseks haldusõiguste delegeerimine Ja grupipoliitika rakendamine domeenis. OP on olemas ainult domeenide sees ja saab kombineerida ainult objektid oma domeenist. OP-sid saab üksteise sisse pesastada, mis võimaldab luua domeenis kompleksse puulaadse konteinerite hierarhia ja kasutada paindlikumat halduskontrolli. Lisaks saab luua OP-sid, mis kajastavad ettevõtte haldushierarhiat ja organisatsioonilist struktuuri.

Ülemaailmne kataloog

Ülemaailmne kataloog on nimekiri kõik objektid mis eksisteerivad Active Directory metsas. Vaikimisi sisaldavad domeenikontrollerid teavet ainult nende domeeni objektide kohta. Globaalne kataloogiserver on domeenikontroller, mis hoiab teavet kõigi metsa objektide (kuigi mitte kõigi nende objektide atribuutide) kohta.

Active Directory

Active Directory("Aktiivsed kataloogid", AD) - LDAP- ettevõtte kataloogiteenuse ühilduv rakendamine Microsoft pere operatsioonisüsteemide jaoks Windows NT. Active Directory võimaldab administraatoritel kasutada rühmapoliitikaid, et tagada järjepidev kasutajakogemuse seadistus, juurutada tarkvara mitmesse arvutisse rühmapoliitika või nende kaudu System Centeri konfiguratsioonihaldur(varem Microsoft Systems Management Server), installige värskendusteenust kasutades kõikidesse võrgus olevatesse arvutitesse operatsioonisüsteemi, rakenduste ja serveritarkvara värskendused Windows Server . Active Directory salvestab keskkonnaandmed ja seadistused tsentraliseeritud andmebaasi. võrgud Active Directory võib olla erineva suurusega: mitmekümnest kuni mitme miljoni objektini.

Esitus Active Directory toimus 1999. aastal, toodeti esmakordselt koos Windows 2000 Server, ning seda muudeti ja täiustati pärast vabastamist Windows Server 2003. Järgnevalt Active Directory aastal on täiustatud Windows Server 2003 R2, Windows Server 2008 Ja Windows Server 2008 R2 ja ümber nimetatud Active Directory domeeniteenused. Varem kutsuti kataloogiteenust NT kataloogiteenus (NTDS), võib seda nime mõnes käivitatavas failis siiski leida.

Erinevalt versioonidest Windows enne Windows 2000 kes kasutasid peamiselt protokolli NetBIOS võrgu loomiseks, teenindamiseks Active Directory integreeritud DNS Ja TCP/IP. Vaikimisi autentimisprotokoll on Kerberos. Kui klient või rakendus ei toeta autentimist Kerberos, kasutatakse protokolli NTLM .

Seade

Objektid

Active Directory on hierarhilise struktuuriga, mis koosneb objektidest. Objektid jagunevad kolme põhikategooriasse: ressursid (nt printerid), teenused (nt e-post) ning kasutaja- ja arvutikontod. Active Directory annab teavet objektide kohta, võimaldab objekte korrastada, juhtida neile juurdepääsu ja kehtestab turvareeglid.

Objektid võivad olla konteinerid muude objektide jaoks (turva- ja jaotusrühmad). Objekt on üheselt identifitseeritud selle nime järgi ja sellel on atribuutide kogum – omadused ja andmed, mida see võib sisaldada; viimased omakorda sõltuvad objekti tüübist. Atribuudid on objekti struktuuri aluseks ja need on määratletud skeemis. Skeem määrab, mis tüüpi objektid võivad eksisteerida.

Skeem ise koosneb kahte tüüpi objektidest: skeemiklassi objektid ja skeemi atribuudiobjektid. Üks skeemiklassi objekt määratleb ühe objektitüübi Active Directory(näiteks kasutaja objekt) ja üks skeemi atribuudi objekt määratleb atribuudi, mis objektil võib olla.

Iga atribuudiobjekti saab kasutada mitmes erinevas skeemiklassi objektis. Neid objekte nimetatakse skeemiobjektideks (või metaandmeteks) ja need võimaldavad teil skeemi vastavalt vajadusele muuta ja lisada. Siiski on iga skeemiobjekt osa objektide määratlustest Active Directory, nii et nende objektide keelamisel või muutmisel võivad olla tõsised tagajärjed, kuna nende toimingute tulemusena muutub struktuur Active Directory. Skeemiobjekti muudatus kantakse automaatselt edasi Active Directory. Pärast loomist ei saa skeemiobjekti kustutada, selle saab ainult keelata. Tavaliselt on kõik skeemimuudatused hoolikalt planeeritud.

Konteiner sarnased objektiks selles mõttes, et sellel on ka atribuudid ja see kuulub nimeruumi , kuid erinevalt objektist ei tähista konteiner midagi konkreetset: see võib sisaldada objektide rühma või muid konteinereid.

Struktuur

Struktuuri tipptase on mets – kõigi objektide, atribuutide ja reeglite kogu (atribuutide süntaks) Active Directory. Mets sisaldab ühte või mitut transitiivselt ühendatud puud usaldussuhted . Puu sisaldab ühte või mitut domeeni, mis on samuti hierarhias ühendatud transitiivsete usaldussuhetega. Domeenid tuvastatakse nende DNS-i nimestruktuuride – nimeruumide järgi.

Domeenis olevaid objekte saab rühmitada konteineritesse – OU-desse. Organisatsiooniüksused võimaldavad luua domeenisisese hierarhia, lihtsustada selle haldust ja modelleerida ettevõtte organisatsioonilist ja/või geograafilist struktuuri. Active Directory. Jaotised võivad sisaldada muid jaotisi. Korporatsioon Microsoft soovitab kasutada võimalikult vähe domeene Active Directory ning kasutada struktureerimiseks ja poliitikateks jaotusi. Grupipoliitikaid rakendatakse sageli spetsiaalselt organisatsiooniüksustele. Grupipoliitikad on ise objektid. Jaotus on madalaim tase, millel saab haldusõigust delegeerida.

Teine viis jagamiseks Active Directory on saidid , mis on füüsilise (mitte loogilise) rühmitamise viis, mis põhineb võrgusegmentidel. Saidid jagunevad madala kiirusega kanalite kaudu (näiteks globaalsete võrkude kaudu, virtuaalsete privaatvõrkude abil) ja kiirete kanalite kaudu (näiteks kohtvõrgu kaudu) ühendatavateks saitideks. Sait võib sisaldada ühte või mitut domeeni ja domeen võib sisaldada ühte või mitut saiti. Projekteerimisel Active Directory on oluline arvestada võrguliiklusega, mis tekib andmete sünkroonimisel saitide vahel.

Peamine disainiotsus Active Directory on otsus jagada infoinfrastruktuur hierarhilisteks domeenideks ja tipptasemel jaotusteks. Selle divisjoni jaoks kasutatavad tüüpilised mudelid on jagunemised ettevõtte funktsionaalsete osakondade, geograafilise asukoha ja rollide järgi ettevõtte infoinfrastruktuuris. Sageli kasutatakse nende mudelite kombinatsioone.

Füüsiline struktuur ja replikatsioon

Füüsiliselt salvestatakse teave ühte või mitmesse samaväärsesse domeenikontrollerisse, mis on asendanud need, mida kasutatakse Windows NT primaarsed ja varudomeenikontrollerid, ehkki nn "üheülema operatsioonide" server, mis suudab emuleerida peamist domeenikontrollerit, jäetakse mõne toimingu jaoks alles. Iga domeenikontroller säilitab andmete lugemise/kirjutamise koopia. Ühel kontrolleril tehtud muudatused sünkroonitakse replikatsiooni ajal kõigi domeenikontrolleritega. Serverid, kus teenus ise Active Directory pole installitud, kuid mis kuuluvad domeeni Active Directory, nimetatakse liikmeserveriteks.

replikatsioon Active Directory teostatakse nõudmisel. Teenindus Teadmiste järjepidevuse kontrollija loob replikatsiooni topoloogia, mis kasutab liikluse haldamiseks süsteemis määratletud saite. Saidisisese replikatsiooni teostab järjepidevuse kontrollija sageli ja automaatselt (teavitades replikatsioonipartnereid muudatustest). Saitidevahelise replikatsiooni saab seadistada saidi iga kanali jaoks (olenevalt kanali kvaliteedist) – igale kanalile saab määrata erineva "tariifi" (või "kulu") (näiteks DS3, , ISDN jne) ning replikatsiooniliiklus on piiratud, ajastatud ja marsruuditud vastavalt määratud lingi hinnangule. Replikatsiooniandmed võivad saidilinkide sildade kaudu transitiivselt liikuda mitme saidi vahel, kui "skoor" on madal, kuigi AD määrab saidivahelistele linkidele automaatselt madalama hinde kui transitiivsetele linkidele. Saitidevahelise replikatsiooni teostavad iga saidi sillapeaserverid, mis seejärel kopeerivad muudatused oma saidi igas domeenikontrolleris. Domeenisisene replikatsioon toimub vastavalt protokollile RPC protokolli IP, domeenidevaheline – saab kasutada ka protokolli SMTP.

Kui struktuur Active Directory sisaldab mitmeid domeene, kasutatakse seda objektide leidmise probleemi lahendamiseks globaalne kataloog: domeenikontroller, mis sisaldab kõiki metsas olevaid objekte, kuid piiratud atribuutide komplektiga (osaline koopia). Kataloog salvestatakse kindlaksmääratud globaalsetes kataloogiserverites ja teenindab domeeniüleseid päringuid.

Ühe hosti võimalus võimaldab taotlusi käsitleda, kui mitme hosti replikatsioon pole lubatud. Selliseid toiminguid on viit tüüpi: domeenikontrolleri emulatsioon (PDC-emulaator), suhtelise identifikaatori host (suhtelise identifikaatori juht või RID-juht), infrastruktuuri host (infrastruktuuri juht), skeemihost (skeemide juht) ja domeeninimede host (domeeninimede juht). ). Esimesed kolm rolli on domeenis ainulaadsed, kaks viimast on ainulaadsed kogu metsas.

alus Active Directory saab jagada kolmeks loogikahoidlaks ehk "partitsiooniks". Skeem on mall Active Directory ja määratleb kõik objektitüübid, nende klassid ja atribuudid, atribuutide süntaksi (kõik puud on samas metsas, kuna neil on sama skeem). Konfiguratsioon on metsa ja puude struktuur Active Directory. Domeen salvestab kogu teabe selles domeenis loodud objektide kohta. Esimesed kaks poodi kopeeritakse kõikidesse metsa domeenikontrolleritesse, kolmas partitsioon kopeeritakse täielikult igas domeenis olevate replikakontrollerite vahel ja osaliselt kopeeritakse globaalsete kataloogiserveritesse.

nimetamine

Active Directory toetab järgmisi objektide nimetamise vorminguid: üldised tüübinimed UNC, URL Ja LDAP URL. Versioon LDAP Sisemiselt kasutatakse nimevormingut X.500 Active Directory.

Igal objektil on eristatav nimi (Inglise) eristatav nimi, DN) . Näiteks printeriobjekt nimega HPLaser3 Marketing OU ja foo.org domeenis on järgmine DN: CN=HPLaser3,OU=Marketing,DC=foo,DC=org , kus CN on üldnimi, OU on jaotis ja DC on domeen objektiklass. Eristavatel nimedel võib olla palju rohkem osi kui selle näite neljal osal. Objektidel on ka kanoonilised nimed. Need on eristavad nimed, mis on kirjutatud vastupidises järjekorras, ilma identifikaatoriteta ja kasutades eraldajatena ettepoole suunatud kaldkriipse: foo.org/Marketing/HPLaser3 . Objekti määratlemiseks selle konteineris kasutage suhteline eristav nimi : CN=HPLaser3 . Igal objektil on ka globaalselt unikaalne identifikaator ( GUID) on ainulaadne ja muutumatu 128-bitine string, mida kasutatakse Active Directory otsimiseks ja paljundamiseks. Teatud objektidel on ka kasutaja põhinimi ( UPN, kooskõlas RFC 822) vormingus objekt@domeen.

Integratsioon UNIXiga

Erinevad suhtlustasandid Active Directory saab rakendada enamikus UNIX- nagu operatsioonisüsteemid standarditele vastavate LDAP kliente, kuid sellised süsteemid ei mõista tavaliselt enamikku komponentidega seotud atribuute Windows nagu grupipoliitika ja ühesuunaliste usaldusfondide tugi.

Kolmanda osapoole müüjad pakuvad integreerimist Active Directory platvormidel UNIX, kaasa arvatud UNIX, Linux, MacOS X ja mitmete rakenduste põhjal Java, koos tootepakendiga:

Kaasasolevad skemaatilised lisandmoodulid Windows Server 2003 R2 sisaldab atribuute, mis on RFC 2307-ga piisavalt tihedalt seotud, et olla üldiselt kasutatavad. Pakutud RFC 2307 baasrakendused nss_ldap ja pam_ldap PADL.com, toetavad neid atribuute otseselt. Grupi liikmelisuse standardskeem järgib RFC 2307bis (pakutud). Windows Server 2003 R2 sisaldab Microsofti halduskonsooli atribuutide loomiseks ja redigeerimiseks.

Alternatiiviks on kasutada mõnda muud kataloogiteenust, näiteks 389 Kataloogiserver(varem Fedora kataloogiserver, FDS), eB2Bcom ViewDS v7.1 XML-i lubatud kataloog või Sun Java süsteemikataloogi server alates Sun Microsystems, mis teostab kahesuunalist sünkroonimist Active Directory, rakendades seega klientidele "peegeldunud" integratsiooni UNIX Ja Linux on autentitud FDS ja kliendid Windows on autentitud Active Directory. Teine võimalus on kasutada OpenLDAP poolläbipaistva ülekatte võimalusega, laiendades kaugserveri elemente LDAP kohalikku andmebaasi salvestatud täiendavad atribuudid.

Active Directory automatiseeritud kasutamine Powershell .

Kirjandus

  • Rand Morimoto, Kenton Gardiner, Michael Noel, Joe Koka Microsoft Exchange Server 2003. Täielik juhend = Microsoft Exchange Server 2003 vallandati. - M .: "Williams", 2006. - S. 1024. - ISBN 0-672-32581-0

Vaata ka

Lingid

Märkmed

Mis aitab Active Directory spetsialistid?

Annan väikese loendi "hüvedest", mida saab hankida Active Directory juurutamisel:

  • ühe kasutaja registreerimise andmebaas, mida hoitakse tsentraalselt ühes või mitmes serveris; seega tuleb uue töötaja kontorisse ilmumisel luua talle serveris vaid konto ja määrata, millistele tööjaamadele ta juurde pääseb;
  • kuna kõik domeeniressursid on indekseeritud, võimaldab see kasutajate lihtsat ja kiiret otsimist; näiteks kui on vaja osakonnast leida värviprinter;
  • NTFS-õiguste rakendamise, rühmapoliitika ja kontrolli delegeerimise kombinatsioon võimaldab teil täpsustada ja jagada õigusi domeeniliikmete vahel;
  • rändluskasutajate profiilid võimaldavad salvestada serverisse olulist teavet ja konfiguratsiooniseadeid; tegelikult, kui domeenis rändlusprofiiliga kasutaja istub teise arvutiga tööle ja sisestab oma kasutajanime ja parooli, näeb ta oma tavapäraste sätetega töölauda;
  • grupipoliitikate abil saate muuta kasutajate operatsioonisüsteemide sätteid, alates kasutajal töölaua taustapildi seadmise lubamisest kuni turvaseadeteni, samuti levitada tarkvara üle võrgu, näiteks Volume Shadow Copy klient jne;
  • paljud programmid (puhverserverid, andmebaasiserverid jne), mida tänapäeval mitte ainult Microsoft ei tooda, on õppinud kasutama domeeni autentimist, nii et te ei pea looma teist kasutajate andmebaasi, vaid saate kasutada olemasolevat;
  • Kauginstallatsiooniteenuste kasutamine hõlbustab süsteemide paigaldamist tööjaamadesse, kuid töötab omakorda ainult sisseehitatud kataloogiteenusega.

Ja see pole täielik funktsioonide loend, kuid sellest lähemalt hiljem. Nüüd püüan rääkida ehitusloogikast Active Directory, aga jällegi tasub uurida, millest on tehtud meie poisid sellest, millest meie poisid on ehitatud Active Directory on domeenid, puud, metsad, organisatsiooniüksused, kasutajad ja arvutirühmad.

Domeenid – See on põhiline loogiline ehitusüksus. Võrreldes töörühmadega AD domeenid on turvarühmad, millel on üks registreerimisbaas, samas kui töörühmad on vaid masinate loogiline rühmitus. AD kasutab nimede andmiseks ja otsinguteenusteks DNS-i (domeeninimeserverit), mitte WINS-i (Windows Internet Name Service), nagu see oli NT varasemate versioonide puhul. Seega on domeeni arvutinimed näiteks buh.work.com, kus buh on domeeni work.com arvuti nimi (kuigi see pole alati nii).

Töörühmad kasutavad NetBIOS-i nimesid. Domeenistruktuuri majutamiseks AD võib-olla kasutate mitte-Microsofti DNS-serverit. Kuid see peab ühilduma versiooniga BIND 8.1.2 või uuemaga ning toetama nii SRV() kirjeid kui ka dünaamilist registreerimisprotokolli (RFC 2136). Igal domeenil on vähemalt üks domeenikontroller, mis majutab keskandmebaasi.

puud - Need on mitme domeeni struktuurid. Selle struktuuri juur on peamine domeen, mille jaoks loote alamdomeene. Tegelikult kasutab Active Directory hierarhilist ehitussüsteemi, mis sarnaneb DNS-i domeenide struktuuriga.

Kui meil on domeen work.com (esimese taseme domeen) ja loome selle jaoks kaks alamdomeeni, first.work.com ja second.work.com (siin on esimene ja teine ​​teise taseme domeen, mitte arvuti domeen, nagu ülalkirjeldatud juhul), siis saame selle tulemusena domeenide puu.

Puud loogilise struktuurina kasutatakse siis, kui on vaja ettevõtte filiaale eraldada näiteks geograafiliste tunnuste järgi või mõnel muul organisatsioonilisel põhjusel.

AD aitab automaatselt luua usaldussuhteid iga domeeni ja selle alamdomeenide vahel.

Seega viib domeeni first.work.com loomine vanema work.com ja lapse first.work.com vahelise kahepoolse usaldussuhte automaatse organiseerimiseni (sarnaselt ka second.work.com puhul). Seetõttu saab õigusi rakendada ülemdomeenilt alamdomeenile ja vastupidi. Pole raske eeldada, et usaldussuhted eksisteerivad ka alamdomeenide puhul.

Teine usaldussuhete omadus on transitiivsus. Saame – domeeni net.first.work.com jaoks luuakse usaldussuhe work.com domeeniga.

Mets - Nii nagu puud, on ka need mitme domeeni struktuurid. Aga metsa on puude liit, millel on erinevad juured.

Oletame, et otsustate omada mitu domeeni nimega work.com ja home.net ning loote neile alamdomeenid, kuid kuna tld (tippdomeen) ei ole teie kontrolli all, saate sellisel juhul korraldada metsa, valides ühe esimestest domeenidest. taseme domeenid on juur. Metsa loomise ilu seisneb antud juhul kahesuunalises usaldussuhtes nende kahe domeeni ja nende alamdomeenide vahel.

Kuid metsade ja puudega töötades pidage meeles järgmist:

  • te ei saa puusse olemasolevat domeeni lisada
  • te ei saa lisada metsa juba olemasolevat puud
  • kui domeenid on paigutatud metsa, ei saa neid teise metsa teisaldada
  • te ei saa kustutada domeeni, millel on alamdomeene

Organisatsiooniüksused - põhimõtteliselt võib neid nimetada alamdomeenideks. võimaldab teil rühmitada domeeni kasutajakontosid, kasutajarühmi, arvuteid, jagatud ressursse, printereid ja muid OU-sid (organisatsiooniüksusi). Nende kasutamise praktiline kasu on võimalus delegeerida õigusi nende üksuste haldamiseks.

Lihtsamalt öeldes on domeenis võimalik määrata administraator, kes saab hallata OU-d, kuid kellel pole õigusi kogu domeeni administreerida.

OU-de oluline omadus, erinevalt rühmadest, on võimalus rakendada neile rühmapoliitikaid. "Miks ei saa algset domeeni OU asemel mitmeks domeeniks jagada?" - te küsite.

Paljud eksperdid soovitavad võimalusel kasutada ühte domeeni. Selle põhjuseks on halduse detsentraliseerimine täiendava domeeni loomisel, kuna iga sellise domeeni administraatorid saavad piiramatu kontrolli (tuletan meelde, et OU administraatoritele õiguste delegeerimisel saate piirata nende funktsionaalsust).

Lisaks sellele vajate uue (isegi alamdomeeni) loomiseks teist kontrollerit. Kui teil on kaks eraldi osakonda, mis on ühendatud aeglase sidekanaliga, võivad tekkida replikatsiooniprobleemid. Sel juhul oleks sobivam omada kahte domeeni.

Grupipoliitikate rakendamisel on ka teine ​​nüanss: paroolisätteid ja konto lukustusi määravaid poliitikaid saab rakendada ainult domeenidele. OU-de puhul neid poliitikaseadeid eiratakse.

saidid – See on viis kataloogiteenuse füüsiliseks eraldamiseks. Definitsiooni järgi on sait arvutite rühm, mis on ühendatud kiirete andmesideühendustega.

Kui teil on riigi eri osades mitu esindust, mis on ühendatud väikese kiirusega sideliinidega, saate luua iga haru jaoks oma veebisaidi. Seda tehakse kataloogide replikatsiooni usaldusväärsuse parandamiseks.

Selline AD partitsioon ei mõjuta loogilise ülesehituse põhimõtteid, mistõttu, nagu sait võib sisaldada mitut domeeni ja vastupidi, võib domeen sisaldada mitut saiti. Kuid see kataloogiteenuse topoloogia on täis konksu. Filiaalidega suhtlemiseks kasutatakse reeglina internetti – väga ebaturvaline keskkond. Paljud ettevõtted kasutavad turvameetmeid, näiteks tulemüüre. Kataloogiteenus kasutab oma töös umbes poolteist tosinat porti ja teenust, mille avamine AD liiklusele tulemüüri läbimiseks paljastab selle tegelikult "väljas". Probleemi lahenduseks on tunnelitehnoloogia kasutamine, samuti domeenikontrolleri olemasolu igal saidil, et kiirendada AD klientide päringute töötlemist.

Esitatakse kataloogiteenuse komponentide pesastamise loogika. Näha on, et mets sisaldab kahte domeenipuud, milles puu juurdomeen võib omakorda sisaldada OU-sid ja objektide rühmi, samuti omada alamdomeene (antud juhul kummalegi üks). Alamdomeenid võivad sisaldada ka objektirühmi ja OU-sid ning neil võivad olla alamdomeenid (joonisel pole neid näidatud). Ja nii edasi. Lubage mul teile meelde tuletada, et OU-d võivad sisaldada OU-sid, objekte ja objektide rühmi ning rühmad võivad sisaldada muid rühmi.

Kasutaja- ja arvutirühmad - kasutatakse halduseesmärkidel ja neil on sama tähendus kui võrgu kohalikes masinates. Erinevalt OU-dest ei saa rühmapoliitikaid rühmadele rakendada, kuid neid saab delegeerida juhtimiseks. Active Directory skeemi raames on kahte tüüpi rühmi: turvarühmad (kasutatakse võrguobjektide juurdepääsuõiguste eristamiseks) ja levirühmad (kasutatakse peamiselt meilisõnumite saatmiseks, näiteks Microsoft Exchange Serveris).

Need liigitatakse nende ulatuse järgi:

  • universaalsed rühmad võivad hõlmata nii metsas olevaid kasutajaid kui ka muid universaalseid rühmi või globaalseid rühmi mis tahes metsa domeenist
  • domeeni globaalsed rühmad võib hõlmata domeeni kasutajaid ja muid sama domeeni globaalseid rühmi
  • domeeni kohalikud rühmad Kasutatakse juurdepääsuõiguste eristamiseks, võib hõlmata domeeni kasutajaid, aga ka universaalseid rühmi ja globaalseid rühmi mis tahes metsas asuvast domeenist
  • kohalikud arvutirühmad– rühmad, mida kohaliku masina SAM (turvakontohaldur) sisaldab. Nende ulatus on piiratud ainult selle masinaga, kuid need võivad hõlmata nii selle domeeni kohalikke rühmi, kus arvuti asub, kui ka nende enda või mõne muu domeeni universaalseid ja globaalseid rühmi, mida nad usaldavad. Näiteks saate kaasata kasutaja domeeni kohalikust rühmast Users kohaliku masina administraatorite gruppi, andes sellega talle administraatoriõigused, kuid ainult selle arvuti jaoks
Artikli hinnang:
1 täht2 tärni3 tärni4 tärni5 tärni(Hinnuseid veel pole)
Laadimine...
Jaga sõpradega:
Seotud artiklid
Sulge
Leia kohapeal
Näiteks: kipsplaatide tüübid