Kohalik domeeninimi. Põhiteave Active Directory domeenide kohta. Domeenikontrolleri lokaatori konfigureerimine Windows XP Professionali ja Windowsi uuemate versioonide jaoks

Kevad on saabunud ja koos sellega ka kõrgendatud soov sünnitada fundamentaalset materjali, mis vastab iseenesestmõistetavana, kuid samas disainimisel kriitilise tähtsusega küsimusele: mis nime anda Active Directory domeenile, et seda ei tekiks. hiljem piinavalt valus?

Selles artiklis püüan juhtida teid Active Directory domeeninime halvimatest valikutest selleni, mis on minu arvates parim valik, osutades ületatavale rehale.

Ühesildise nimega domeen ei sobi tootmiskeskkonnas kasutamiseks ning ainus õige viis on sellest võimalikult kiiresti lahti saada.

Domeeninimes on kehtetud tähemärgid

Näiteks alakriips. Kuigi Windows Serveri varasemad versioonid lubasid seda märki DNS-i domeeninime valimisel, ei vasta see DNS-i RFC 1123 standardile. Windows Serveri uued versioonid ei luba enam domeenidele standardivastaselt nimesid anda. Kui päritakse alakriipsu sisaldava nimega domeen, ootab ees suur häda. Näiteks ei saa te installida Exchange 2007 ja uuemaid versioone. On ainult üks lahendus – vabaneda domeeninime kehtetutest tähemärkidest, migreerides teisele domeenile (soovitav) või nimetades domeeni ümber (ebaturvaline).

Lahtine nimeruum

Üks Disjoint nimeruumi erijuhtudest on olukord, kus domeeni Netbiose nimi erineb domeeni DNS-nime vasakpoolsemast osast.

Netbiose nimi = TEST
DNS nimi = lab.site

Funktsionaalsuse seisukohast on see konfiguratsioon täielikult toetatud. Aga soovitan seda siiski vältida, et mitte tekitada segadust ja ebaselgust.

.kohalik või ICANN

Paljudes õpetustes näete domeeninimesid nagu company.local. Tõepoolest, selliste nimede kasutamine koolituse ja testimise eesmärgil pole kuritegu. See on hullem, kui päris domeenid on nimetatud sama skeemi järgi:

• Nimi on vastuolus globaalse DNS-i ideoloogiaga: see ei garanteeri kokkupõrgete puudumist teiste sarnaste domeenidega (kui on aeg luua usaldussuhteid)
• Seda nime ei saa kasutada globaalsest võrgust juurdepääsuks (kui on aeg avaldada)
• Avalikku SSL-sertifikaati ei saa hankida domeenile, mille omandiõigust ei saa kontrollida. See piirang on eriti oluline pilveteenuste arendamisel, kui piirid kohapealsete ja pilveteenuste vahel on hägused. Lihtsalt näide: ühekordse sisselogimise jaoks Office 365 teenustega töötamiseks on vaja AD Föderatsiooni teenuseid avaliku sertifikaadiga

Seetõttu soovitan domeenile nime andmisel alati kasutada ICANN (Internet Corporation for Assigned Names and Numbers) hierarhias ametlikult registreeritud globaalset nime, mis garanteeritult kõrvaldab ülalkirjeldatud puudused.

veebisait
argon.com.ru
irom.info

Valige või ühendage

Kujutagem ette, et kujundame domeenistruktuuri ettevõttele Argon, millel on aadressisaidil veebisait ja mis kasutab ka samas domeenis olevaid meiliaadresse.? Kuid parem on seda mitte teha järgmistel põhjustel:

• Kui sisestame sellise organisatsiooni võrgus brauserisse aadressi http://site/, siis ei jõua me mitte ettevõtte veebisaidile, vaid esimesele domeenikontrollerile, millega kokku puutume.
• Avalike ja sisemiste DNS-kirjete haldamine on keeruline: kõik saidi tsooni avalikud DNS-kirjed, mida kasutatakse sisevõrgust, peavad olema sisemises DNS-tsoonis dubleeritud. Samuti on vaja kuidagi tagada nende kirjete sünkroniseerimine.

Näiteks Internetis on veebisait www.site. Selleks, et sisevõrgu kasutajad saaksid sellele juurde pääseda, on vaja luua sarnane kirje sisemises DNS-tsoonis

• Võimalikud on kokkupõrked sisemiste ja väliste ressursside nimede vahel.

Näiteks serverit ftp.site kasutatakse laialdaselt sisevõrgus. Järsku tekkis vajadus pakkuda Interneti-kasutajatele failiteenust samal aadressil ftp.site. Mis juhtus? Sisekasutajad ei saa määratud nime kasutades välisteenusega ühendust luua...

Seega on parem, kui Active Directory domeenil on spetsiaalne nimeruum, mis erineb Interneti nimeruumist (ettevõtte veebisait jms). Ja siin on ka valik:

• Kasutage AD jaoks täiesti erinevat nime (sait saidi jaoks, argon.com.ru AD jaoks)
• Kasutage AD jaoks alamnime (sait saidi jaoks, lab.site AD jaoks)

Mõlemad valikud vastavad DNS-i ideoloogiale ja on vabad ülaltoodud puudustest, kuid teine ​​valik alamdomeeniga võib olla mugavam järgmistest vaatenurkadest:

• registreeritud domeeninimede tugi (makse ainult ühe domeeni registreerimise ja DNS-i hostimise eest)
• ilusate nimede olemasolu registreerimiseks (registreerima pole vaja)
• avalike SSL-sertifikaatide hankimine (ainult ühte metamärgisertifikaati saab kasutada nii ettevõtte veebisaidil kui ka sisevõrgu ressursside avaldamisel)

Seega soovitan valida AD jaoks spetsiaalse domeeni, kuid domeeni, mis on organisatsiooni veebisaidi alamdomeen.

lab.site
corp.microsoft.com

Lõhenenud aju

Split-brain DNS tähendab ühe domeeninime kasutamist ressursside avaldamiseks nii sisevõrgus kui ka Internetis. Sel juhul lahendavad sisevõrgu DNS-serverid aadressid (nt portal.lab.site) sisemisteks IP-aadressideks ja avalikud DNS-serverid Internetis vastavalt välisteks IP-aadressideks. Näide:

Tänu split-brainile saavutatakse sellised kasulikud asjad üksikute aadressidena ressurssidele juurdepääsuks nii sisevõrgust kui ka Internetist. Kasutajal on vaja teada ainult ühte aadressi portal.lab.site, mille kaudu ta oma dokumentidele pääseb, ja pole vahet, kus ta asub: ettevõtte kontoris või hotellis.

Infrastruktuuri vaatenurgast on mugav, kui sisemiste CA-de väljastatud SSL-sertifikaatidel on sama aadress CRL-i või OCSP jaoks.

Split-aju puudumisel võib tekkida vajadus luua sisemistes DNS-serverites nn täpsed tsoonid; sellised "täpse" tsoonid sisaldavad ainult neid kirjeid, mille puhul on vaja "avalikud" väärtused asendada "privaatsete" väärtustega. ” sisevõrgule iseloomulikke (olukord, mis sarnaneb rubriigis „Vali või kombineeri“ kirjeldatule).

Täpse tsooni näide:

Täpsustage või tehke kokkuvõte

Kirjandusest leiate nõuandeid domeenide (eriti juure) nimetamiseks üldsõnaga, näiteks pank, ettevõte või korporatsioon. Sellel on oma põhjused, sest tänapäeval võivad ettevõtted regulaarselt kogeda ühinemisi ja ülevõtmisi ning brändimuutusi. Ja nagu teate, on domeeninime muutmine väga keeruline.

Teisalt on samade ettevõtete ühinemiste ja ülevõtmiste puhul väga tõenäoline kasutajate migratsioon ühelt domeenilt teisele. Praktikas puutusin kokku olukorraga, kus oli vaja migreerida kasutajaid kümnekonnast samanimelisest pangast domeenist. Nagu teate, pole usaldussuhete loomine sama nimega domeenide vahel (olgu siis DNS või Netbios) võimalik. Peate need domeenid ümber nimetama või andmed kahes etapis üle viima kolmanda domeeni kaudu.

Kaldun arvama, et parem on nimetada domeen konkreetselt ja taluda vana nime pärast ettevõtte ümbernimetamist, kui nimetada seda üldiselt ja lõppeda tõsiste tehniliste probleemidega, mis puudutavad migratsiooni või usaldussuhete loomist.

Viimane lihv teel täiuslikkuse poole

• ülemaailmselt registreeritud
• pühendatud (ettevõtte veebisaidi domeeni alam)
• spetsiifiline
• kasutada lõhenenud aju

lab.site
corp.microsoft.com

Nagu öeldud, oleks Lyncis parem kasutada e-posti ja SIP-aadresside jaoks lühemaid kasutaja@saidi aadresse. Miski ei takista meid seda tegemast, kuid sellega kaasnevad ebamugavused.

Kasutaja e-posti aadress = kasutaja@sait, sisselogimisnimi = lab\kasutaja, kasutaja põhinimi = [email protected]. Siin on lihtne segadusse sattuda mitte ainult kasutajal, vaid ka sellistel programmidel nagu Outlook ja Lync.

Pärast väiksemaid konto muudatusi saavad kasutajad kasutaja põhinime, mis on võrdne nende e-posti aadressiga. Segadust on vähem ning sellised programmid nagu Lync ja Outlook lõpetavad kasutaja sisselogimise küsimise; piisab, kui nad teavad e-posti või SIP-aadressi.

Minu põhitööd:

Artiklid muude ressursside kohta:

• Active Directory domeeninimede määramise kaalutlused – siin on Microsofti kuiv juhend
• Active Directory arvutite, domeenide, saitide ja OU-de nimetamise kokkulepped – vt alajaotist Metsad, mis on Internetiga ühendatud
• Miks te ei peaks oma Active Directory domeeninimes kasutama .local - sarnane artikkel välismaiselt kolleegilt

Eile saime oma stuudiosse kirja meie püsilugejalt Andreilt küsimusega:

Lugesin teie ajaveebi mõnuga, õppisin enda jaoks palju kasulikku, tahtsin teada teie arvamust Active Directory domeeni nime kohta, paljud kirjutavad, et selle nimi peaks olema *organisatsioon*.local ja keegi kirjutab, et see tuleks nimetada samaks mis domeeni.

Vaatame lühidalt, millist nime on kõige parem kasutada organisatsioonisisese domeeninime andmisel.

Nagu praktika näitab, võib domeeninime valimine isegi kogenud süsteemiadministraatorile hämmingut tekitada. Utiliidi esmakordsel käivitamisel dcpromo Domeeninimi genereeritakse automaatselt ja juhuslikult, kui selles etapis domeeninime ei viida vastavusse vajalike reeglitega, on edaspidi domeeninime muutmine keerulisem. Vaatame võimalikke valikuid populaarsuse järjekorras.

1. Domeen nimega näide.kohalik

Meie hitiparaadi liider on domeeninimi, mis lõpeb tähega kohalik. Sellel teemal on näiteks muid variatsioone katsetada, firma, tehas, nn, loc, ja nii edasi. Tänapäeval ei mäletagi enam, kust selline armastus tuli; Microsoft kasutab kõigis oma raamatutes alati oma nimesid, näiteks contoso.com kus me selgelt näeme domeeninime vorming. Siiski peaaegu 10 aastat domeeni .kohalik hõivas juhtiva positsiooni. Olukord hakkas paranema koos kasutavate teenuste saabumisega SSL-sertifikaadid. Kui domeenide "ei hooli" kasutamine muutub võimatuks. Oletame, et teie ettevõte kasutab sisemiselt Exchange'i server, mis nõuab kliendiühenduste krüptimiseks SSL-sertifikaati. Teie stsenaariumi kohaselt on teil selle ülesande täitmiseks vaja sertifikaati väline sertifitseerimisasutus, milles peate määrama kõik väliste ühenduste jaoks kasutatavate serverite nimed. Tundub, et mis viga, paneme kõik serverinimed kirja ja taotleme sertifikaatide väljastamist, aga üks asi on. Sellise domeeni nimega te ei saa valideerimist läbida, kuna domeeni "ei hooli" pole olemas ja kui proovite välisele sertifitseerimisasutusele selgitada, et peate SAN-i sisestama olematu domeeni FQDN-nime, saate pehme keeldumise:

See pole võimalik, me väljastame ainult tõelisi domeeninimesid.

Kuid on veel üks probleem. Domeeninime kasutamine mitte sinu oma domeeninimes võib kaasa tuua katastroofilisi tagajärgi. Kujutage ette olukorda, kui tsoon kohalik saab avaliku staatuse. Nagu tsoon com või ru. Ma arvan, et pole mõtet enam jätkata :)

2. Domeeninimi on sama mis välise domeeninimi

Meie hitiparaadi teine ​​koht. Hoolimata asjaolust, et selline stsenaarium on vähem populaarne, on sellel siiski õigus elule. Peale selle, et lähitulevikus kogete võrgu hooldamisel siiski mõningaid ebamugavusi, ei ähvarda teid miski muu. Selle stsenaariumi peamine probleem on see, et peate hooldama kahte DNS-serverit: sisemine ja välimine. Selle tingimuse korral kasutavad võrgus asuvad arvutid nimede lahendamiseks sisemist DNS-serverit ja väljaspool ettevõtte perimeetrit asuvad arvutid välist. Oletame, et teie domeenil on uhke nimi example.com. IN DMZ tsoonis sa oled veebisait firma nimega example.com. Ülalkirjeldatud stsenaariumi korral asuvad arvutid sees organisatsioonid nad ei saagi juurdepääs sellele, kuna nende jaoks on example.com domeeninimi ja kui sisestate selle aadressi brauserisse, siis nad lähevad domeenikontroller. Nagu ma eespool märkisin, ei too see kaasa midagi peale ebamugavuste. Võite alati kasutada karkusid, mis suunavad teid välisele saidile, kuid nõustute, et see on tarbetu topelttöö või kasutage võrgus saidi nime, mis algab www, või väljas.

3. Ühesõnaline domeeninimi

Võib-olla kõige ebaõigem variant ülaltoodust. Ühetasandilised domeenid: Ühe sildiga domeen on domeen, mis sisaldab ainult üks komponent. Ilmselt hakati neid kasutama NT päevil, kui Microsoft võttis kasutusele Novelli eduka kogemuse. Juhtus nii, et algselt olin FreeBSD ja suure NetWare serveripargi administraator alates versioonist 4.11 ja nii kasutas NetWare neil iidsetel aegadel oma töös Binderyt, mis on just nimelt nimed. ühetasandilise domeeni diagramm, mille Microsoft hiljem vastu võttis.

Parimad tavad

On aeg see kokku võtta. Millist domeeninime peaksin kasutama? Ainult kolmanda taseme domeen teile kuuluvas domeenis. Teiste ilusamaid domeeninimesid ei tasu kasutada :-). Sellise domeeni näidet näete allpool.

Lühidalt, AD võimaldab teil kõigi avaldatud ressursside jaoks kasutada ühte halduspunkti. AD põhineb X.500 nimetamisstandardil, kasutab asukoha määramiseks domeeninimede süsteemi (DNS) ja kasutab peamise protokollina LDAP-protokolli (Lightweight Directory Access Protocol).

AD ühendab võrgu loogilise ja füüsilise struktuuri. AD loogiline struktuur koosneb järgmistest elementidest:

• organisatsiooniline üksus – arvutite alamrühm, mis tavaliselt peegeldab ettevõtte struktuuri;
• domeeni – arvutite rühm, millel on ühine kataloogide andmebaas;
• domeenipuu – üks või mitu külgnevat nimeruumi jagavat domeeni;
• domeeni mets – üks või mitu puud, mis jagavad kataloogi teavet.

Füüsiline struktuur sisaldab järgmisi elemente:

• alamvõrk – määratud IP-aadressi ala ja võrgumaskiga võrgugrupp;
• saidile – üks või mitu alamvõrku. Saiti kasutatakse kataloogile juurdepääsu konfigureerimiseks ja replikatsiooniks.

Kataloog salvestab kolme tüüpi teavet: domeeniandmed, skeemiandmed ja konfiguratsiooniandmed. AD kasutab ainult domeenikontrollereid. Domeeniandmed kopeeritakse kõikidesse domeenikontrolleritesse. Kõigil domeenikontrolleritel on võrdsed õigused, s.t. kõik domeenikontrollerilt tehtud muudatused kopeeritakse kõikidesse teistesse domeenikontrolleritesse. Skeem ja konfiguratsiooniandmed kopeeritakse kõigis puu või metsa domeenides. Lisaks kopeeritakse kõik üksikud domeeniobjektid ja mõned metsaobjekti atribuudid globaalsesse kataloogi (GC). See tähendab, et domeenikontroller salvestab ja kopeerib puu või metsa skeemi, puu või metsa kõigi domeenide konfiguratsiooniteavet ning kõik kataloogiobjektid ja atribuudid oma domeeni jaoks.

Domeenikontroller, kuhu GC on salvestatud, sisaldab ja kordab metsa skeemiteavet, metsa kõigi domeenide konfiguratsiooniteavet ja piiratud hulga atribuute kõigi metsa kataloogiobjektide jaoks (mida kopeeritakse ainult GC serverite vahel), ja kõik teie domeeni kataloogiobjektid ja atribuudid.

Domeenikontrolleritel võivad olla erinevad operatsioonide juhtrollid. Toimingute juht haldab ülesandeid, mida on mitmest ülemast koosnevas replikatsioonimudelis ebamugav täita.

Ühele või mitmele domeenikontrollerile saab määrata viis operatsioonide pearolli. Mõned rollid peavad olema ainulaadsed metsa, teised domeeni tasemel.

Igas AD metsas on järgmised rollid:

• Skeemimeister – Haldab kataloogiskeemi värskendusi ja muudatusi. Kataloogiskeemi värskendamiseks peab teil olema juurdepääs skeemile. Et teha kindlaks, milline server on praegu domeenis oleva skeemi omanik, peate käsurea aknasse tippima käsu dsquery server -hasfsmo skeem
• Domeeninimede meister – haldab metsas domeenide lisamist ja eemaldamist. Domeeni lisamiseks või eemaldamiseks on teil vaja juurdepääsu domeeninimede ülemale. Et teha kindlaks, milline server on praegu domeeninime määramise juht, sisestage käsuviiba aknasse dsquery server -hasmo name

Need rollid on ühised kogu metsale tervikuna ja on omased.

Igal AD domeenil peavad olema järgmised rollid:

• Suhteline ID-meister – eraldab domeenikontrolleritele suhtelised identifikaatorid. Iga kord, kui kasutaja, rühm või arvutiobjekt luuakse, määravad kontrollerid objektile kordumatu turbeidentifikaatori, mis koosneb domeeni turbeidentifikaatorist ja kordumatust identifikaatorist, mille on eraldanud suhtelise identifikaatori ülem. Et määrata, milline server on praegu suhteliste domeeni ID-de juht, sisestage käsureale dsquery server -hasfsmo rid
• PDC emulaator – Sega- või vahedomeenirežiimis toimib Windows NT peadomeenikontrollerina. See autentib Windowsi sisselogimisi, haldab paroolimuutusi ja kopeerib BDC värskendusi, kui neid on. Et määrata, milline server on praegu domeeni PDC emulaator, sisestage käsureale dsquery server -hasfsmo pdc
• Taristumeister – värskendab objekti linke, võrreldes oma kataloogiandmeid GC andmetega. Kui andmed on aegunud, taotleb see värskendusi GC-lt ja kopeerib need ülejäänud domeenikontrolleritele. Et määrata, milline server on praegu domeeni infrastruktuuri peremees, sisestage käsureale dsquery server -hasfsmo infr

Need rollid on kogu domeeni jaoks ühised ja peavad olema selles ainulaadsed.

Toimingute pearollid määratakse automaatselt domeeni esimesele kontrollerile, kuid saate need hiljem ümber määrata. Kui domeenis on ainult üks kontroller, täidab see kõiki operatsioone korraga.

Ei ole soovitatav eraldada skeemide juht ja domeeninimede ülem rolle. Võimalusel määrake need samale domeenikontrollerile. Maksimaalse efektiivsuse saavutamiseks on soovitav, et suhteline ID-juht ja PDC-emulaator oleksid samuti samal kontrolleril, kuigi neid rolle saab vajadusel eraldada. Suures võrgus, kus suured koormused vähendavad jõudlust, tuleks suhtelise ID-juht ja PDC-emulaator paigutada erinevatele kontrolleritele. Lisaks ei ole soovitatav majutada infrastruktuuri juhtseadet domeenikontrolleris, mis salvestab globaalset kataloogi.

Windows Server 2003-põhise domeenikontrolleri (DC) installimine Active Directory häälestusviisardi abil

Domeenikontroller installitakse Active Directory installiviisardi abil. Serveri domeenikontrolleriks üleviimiseks peate tagama, et kõik vajalikud nõuded on täidetud:

1. Serveril peab olema vähemalt üks NTFS-i partitsioon, et mahutada süsteemi SYSVOL.
2. Serveril peab olema juurdepääs DNS-serverile. Soovitatav on installida DNS-teenus samasse serverisse. Kui kasutatakse eraldi serverit, peate tagama, et see toetab teenuse asukoha ressursikirjeid (RFC 2052) ja dünaamiliste värskenduste protokolli (RFC 2136).
3. Teil peab olema serveris kohaliku administraatori õigustega konto.

Vaatame üksikasjalikumalt serveri rolli edendamist Active Directory domeenikontrollerile samm-sammult:

Active Directory domeenihalduse põhitõed

Mitmed Microsofti halduskonsooli (MMC) lisandmooduli tööriistad muudavad Active Directoryga töötamise lihtsamaks.

Active Directory kasutajate ja arvutite lisandmoodul on MMC, mida saate kasutada kataloogiteabe haldamiseks ja avaldamiseks. See on Active Directory peamine haldustööriist ja seda kasutatakse kõigi kasutajate, rühmade ja arvutitega seotud ülesannete täitmiseks, samuti organisatsiooniüksuste haldamiseks.

Lisandmooduli (Active Directory kasutajad ja arvutid) käivitamiseks valige haldustööriistade menüüst samanimeline käsk.

Vaikimisi töötab Active Directory kasutajate ja arvutite konsool domeeniga, kuhu teie arvuti kuulub. Selle domeeni arvuti- ja kasutajaobjektidele pääsete juurde konsoolipuu kaudu või looge ühenduse mõne teise domeeniga. Sama konsooli tööriistad võimaldavad vaadata täiendavaid objekti parameetreid ja neid otsida.

Pärast domeenile juurdepääsu saamist näete standardset kaustade komplekti:

• Salvestatud päringud (Salvestatud päringud) – salvestatud otsingukriteeriumid, mis võimaldavad kiirelt korrata varem tehtud otsingut Active Directorys;
• sisseehitatud – sisseehitatud kasutajakontode loend;
• Arvutid – arvutikontode vaikekonteiner;
• Domeenikontrollerid – domeenikontrollerite vaikekonteiner;
• Välisjulgeolekujuhid – sisaldab teavet usaldusväärse välisdomeeni objektide kohta. Tavaliselt luuakse need objektid siis, kui praegusesse domeenirühma lisatakse objekt välisest domeenist;
• Kasutajad – kasutajate vaikemahuti.

Mõnda konsoolikausta vaikimisi ei kuvata. Nende kuvamiseks valige menüüst Vaade valik Täpsemad funktsioonid. Need on täiendavad kaustad:

• Leiunurk – kadunud omanik, kataloogiobjektid;
• NTDS-kvoodid – andmed kataloogiteenuste kvootide kohta;
• Programmi andmed – Microsofti rakenduste kataloogiteenuses salvestatud andmed;
• Süsteem - sisseehitatud süsteemi parameetrid.

Saate iseseisvalt lisada AD-puusse organisatsiooniüksuste kaustu.

Vaatame näidet domeeni kasutajakonto loomisest. Kasutajakonto loomiseks paremklõpsake konteinerit, kuhu soovite kasutajakonto paigutada, valige kontekstimenüüst Uus ja seejärel valige Kasutaja. Avaneb aken Uus objekt – kasutaja viisard:

1. Sisestage vastavatele väljadele kasutaja eesnimi, initsiaal ja perekonnanimi. Seda teavet vajate oma kasutaja kuvatava nime loomiseks.
2. Muutke oma täisnime. See peab olema domeenis ainulaadne ega tohi olla pikem kui 64 tähemärki.
3. Sisestage oma sisselogimisnimi. Kasutage ripploendit, et valida domeen, millega konto seostatakse.
4. Vajadusel muutke oma sisselogimise kasutajanime süsteemides, kus töötab Windows NT 4.0 või varasem. Vaikimisi kasutatakse Windowsi eelmisi versioone kasutavate süsteemide sisselogimisnimena kasutaja täisnime 20 esimest tähemärki. See nimi peab olema ka domeenis kordumatu.
5. Klõpsake Edasi. Andke kasutajale parool. Selle seaded peaksid vastama teie paroolipoliitikale;
   Confirm Password – väli, mida kasutatakse sisestatud parooli õigsuse kinnitamiseks;
   Kasutaja peab järgmisel sisselogimisel parooli muutma(Nõua järgmisel sisselogimisel parooli muutmine) – kui see ruut on märgitud, peab kasutaja järgmisel sisselogimisel parooli muutma;
   Kasutaja ei saa parooli muuta – kui see ruut on märgitud, ei saa kasutaja parooli muuta;
   Parool ei aegu kunagi – kui see märkeruut on märgitud, ei aegu selle konto parool kunagi (see säte alistab domeeni kontoreeglid);
   Konto on keelatud – kui see märkeruut on märgitud, on konto keelatud (see valik on kasulik kellegi konto kasutamise ajutiseks keelamiseks).

Kontod võimaldavad salvestada kasutajate kontaktandmeid, samuti teavet erinevates domeenigruppides osalemise kohta, profiilitee, sisselogimisskript, kodukausta tee, arvutite loend, kust kasutajal on lubatud domeeni sisse logida jne.

Sisselogimisskriptid määratlevad käsud, mis käivitatakse iga kord, kui süsteemi sisse logite. Need võimaldavad teil konfigureerida süsteemi aega, võrguprintereid, võrgudraivide teid jne. Skripte kasutatakse käskude ühekordseks käivitamiseks ja skriptide määratud keskkonnasätteid hilisemaks kasutamiseks ei salvestata. Sisselogimisskriptid võivad olla Windowsi skriptiserveri failid laiendiga .VBS, .JS ja teised, pakkfailid laiendiga .BAT, pakkfailid laiendiga .CMD, programmid laiendiga .EXE.

Saate määrata igale kontole oma kodukausta kasutajafailide salvestamiseks ja taastamiseks. Enamik rakendusi avab failide avamiseks ja salvestamiseks vaikimisi kodukausta, muutes kasutajatel oma andmete leidmise lihtsamaks. Käsureal on kodukaust praegune alguskataloog. Kodukaust võib asuda kas kasutaja kohalikul kõvakettal või jagatud võrgukettal.

Grupipoliitikaid saab rakendada domeeniarvutitele ja kasutajakontodele. Rühmapoliitika lihtsustab haldust, andes administraatoritele tsentraliseeritud kontrolli kasutajate ja arvutite õiguste, õiguste ja võimaluste üle. Grupipoliitika võimaldab teil:

• luua keskselt hallatavaid spetsiaalseid kaustu, näiteks Minu dokumendid;
• juhtida juurdepääsu Windowsi komponentidele, süsteemi- ja võrguressurssidele, juhtpaneeli tööriistadele, töölauale ja menüüle Start;
• seadistada kasutaja ja arvuti skripte ülesande täitmiseks määratud ajal;
• Konfigureerige paroolide ja konto lukustamise, auditeerimise, kasutajaõiguste määramise ja turvalisuse eeskirju.

Lisaks kasutajakontode ja gruppide haldamise ülesannetele on palju muid domeenihaldusülesandeid. Muud tööriistad ja rakendused teenivad seda eesmärki.

Varustus Active Directory domeenid ja usaldusfondid(Active Directory – domeenid ja usaldus) kasutatakse domeenide, domeenipuude ja domeenimetsadega töötamiseks.

Varustus Active Directory saidid ja teenused(Active Directory – saidid ja teenused) võimaldab hallata saite ja alamvõrke ning ka saitidevahelist replikatsiooni.

AD-objektide haldamiseks on käsureatööriistad, mis võimaldavad teil täita mitmesuguseid haldusülesandeid.

• Dsadd – lisab Active Directorysse arvutid, kontaktid, rühmad, organisatsiooniüksused ja kasutajad. Abiteabe saamiseks tippige dsadd /? , näiteks dsadd arvuti/?
• Dsmod – muudab Active Directorysse registreeritud arvutite, kontaktide, rühmade, organisatsiooniüksuste, kasutajate ja serverite atribuute. Abiteabe saamiseks tippige dsmod /? , näiteks dsmod server /?
• Dsmove – Teisaldab üksiku objekti domeenis uude asukohta või nimetab objekti ümber ilma seda liigutamata.
• Dsget – Kuvab Active Directorysse registreeritud arvutite, kontaktide, rühmade, organisatsiooniüksuste, kasutajate, saitide, alamvõrkude ja serverite atribuudid. Abiteabe saamiseks tippige dsget /? , näiteks dsget subnet /?
• Dquery – otsib Active Directory'st arvuteid, kontakte, rühmi, organisatsiooniüksusi, kasutajaid, saite, alamvõrke ja servereid vastavalt määratud kriteeriumidele.
• Dsrm – kustutab objekti Active Directoryst.
• Ntdsutil – võimaldab teil vaadata teavet saidi, domeeni või serveri kohta, hallata operatsioonide juhtfaile ja hallata Active Directory andmebaasi.

Samuti on olemas Active Directory tugitööriistad:

• LDP – Teostab toiminguid, kasutades Active Directory halduses LDAP-protokolli.
• Replymon – Haldab replikatsiooni ja kuvab selle tulemused graafilises liideses.
• Dsacls – Haldab Active Directory objektide ACL-e (juurdepääsuloendeid).
• Dfsutil – Haldab hajutatud failisüsteemi (DFS) ja kuvab teavet selle toimimise kohta.
• Dnscmd – Haldab serverite, tsoonide ja DNS-ressursside kirjete atribuute.
• Movetree – Teisaldab objekte ühest domeenist teise.
• Repadmin – Haldab replikatsiooni ja kuvab selle tulemused käsurea aknas.
• Sdcbeck – Analüüsib juurdepääsukontrolli loendite levitamist, replikatsiooni ja pärimist.
• Sidwalker – Määrab ACL-id objektidele, mis on ajalooliselt kuulunud teisaldatud, kustutatud või orvuks jäänud kontodele.
• Netdom – Võimaldab hallata domeene ja usaldussuhteid käsurealt.

Nagu sellest artiklist näha, võib arvutirühmade ühendamine Active Directory alusel domeenideks vähendada oluliselt haldusülesannete kulusid, tsentraliseerides domeeniarvutite ja kasutajakontode haldamise, ning võimaldab ka paindlikult hallata kasutajaõigusi, turvalisust ja hulk muid parameetreid. Täpsemad materjalid domeenide korraldamise kohta leiate vastavast kirjandusest.

Domeeninime valimine pole keeruline ülesanne, kuid nagu elu näitab, tekib üsna sageli pärast dcpromo käivitamist domeeninimi juhuslikult. Tundub, et sellel pole midagi viga, domeen töötab, printerid prindivad, 1C avaneb. Kuid paraku on mitmeid olukordi, kus nime juhuslik loomine, kui see teile ei sobi, lisab kindlasti probleeme. Selles lühikeses postituses püüan rääkida sellest, mida oma domeenidele mitte nimetada ja miks. Kuigi teave on üldteada, näitab tegelik elu, et nimetamisvead on lihtsalt endeemilised. Ja kuna domeeni ümbernimetamise protseduur on IT-sadomaso, on parem teha kõike algusest peale õigesti.

1. Olukord üks. Domeeninimi – domeeninimi.kohalik

Tõenäoliselt on kõige levinum võimalus kasutada lõppu .local või mõnda muud tippdomeeni, mida IANA ei kasuta. (a la.msk või.test or.loc jne) Kust see tuli, on praegu raske öelda, valikuid on mitu. Üks ütleb, et 2000. aastal, kui AD esines konverentsil meeleavaldusel, tegi kõneleja sellise domeeni.
Noh, inimesed võtsid seda kui üleskutset tegutseda. Teine hüpotees, kuigi ei välista esimest, kaldub sellele, et suure tõenäosusega kirjutas MSFT ise kirjanduses selgelt soovituse, mille järel .local läks rahvale. Miks see valik halb on?

Stsenaariume on mitu, kuid ma räägin teile kõige valusamatest. Oletame, et installite oma organisatsiooni Exchange Serveri, mis nõuab kliendiühenduste krüptimiseks sertifikaati. Soovin sertifikaati kaubanduskeskusest, kõik on nagu inimestega. Loomulikult peab sertifikaat näitama kõiki serverite nimesid, mille kaudu server on juurdepääsetav. Ja kui väline domeen kuulub meile ja saab hõlpsasti valideerimise läbida, siis sisemist domeeni a la super-firma.moscow ei eksisteeri ja kui proovite sertifitseerimisasutustele selgitada, et peate FQDN SAN-i toppima - Exchange .super-firma.moscow saate vastuse:

See pole võimalik, me väljastame ainult tõelisi domeeninimesid.

Hetkel lubab Comodo sertifitseerimiskeskus sertifikaadi SAN-i toppida kõikvõimalikke ebatsensuurseid sõnu, mis kitsendab oluliselt sertifikaadipakkuja valikut ja pole mingit garantiid, et nad seda ka tulevikus lubavad.

2. Olukord kaks. AD domeeninimi on sama, mis väline Interneti-domeeni nimi.

See on samuti levinud variant, kuid sertifikaatidega probleeme ei teki. Kuid nimede lahendamisega on probleeme. Selle tulemuseks on olukord, kus välised ja sisemised DNS-serverid ei ole omavahel ühendatud, vaid teenindavad samal ajal samade nimedega mitteseotud tsoone. Sellises olukorras peab iga siseserver end loogiliselt tsooni jaoks autoriteetseks ja kui ta ei tea ühestki hostist, teatab autoriteetselt – EI! Kuna teil on mõned välised ressursid, kõige tavalisemad veebisaidid, lisatakse välise DNS-serveri tsooni loomulikult A-tüüpi kirjed. Nüüd, kui siseklient proovib lahendada välise ressursi nime, läheb tema päring sisemisele DNS-serverile (loomulikult on see domeeni klient) ja see vastab "Ma ei tea, sellist pole olemas asi ja te ei pea seda otsima", sest see näeb, et see on selle tsooni jaoks autoriteetne server.

Selle probleemi lahendamiseks peate registreerima välised kirjed kahes tsoonis ja see toob paratamatult kaasa segaduse ja täiendava rutiini. Kui see teid ei häiri, proovige selle stsenaariumi korral lubada sisekasutajatel avada ettevõtte veebisait ilma www-eesliiteta. Üldiselt on see halb valik ja seda ei tohiks kasutada.

Erilised tervitused administraatoritele, kes panid oma sisedomeenile nimed teiste inimeste kuulsate avalike domeenide järgi. Ma arvan, et te ei pea sel juhul selgitama, millised hemorroidid teil on.

3. Olukord kolm. Lame domeeninimi, mis koosneb ühest sõnast.

Kui kaks esimest võimalust on veel üle elatud, siis on aeg kehtestada halduskaristused lamedate domeeninimede eest. Single-label domeen (single-level domain, SLD) on domeen, mis sisaldab ainult ühte nominaalset komponenti. Ma ei tea, kust tuli nende kasutamise maania, aga juba ammu on ametlikult tunnustatud, et IT-infrastruktuuride ehitamisel ei tohi SLD domeene kasutada.

Samas on see info selline Kanada akordion, et jääb üle vaid imestada, kust SLD domeenid pärit on. http://support.microsoft.com/kb/300684.

Mis on oht? Microsofti toodete toe puudumine selle konfiguratsiooni jaoks. Värskest. Proovige installida Exchange 2010 hoolduspakett SP1 kindla nimega domeenile ja saate teate, et seda konfiguratsiooni enam ei toetata.

Kuidas domeenile õigesti nime anda?

Vastus on lihtne. Looge ühtne nimeruum. See tähendab, et kui teil on reaalses maailmas saidi domeen, muutke Active Directory domeen alamdomeeniks nagu corp.site. Sellises olukorras kaovad kõik probleemid. Ja alamdomeeni DNS-i delegeerimine välisele DNS-serverile pole üldse vajalik. Kuigi kui teete seda, saate nimede eraldusvõimet mõlemal viisil. (välisnimede sisevõrgust, sisenimede Internetist)

Neile, kes esialgu ei arvanud, et on olemas "hea" link: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx Ilusat õhtut selle töö lugemiseks.

MCP/MCT Ilja Rud