Vietējais domēna nosaukums. Pamatinformācija par Active Directory domēniem. Domēna kontrollera lokatora konfigurēšana operētājsistēmai Windows XP Professional un jaunākām Windows versijām

Ir atnācis pavasaris un līdz ar to pastiprināta vēlme radīt fundamentālu materiālu, kas atbild uz jautājumu, kas šķiet pašsaprotams, bet tajā pašā laikā ir ļoti svarīgs projektēšanas laikā: kādu nosaukumu dot Active Directory domēnam, lai tas vairs nebūtu. neciešami sāpīgi vēlāk?

Šajā rakstā es centīšos jūs novirzīt no sliktākajām Active Directory domēna vārda opcijām līdz, manuprāt, vislabākajam variantam, norādot uz pārvaramajām grūtībām.

Domēns ar vienas etiķetes nosaukumu nav piemērots lietošanai ražošanas vidē, un vienīgais pareizais veids ir pēc iespējas ātrāk no tā atbrīvoties.

Domēna nosaukumā nav derīgas rakstzīmes

Piemēram, pasvītrojums. Lai gan iepriekšējās Windows Server versijās šī rakstzīme tika atļauta, izvēloties DNS domēna nosaukumu, tā neatbilst RFC 1123 standartam DNS. Jaunās Windows Server versijas vairs neļauj nosaukt domēnus pretēji standartam. Ja domēns ar nosaukumu, kurā ir pasvītrojums, tika mantots, gaida lielas problēmas. Piemēram, jūs nevarat instalēt Exchange 2007 un jaunākas versijas. Ir tikai viens risinājums - atbrīvoties no nederīgām rakstzīmēm domēna nosaukumā, migrējot uz citu domēnu (vēlams), vai pārdēvējot domēnu (nedroši).

Atdalīta nosaukumvieta

Viens no īpašajiem Disjoint nosaukumvietas gadījumiem ir situācija, kad domēna Netbios nosaukums atšķiras no domēna DNS nosaukuma kreisās daļas.

Netbios nosaukums = TESTS
DNS nosaukums = lab.site

No funkcionalitātes viedokļa šī konfigurācija tiek pilnībā atbalstīta. Bet tomēr iesaku no tā izvairīties, lai neradītu neskaidrības un neskaidrības.

.vietējais vai ICANN

Daudzās apmācībās varat redzēt domēna nosaukumus, piemēram, company.local. Patiešām, šādu nosaukumu izmantošana apmācības un pārbaudes nolūkos nav nekāda nozieguma. Sliktāk ir, ja reālie domēni tiek nosaukti, izmantojot to pašu shēmu:

• Nosaukums ir pretrunā ar globālā DNS ideoloģiju: tas negarantē sadursmju neesamību ar citiem līdzīgiem domēniem (kad ir pienācis laiks izveidot uzticības attiecības)
• Šo nosaukumu nav iespējams izmantot piekļuvei no globālā tīkla (kad ir pienācis laiks publicēt)
• Publisku SSL sertifikātu nevar iegūt domēnam, kura īpašumtiesības nevar pārbaudīt. Šis ierobežojums ir īpaši aktuāls mākoņpakalpojumu attīstībā, kad robežas starp lokālajiem un mākoņpakalpojumiem ir izplūdušas. Tikai piemērs: lai vienotā pierakstīšanās darbotos ar Office 365 pakalpojumiem, ir nepieciešami AD Federācijas pakalpojumi ar publisku sertifikātu.

Tāpēc iesaku, piešķirot domēnam nosaukumu, vienmēr izmantot ICANN (Internet Corporation for Assigned Names and Numbers) hierarhijā oficiāli reģistrētu globālo nosaukumu, kas garantēti novērsīs iepriekš aprakstītos trūkumus.

tīmekļa vietne
argon.com.ru
irom.info

Atlasiet vai apvienojiet

Iedomāsimies, ka mēs izstrādājam domēna struktūru uzņēmumam Argon, kuram adreses vietnē ir vietne un kas izmanto arī e-pasta adreses tajā pašā domēnā.? Bet labāk to nedarīt šādu iemeslu dēļ:

• Ja šādas organizācijas tīklā pārlūkprogrammā ievadām adresi http://site/, tad nenokļūsim uzņēmuma mājaslapā, bet gan pie pirmā domēna kontrollera, ar kuru saskaramies.
• Publisko un iekšējo DNS ierakstu administrēšana ir sarežģīta: visi publiskie DNS ieraksti vietnes zonā, kas tiek izmantoti no iekšējā tīkla, ir jādublē iekšējā DNS zonā. Ir arī kaut kā jānodrošina šo ierakstu sinhronizācija.

Piemēram, internetā ir vietne www.site. Lai lietotāji no iekšējā tīkla varētu tam piekļūt, ir nepieciešams izveidot līdzīgu ierakstu iekšējā DNS zonā

• Pastāv sadursmes starp iekšējo un ārējo resursu nosaukumiem.

Piemēram, serveris ftp.site tiek plaši izmantots iekšējā tīklā. Pēkšņi radās nepieciešamība interneta lietotājiem nodrošināt failu pakalpojumu tajā pašā adresē ftp.site. Kas notika? Iekšējie lietotāji nevar izveidot savienojumu ar ārējo pakalpojumu, izmantojot norādīto nosaukumu...

Tādējādi Active Directory domēnam labāk ir izveidot īpašu nosaukumvietu, kas atšķiras no nosaukumvietas internetā (uzņēmuma vietne un tamlīdzīgi). Un arī šeit ir izvēle:

• Izmantojiet pilnīgi citu nosaukumu AD (vietne vietnei, argon.com.ru AD)
• Izmantojiet vietni AD (vietne vietnei, lab.site AD)

Abas opcijas atbilst DNS ideoloģijai un ir bez iepriekš minētajiem trūkumiem, taču otrā iespēja ar bērnu domēnu var būt ērtāka no šādiem viedokļiem:

• reģistrētu domēna vārdu atbalsts (maksa tikai par viena domēna reģistrāciju un DNS mitināšanu)
• skaistu vārdu pieejamība reģistrācijai (nav nepieciešams reģistrēties)
• publisko SSL sertifikātu iegūšana (var izmantot tikai vienu aizstājējzīmes sertifikātu gan uzņēmuma vietnei, gan publicējot iekšējā tīkla resursus)

Tāpēc es iesaku izvēlēties AD īpašu domēnu, bet domēnu, kas ir organizācijas vietnes atvasinātais domēns.

lab.site
corp.microsoft.com

Sašķeltās smadzenes

Split-brain DNS nozīmē viena domēna vārda izmantošanu, lai publicētu resursus gan iekšējā tīklā, gan internetā. Šajā gadījumā DNS serveri iekšējā tīklā atdala adreses, piemēram, portal.lab.site, par iekšējām IP adresēm un publiskos DNS serverus internetā, attiecīgi, ārējos IP. Piemērs:

Pateicoties split-brain, tik noderīgas lietas tiek panāktas kā vienas adreses, lai piekļūtu resursiem gan no iekšējā tīkla, gan no interneta. Lietotājam ir jāzina tikai viena adrese portal.lab.site, caur kuru viņš var piekļūt saviem dokumentiem, un nav svarīgi, kur viņš atrodas: uzņēmuma birojā vai viesnīcā.

No infrastruktūras viedokļa ir ērti, ja SSL sertifikātos, ko izsniedz iekšējās CA, ir viena CRL vai OCSP adrese.

Ja nav sadalītas smadzenes, iekšējos DNS serveros var būt nepieciešams izveidot tā sauktās precīzas zonas; šādās "precīzās" zonās būs tikai tie ieraksti, kuriem "publiskās" vērtības jāaizstāj ar "privāts". ” tie, kas raksturīgi iekšējam tīklam (situācija ir līdzīga tai, kas aprakstīta sadaļā “Atlasīt vai apvienot”).

Precīzas zonas piemērs:

Precizējiet vai apkopojiet

Literatūrā varat atrast ieteikumus domēnus (īpaši sakni) nosaukt ar vispārīgu vārdu, piemēram, Banka, Company vai Corp. Tam ir iemesli, jo mūsdienās uzņēmumi var regulāri piedzīvot apvienošanos un pārņemšanu, kā arī zīmola izmaiņas. Un, kā jūs zināt, domēna vārda maiņa ir ļoti sarežģīta.

No otras puses, ar vienādām uzņēmumu apvienošanām un pārņemšanām ļoti iespējama lietotāju migrācija no viena domēna uz otru. Praksē es saskāros ar situāciju, kad man vajadzēja migrēt lietotājus no desmitiem domēnu ar tādu pašu nosaukumu Banka. Kā zināms, uzticības attiecību izveidošana starp domēniem ar vienādiem nosaukumiem (DNS vai Netbios) nav iespējama. Jums būs jāpārdēvē šie domēni vai jāmigrē dati divos posmos, izmantojot trešo domēnu.

Es sliecos uzskatīt, ka labāk ir nosaukt domēnu konkrēti un izturēt veco nosaukumu pēc uzņēmuma pārdēvēšanas, nevis nosaukt to vispārīgi un nonākt pie nopietnām tehniskām problēmām, kad runa ir par migrāciju vai uzticības attiecību nodibināšanu.

Pēdējie pieskārieni ceļā uz pilnību

• reģistrēts visā pasaulē
• veltīts (uzņēmuma vietnes domēna atvasinājums)
• specifisks
• izmantot sadalītās smadzenes

lab.site
corp.microsoft.com

Tas nozīmē, ka Lync e-pasta un SIP adresēm būtu labāk izmantot īsākas user@site adreses. Nekas mūs neliedz to darīt, taču būs neērtības.

Lietotāja e-pasta adrese = lietotājs@vietne, pieteikšanās pieteikšanās = laboratorija\lietotājs, lietotāja galvenais vārds = lietotā[email protected]. Šeit var viegli apjukt ne tikai lietotājs, bet arī tādas programmas kā Outlook un Lync.

Pēc nelielām konta izmaiņām lietotājiem tiks piešķirts lietotāja galvenais vārds, kas vienāds ar viņu e-pasta adresi. Būs mazāk neskaidrību, un tādas programmas kā Lync un Outlook pārtrauks prasīt lietotāja pieteikšanos; pietiks, lai tās zinātu e-pasta vai SIP adresi.

Mani pamatdarbi:

Raksti par citiem resursiem:

• Active Directory domēna nosaukumu piešķiršanas apsvērumi — šeit ir sausa Microsoft rokasgrāmata
• Nosaukumu piešķiršanas konvencijas Active Directory datoriem, domēniem, vietnēm un OU — skatiet apakšsadaļu Meži, kas ir savienoti ar internetu
• Kāpēc Active Directory domēna nosaukumā neizmantot .local — līdzīgs raksts no ārzemju kolēģa

Vakar saņēmām vēstuli mūsu studijai no mūsu pastāvīgā lasītāja Andreja ar jautājumu:

Ar prieku lasīju tavu emuāru, uzzināju daudz sev noderīga, vēlējos uzzināt tavu viedokli par Active Directory domēna nosaukumu, daudzi raksta, ka jāsauc *organizācija*.local, un kāds raksta, ka tā jāsauc tāpat kā domēnu.

Īsi apskatīsim, kāds nosaukums ir vislabākais, piešķirot domēna nosaukumu organizācijā.

Kā liecina prakse, domēna vārda izvēle var samulsināt pat pieredzējušu sistēmas administratoru. Pirmoreiz palaižot utilītu dcpromo Domēna vārds tiks ģenerēts automātiski un nejauši, ja šajā posmā domēna vārds netiks saskaņots ar nepieciešamajiem noteikumiem, tad turpmāk domēna vārda maiņa būs grūtāka. Apskatīsim iespējamos variantus popularitātes secībā.

1. Domēna nosaukums example.local

Mūsu hit parādes līderis ir domēna nosaukums, kas beidzas ar vietējā. Par šo tēmu ir, piemēram, arī citas variācijas pārbaude, firma, rūpnīca, nn, loc, un tā tālāk. Mūsdienās jūs pat nevarat atcerēties, no kurienes radusies šāda mīlestība; visās savās grāmatās Microsoft vienmēr izmanto savus vārdus, piemēram, contoso.com kur mēs skaidri redzam domēna nosaukumu formāts. Tomēr gandrīz 10 gadus domēna .vietējais ieņēma vadošo pozīciju. Situācija sāka uzlaboties, parādoties pakalpojumiem, kas izmanto SSL sertifikāti. Ja domēnu “vienalga” izmantošana kļūst neiespējama. Pieņemsim, ka jūsu uzņēmums izmanto iekšēji Exchange serveris, kam nepieciešams SSL sertifikāts, lai šifrētu klientu savienojumus. Saskaņā ar jūsu scenāriju jums ir nepieciešams sertifikāts, lai veiktu šo uzdevumu ārējā sertifikācijas iestāde, kurā jānorāda visi ārējiem savienojumiem izmantoto serveru nosaukumi. Šķiet, kas vainas, mēs pierakstām visus serveru nosaukumus un piesakāmies sertifikātu izsniegšanai, bet ir viena lieta. Ar šāda domēna nosaukumu jūs nevarēsit izturēt apstiprinājumu, tā kā domēns “nerūp” neeksistē un, ja mēģināsit paskaidrot ārējai sertifikācijas iestādei, ka SAN ir jāievieto neesoša domēna FQDN nosaukums, jūs saņemsit vieglu atteikumu:

Tas nav iespējams, mēs izsniedzam tikai sertifikātus reāliem domēna vārdiem.

Bet ir vēl viena problēma. Domēna vārda lietošana nav tavs domēna vārdā var izraisīt postošas ​​sekas. Iedomājieties situāciju, ja zona vietējā būs publisks statuss. Kā zona com vai ru. Es domāju, ka nav vērts turpināt :)

2. Domēna nosaukums ir tāds pats kā ārējais domēna nosaukums

Otrā vieta mūsu hītu parādē. Neskatoties uz to, ka šāds scenārijs ir mazāk populārs, tam joprojām ir tiesības uz dzīvību. Ja neskaita faktu, ka tuvākajā nākotnē jūs joprojām sajutīsiet neērtības, uzturot tīklu, nekas cits jūs neapdraud. Galvenā problēma šajā scenārijā ir tāda, ka jums būs jāuztur divi DNS serveri: iekšējā un ārējā. Saskaņā ar šo nosacījumu datori, kas atrodas tīklā, izmantos iekšējo DNS serveri, lai atrisinātu nosaukumus, un datori ārpus uzņēmuma perimetra izmantos ārējo. Pieņemsim, ka jūsu domēnam ir lepns nosaukums example.com. IN DMZ zonā, kurā atrodaties tīmekļa vietne uzņēmums nosaukts example.com. Iepriekš aprakstītajā scenārijā datori atrodas iekšā organizācijām viņi nevarēs piekļūt tam, jo ​​viņiem example.com ir domēna vārds un, ievadot šo adresi pārlūkprogrammā, viņi dosies uz domēna kontrolleris. Kā jau minēju iepriekš, izņemot neērtības, tas neko nenovedīs. Jūs vienmēr varat izmantot kruķus, kas novirzīs jūs uz ārēju vietni, taču jūs piekrītat, ka tas ir nevajadzīgs dubultdarbs, vai arī tīklā izmantojiet vietnes nosaukumu, kas sākas ar www, vai ārpusē.

3. Viena vārda domēna vārds

Varbūt visnepareizākā iespēja no iepriekš minētā. Viena līmeņa domēni: Viena apzīmējuma domēns ir domēns, kas satur tikai viena sastāvdaļa. Acīmredzot tos sāka izmantot NT laikos, kad Microsoft pārņēma veiksmīgo Novell pieredzi. Sagadījās tā, ka sākotnēji biju FreeBSD un lielas NetWare serveru flotes administrators, sākot ar versiju 4.11, un tāpēc tajos senos laikos NetWare savā darbā izmantoja Bindery, kas ir tieši nosaukumi. viena līmeņa domēna diagramma, ko vēlāk pieņēma Microsoft.

Labākā pieredze

Ir pienācis laiks to apkopot. Kādu domēna vārdu man vajadzētu izmantot? Tikai trešā līmeņa domēns jums piederošajā domēnā. Jums nevajadzētu izmantot citu cilvēku skaistākos domēna vārdus :-). Tālāk varat redzēt šāda domēna piemēru.

Īsāk sakot, AD ļauj jums izveidot vienu administrēšanas punktu visiem publicētajiem resursiem. AD ir balstīta uz X.500 nosaukšanas standartu, izmanto domēna nosaukumu sistēmu (DNS), lai noteiktu atrašanās vietu, un izmanto Lightweight Directory Access Protocol (LDAP) kā savu pamata protokolu.

AD apvieno tīkla loģisko un fizisko struktūru. AD loģiskā struktūra sastāv no šādiem elementiem:

• organizatoriskā vienība – datoru apakšgrupa, kas parasti atspoguļo uzņēmuma struktūru;
• domēns – datoru grupai, kam ir kopīga direktoriju datu bāze;
• domēna koks – viens vai vairāki domēni, kuriem ir kopīga nosaukumvieta;
• domēna mežs – viens vai vairāki koki, kas koplieto direktoriju informāciju.

Fiziskā struktūra ietver šādus elementus:

• apakštīkls – tīkla grupa ar noteiktu IP adreses apgabalu un tīkla masku;
• vietne – viens vai vairāki apakštīkli. Vietne tiek izmantota, lai konfigurētu piekļuvi direktorijai un replikācijai.

Direktorijā tiek glabāta trīs veidu informācija: domēna dati, shēmas dati un konfigurācijas dati. AD izmanto tikai domēna kontrollerus. Domēna dati tiek replicēti visos domēna kontrolleros. Visiem domēna kontrolleriem ir vienādas tiesības, t.i. visas izmaiņas, kas veiktas no jebkura domēna kontrollera, tiks replicētas visos citos domēna kontrolleros. Shēma un konfigurācijas dati tiek replicēti visos koka vai meža domēnos. Turklāt visi atsevišķie domēna objekti un daži meža objektu rekvizīti tiek replicēti globālajā katalogā (GC). Tas nozīmē, ka domēna kontrolleris saglabā un atkārto koka vai meža shēmu, konfigurācijas informāciju visiem koka vai meža domēniem un visus direktoriju objektus un rekvizītus savam domēnam.

Domēna kontrolleris, kurā tiek glabāts GC, satur un atkārto meža shēmas informāciju, visu meža domēnu konfigurācijas informāciju un ierobežotu rekvizītu kopu visiem direktoriju objektiem mežā (kas tiek replicēta tikai starp GC serveriem), un visi jūsu domēna direktoriju objekti un rekvizīti.

Domēna kontrolleriem var būt dažādas operāciju galvenās lomas. Operāciju galvenais apstrādā uzdevumus, kurus ir neērti veikt vairāku galveno replikācijas modelī.

Ir piecas operāciju galvenās lomas, kuras var piešķirt vienam vai vairākiem domēna kontrolleriem. Dažām lomām ir jābūt unikālām meža līmenī, bet citām domēna līmenī.

Katrā AD mežā ir šādas lomas:

• Shēmas meistars - Pārvalda direktoriju shēmas atjauninājumus un izmaiņas. Lai atjauninātu direktoriju shēmu, jums ir jābūt piekļuvei shēmas šablonam. Lai noteiktu, kurš serveris pašlaik ir domēna shēmas īpašnieks, komandrindas logā ir jāievada komanda dsquery server -hasfsmo shēma
• Domēna nosaukumu meistars – pārvalda domēnu pievienošanu un noņemšanu mežā. Lai pievienotu vai noņemtu domēnu, jums ir nepieciešama piekļuve domēna nosaukumu galvenajam. Lai noteiktu, kurš serveris pašlaik ir domēna nosaukumu galvenais, komandu uzvednes logā ievadiet dsquery server -hasmo name

Šīs lomas ir kopīgas visam mežam kopumā un ir raksturīgas tikai tam.

Katram AD domēnam ir jābūt šādām lomām:

• Relatīvā ID meistars – piešķir relatīvos identifikatorus domēna kontrolleriem. Katru reizi, kad tiek izveidots lietotājs, grupa vai datora objekts, kontrolleri piešķir objektam unikālu drošības identifikatoru, kas sastāv no domēna drošības identifikatora un unikāla identifikatora, ko ir piešķīris relatīvā identifikatora galvenais. Lai noteiktu, kurš serveris pašlaik ir relatīvo domēna ID galvenais serveris, komandu uzvednē ievadiet dsquery server -hasfsmo rid
• PDC emulators – Jauktā vai vidējā domēna režīmā darbojas kā Windows NT galvenais domēna kontrolleris. Tas autentificē Windows pieteikšanos, apstrādā paroles izmaiņas un atkārto BDC atjauninājumus, ja tādi ir. Lai noteiktu, kurš serveris pašlaik ir domēna PDC emulators, komandu uzvednē ievadiet dsquery server -hasfsmo pdc
• Infrastruktūras meistars – atjaunina objektu saites, salīdzinot tā kataloga datus ar GC datiem. Ja dati ir novecojuši, tas pieprasa atjauninājumus no GC un replicē tos atlikušajos domēna kontrolleros. Lai noteiktu, kurš serveris pašlaik ir domēna infrastruktūras galvenais serveris, komandu uzvednē ievadiet dsquery server -hasfsmo infr

Šīs lomas ir kopīgas visam domēnam, un tām ir jābūt unikālām tajā.

Operāciju galvenās lomas tiek automātiski piešķirtas pirmajam kontrolierim domēnā, taču vēlāk varat tās piešķirt atkārtoti. Ja domēnā ir tikai viens kontrolleris, tas vienlaikus veic visas operācijas galvenās lomas.

Nav ieteicams nodalīt shēmas galvenā un domēna nosaukumu galvenā loma. Ja iespējams, piešķiriet tos vienam domēna kontrollerim. Lai nodrošinātu maksimālu efektivitāti, ir vēlams, lai relatīvais ID galvenais un PDC emulators atrastos vienā kontrollerī, lai gan vajadzības gadījumā šīs lomas var atdalīt. Lielā tīklā, kur liela slodze samazina veiktspēju, relatīvais ID galvenais un PDC emulators ir jānovieto uz dažādiem kontrolleriem. Turklāt nav ieteicams viesot infrastruktūras galveno serveri domēna kontrollerī, kurā tiek glabāts globālais katalogs.

Uz Windows Server 2003 balstīta domēna kontrollera (DC) instalēšana, izmantojot Active Directory iestatīšanas vedni

Domēna kontrolleris tiek instalēts, izmantojot Active Directory instalēšanas vedni. Lai paaugstinātu serveri par domēna kontrolleri, jums ir jānodrošina, lai tiktu izpildītas visas nepieciešamās prasības:

1. Serverim ir jābūt vismaz vienam NTFS nodalījumam, lai pielāgotos SYSVOL sistēmas sējumam.
2. Serverim ir jābūt piekļuvei DNS serverim. DNS pakalpojumu ieteicams instalēt tajā pašā serverī. Ja tiek izmantots atsevišķs serveris, jums ir jānodrošina, ka tas atbalsta pakalpojuma atrašanās vietas resursu ierakstus (RFC 2052) un dinamisko atjauninājumu protokolu (RFC 2136).
3. Serverī ir jābūt kontam ar vietējā administratora tiesībām.

Apskatīsim tuvāk servera lomas popularizēšanu Active Directory domēna kontrollerim soli pa solim:

Active Directory domēna pārvaldības pamati

Vairāki rīki Microsoft Management Console (MMC) papildprogrammā atvieglo darbu ar Active Directory.

Active Directory lietotāju un datoru papildprogramma ir MMC, ko varat izmantot direktoriju informācijas administrēšanai un publicēšanai. Tas ir galvenais Active Directory administratīvais rīks un tiek izmantots, lai veiktu visus uzdevumus, kas saistīti ar lietotājiem, grupām un datoriem, kā arī lai pārvaldītu organizatoriskās vienības.

Lai palaistu papildprogrammu (Active Directory lietotāji un datori), izvēlnē Administratīvie rīki atlasiet komandu ar tādu pašu nosaukumu.

Pēc noklusējuma Active Directory lietotāju un datoru konsole darbojas ar domēnu, kuram pieder jūsu dators. Varat piekļūt datora un lietotāja objektiem šajā domēnā, izmantojot konsoles koku vai izveidot savienojumu ar citu domēnu. Tajā pašā konsolē esošie rīki ļauj skatīt papildu objekta parametrus un tos meklēt.

Kad esat ieguvis piekļuvi domēnam, jūs redzēsit standarta mapju kopu:

• Saglabātie vaicājumi (Saglabātie vaicājumi) – saglabāti meklēšanas kritēriji, kas ļauj ātri atkārtot iepriekš veikto meklēšanu Active Directory;
• iebūvēts – iebūvēto lietotāju kontu saraksts;
• Datori – noklusējuma konteiners datoru kontiem;
• Domēna kontrolieri – noklusējuma konteiners domēna kontrolleriem;
• Ārvalstu drošības principi – satur informāciju par objektiem no uzticama ārējā domēna. Parasti šie objekti tiek izveidoti, kad pašreizējai domēna grupai tiek pievienots objekts no ārēja domēna;
• Lietotāji - noklusējuma konteiners lietotājiem.

Dažas konsoles mapes pēc noklusējuma netiek rādītas. Lai tos parādītu, izvēlnē Skats atlasiet Papildfunkcijas. Šīs ir papildu mapes:

• Pazaudēts un atrasts – pazaudēts īpašnieks, kataloga objekti;
• NTDS kvotas – dati par uzziņu pakalpojumu kvotām;
• Programmas dati – Microsoft lietojumprogrammu direktoriju pakalpojumā saglabātie dati;
• Sistēma – iebūvētie sistēmas parametri.

Jūs varat patstāvīgi pievienot mapes organizācijas vienībām AD kokam.

Apskatīsim domēna lietotāja konta izveides piemēru. Lai izveidotu lietotāja kontu, ar peles labo pogu noklikšķiniet uz konteinera, kurā vēlaties ievietot lietotāja kontu, konteksta izvēlnē atlasiet Jauns un pēc tam atlasiet Lietotājs. Tiks atvērts jauns objekts — lietotājs vedņa logs:

1. Attiecīgajos laukos ievadiet lietotāja vārdu, iniciāļus un uzvārdu. Šī informācija būs nepieciešama, lai izveidotu lietotāja parādāmo vārdu.
2. Rediģējiet savu pilno vārdu. Tam jābūt unikālam domēnā, un tam jābūt ne garākam par 64 rakstzīmēm.
3. Ievadiet savu pieteikšanās vārdu. Izmantojiet nolaižamo sarakstu, lai atlasītu domēnu, ar kuru konts tiks saistīts.
4. Ja nepieciešams, mainiet savu pieteikšanās lietotājvārdu sistēmās, kurās darbojas operētājsistēma Windows NT 4.0 vai vecāka versija. Pēc noklusējuma pirmās 20 rakstzīmes no lietotāja pilnā vārda tiek izmantotas kā pieteikšanās vārds sistēmām, kurās darbojas iepriekšējās Windows versijas. Šim nosaukumam ir jābūt unikālam domēnā.
5. Klikšķis Nākamais. Norādiet lietotāja paroli. Tās iestatījumiem jāatbilst jūsu paroles politikai;
   Confirm Password – lauks, ko izmanto, lai apstiprinātu ievadītās paroles pareizību;
   Nākamajā pieteikšanās reizē lietotājam ir jāmaina parole(Nākamajā pieteikšanās reizē pieprasīt paroles maiņu) – ja ir atzīmēta šī izvēles rūtiņa, lietotājam nākamajā pieteikšanās reizē būs jāmaina parole;
   Lietotājs nevar mainīt paroli – ja ir atzīmēta šī izvēles rūtiņa, lietotājs nevar mainīt paroli;
   Parole nekad nebeidzas — ja ir atzīmēta šī izvēles rūtiņa, šī konta parole nekad nebeigsies (šis iestatījums ignorē domēna konta politiku);
   Konts ir atspējots — ja ir atzīmēta šī izvēles rūtiņa, konts ir atspējots (šī opcija ir noderīga, lai īslaicīgi atspējotu kādam konta lietošanu).

Konti ļauj saglabāt lietotāja kontaktinformāciju, kā arī informāciju par dalību dažādās domēnu grupās, profila ceļu, pieteikšanās skriptu, mājas mapes ceļu, datoru sarakstu, no kuriem lietotājam ir atļauts pieteikties domēnā u.c.

Pieteikšanās skripti definē komandas, kas tiek izpildītas katru reizi, kad piesakāties sistēmā. Tie ļauj konfigurēt sistēmas laiku, tīkla printerus, ceļus uz tīkla diskdziņiem utt. Skripti tiek izmantoti, lai komandas palaistu vienreiz, un skriptu iestatītie vides iestatījumi netiek saglabāti vēlākai lietošanai. Pieteikšanās skripti var būt Windows skriptu servera faili ar paplašinājumu .VBS, .JS un citi, sērijveida faili ar paplašinājumu .BAT, pakeš faili ar paplašinājumu .CMD, programmas ar paplašinājumu .EXE.

Katram kontam varat piešķirt savu mājas mapi lietotāja failu glabāšanai un atjaunošanai. Lielākā daļa lietojumprogrammu pēc noklusējuma atver mājas mapi failu atvēršanas un saglabāšanas darbībām, tādējādi lietotājiem ir vieglāk atrast savus datus. Komandrindā mājas mape ir sākuma pašreizējais direktorijs. Mājas mape var atrasties vai nu lietotāja lokālajā cietajā diskā, vai koplietotā tīkla diskā.

Grupas politikas var piemērot domēna datoram un lietotāju kontiem. Grupas politika vienkāršo administrēšanu, sniedzot administratoriem centralizētu kontroli pār lietotāju un datoru privilēģijām, atļaujām un iespējām. Grupas politika ļauj:

• izveidot centralizēti pārvaldītas īpašas mapes, piemēram, Mani dokumenti;
• kontrolēt piekļuvi Windows komponentiem, sistēmas un tīkla resursiem, vadības paneļa rīkiem, darbvirsmai un izvēlnei Sākt;
• konfigurēt lietotāja un datora skriptus, lai veiktu uzdevumu noteiktā laikā;
• Konfigurējiet paroļu un kontu bloķēšanas, auditēšanas, lietotāju tiesību piešķiršanas un drošības politikas.

Papildus lietotāju kontu un grupu pārvaldības uzdevumiem ir arī daudzi citi domēna pārvaldības uzdevumi. Šim nolūkam kalpo citi rīki un lietojumprogrammas.

Aprīkojums Active Directory domēni un tresti(Active Directory — domēni un uzticēšanās) tiek izmantots darbam ar domēniem, domēnu kokiem un domēnu mežiem.

Aprīkojums Active Directory vietnes un pakalpojumi(Active Directory — vietnes un pakalpojumi) ļauj pārvaldīt vietnes un apakštīklus, kā arī starpvietņu replikāciju.

Lai pārvaldītu AD objektus, ir komandrindas rīki, kas ļauj veikt plašu administratīvo uzdevumu klāstu:

• Dsadd – pievieno Active Directory datorus, kontaktpersonas, grupas, organizācijas vienības un lietotājus. Lai saņemtu palīdzību, ierakstiet dsadd /? , piemēram, dsadd dators/?
• Dsmod – maina Active Directory reģistrēto datoru, kontaktpersonu, grupu, organizatorisko vienību, lietotāju un serveru rekvizītus. Lai saņemtu palīdzību, ierakstiet dsmod /? , piemēram, dsmod serveris /?
• Dsmove – Pārvieto vienu objektu uz jaunu vietu domēnā vai pārdēvē objektu, to nepārvietojot.
• Dsget — Parāda Active Directory reģistrēto datoru, kontaktpersonu, grupu, organizatorisku vienību, lietotāju, vietņu, apakštīklu un serveru rekvizītus. Lai saņemtu palīdzību, ierakstiet dsget /? , piemēram, dsget apakštīkls /?
• Dquery – meklē datorus, kontaktpersonas, grupas, organizācijas vienības, lietotājus, vietnes, apakštīklus un serverus Active Directory pēc noteiktiem kritērijiem.
• Dsrm – dzēš objektu no Active Directory.
• Ntdsutil – ļauj skatīt informāciju par vietni, domēnu vai serveri, pārvaldīt operāciju galvenos un uzturēt Active Directory datu bāzi.

Ir arī Active Directory atbalsta rīki:

• LDP – Veic darbības, izmantojot LDAP protokolu programmā Active Directory Administration.
• Atbildēt – Pārvalda replikāciju un parāda tās rezultātus grafiskā interfeisā.
• Dsacls – Pārvalda Active Directory objektu ACL (piekļuves kontroles sarakstus).
• Dfsutil – Pārvalda izplatīto failu sistēmu (DFS) un parāda informāciju par tās darbību.
• Dnscmd – Pārvalda serveru, zonu un DNS resursu ierakstu rekvizītus.
• Movetree - Pārvieto objektus no viena domēna uz citu.
• Repadmin – Pārvalda replikāciju un parāda tās rezultātus komandrindas logā.
• Sdcbeck – analizē piekļuves kontroles sarakstu izplatīšanu, replikāciju un pārmantošanu.
• Sidwalker — Iestata ACL objektiem, kas vēsturiski pieder pārvietotiem, dzēstiem vai bāreņu kontiem.
• Netdom - Ļauj pārvaldīt domēnus un uzticamības attiecības no komandrindas.

Kā redzams šajā rakstā, datoru grupu apvienošana domēnos, kuru pamatā ir Active Directory, var ievērojami samazināt administratīvo uzdevumu izmaksas, centralizējot domēna datoru un lietotāju kontu pārvaldību, kā arī ļauj elastīgi pārvaldīt lietotāju tiesības, drošību un virkne citu parametru. Detalizētāki materiāli par domēnu organizēšanu ir atrodami attiecīgajā literatūrā.

Domēna vārda izvēle nav grūts uzdevums, taču, kā rāda dzīve, diezgan bieži pēc dcpromo palaišanas domēna vārds tiek ģenerēts nejauši. Šķiet, ka ar to nav nekā slikta, domēns darbojas, printeri drukā, tiek atvērts 1C. Bet diemžēl ir vairākas situācijas, kad nejauša nosaukuma ģenerēšana, ja tas jums neder, noteikti radīs problēmas. Šajā īsajā ierakstā es mēģināšu runāt par to, kā nenosaukt savus domēnus un kāpēc. Lai gan informācija ir labi zināma, reālā dzīve rāda, ka nosaukšanas kļūdas ir vienkārši endēmiskas. Un tā kā domēna pārdēvēšanas procedūra ir IT-sadomaso, labāk ir darīt visu pareizi no sākuma.

1. Situācija viena. Domēna nosaukums – domēna vārds.lokālais

Iespējams, visizplatītākā iespēja ir izmantot beigu .local vai jebkuru citu augstākā līmeņa domēnu, ko IANA neizmanto. (a la.msk vai.test or.loc utt.) No kurienes tas nāca, tagad ir grūti pateikt, ir vairākas iespējas. Viens saka, ka 2000. gadā, kad AD parādījās konferencē demonstrācijā, runātājs izveidoja šādu domēnu.
Cilvēki to uztvēra kā aicinājumu rīkoties. Otrā hipotēze, lai arī neizslēdz pirmo, tomēr sliecas uz to, ka visticamāk pati MSFT literatūrā skaidri uzrakstīja ieteikumu, pēc kura .vietējais devās pie tautas. Kāpēc šī opcija ir slikta?

Ir vairāki scenāriji, bet es jums pastāstīšu sāpīgākos. Pieņemsim, ka instalējat Exchange Server savā organizācijā, kam ir nepieciešams sertifikāts, lai šifrētu klientu savienojumus. Gribu sertifikātu no komerccentra, viss kā ar cilvēkiem. Protams, sertifikātā jānorāda visi serveru nosaukumi, ar kuriem serveris būs pieejams. Un, ja ārējais domēns pieder mums un var viegli iziet validāciju, tad iekšējais domēns a la super-firma.mascow neeksistē un, mēģinot paskaidrot sertifikācijas iestādēm, ka jums ir jāievieto FQDN SAN - Exchange. .super-firma.moscow saņemsiet atbildi:

Tas nav iespējams, mēs izsniedzam tikai sertifikātus reāliem domēna vārdiem.

Šobrīd Comodo sertifikācijas iestāde ļauj sertifikāta SAN iebāzt visādus neķītrus vārdus, kas būtiski sašaurina sertifikātu sniedzēja izvēli, un nav garantijas, ka viņi to atļaus arī turpmāk.

2. Otrā situācija. AD domēna nosaukums ir tāds pats kā ārējam interneta domēna nosaukumam.

Arī šī ir izplatīta iespēja, taču ar sertifikātiem problēmu nebūs. Bet ir problēmas ar nosaukumu izšķirtspēju. Tā rezultātā rodas situācija, kad ārējie un iekšējie DNS serveri nav savienoti viens ar otru, bet tajā pašā laikā apkalpo nesaistītas zonas ar vienādiem nosaukumiem. Šādā situācijā katrs iekšējais serveris loģiski uzskata sevi par zonas autoritatīvu un, ja nezina par kādu saimnieku, autoritatīvi paziņo - NĒ! Tā kā jums ir daži ārējie resursi, visizplatītākās vietnes, dabiski A tipa ieraksti tiek pievienoti ārējā DNS servera zonai. Tagad, kad iekšējais klients mēģina atrisināt ārēja resursa nosaukumu, tā pieprasījums tiks nosūtīts uz iekšējo DNS serveri (protams, tas ir domēna klients) un tas atbildēs "Es nezinu, tāda nav. lieta un jums tas nav jāmeklē”, jo tas redz, ka tas ir autoritatīvs serveris šai zonai.

Lai atrisinātu šo problēmu, jums būs jāreģistrē ārējie ieraksti divās zonās, un tas neizbēgami radīs neskaidrības un papildu rutīnu. Ja tas jūs netraucē, šajā gadījumā mēģiniet atļaut iekšējiem lietotājiem atvērt uzņēmuma vietni bez prefiksa www. Kopumā tas ir slikts risinājums, un to nevajadzētu izmantot.

Īpaši sveicieni tiem administratoriem, kuri savus iekšējos domēnus nosaukuši citu cilvēku slaveno publisko domēnu vārdā. Es domāju, ka šajā gadījumā jums nav jāpaskaidro, kāda veida hemoroīdi jums ir.

3. Situācija trešā. Plakans domēna nosaukums, kas sastāv no viena vārda.

Ja pirmās divas iespējas vēl var izdzīvot, tad ir pienācis laiks ieviest administratīvos sodus par vienotiem domēna vārdiem. Vienas etiķetes domēns (viena līmeņa domēns, SLD) ir domēns, kas satur tikai vienu nominālo komponentu. Nezinu, no kurienes radās mānija tos lietot, taču jau sen ir oficiāli atzīts, ka SLD domēnus nedrīkst izmantot, veidojot IT infrastruktūras.

Tajā pašā laikā šī informācija ir tāds Kanādas akordeons, ka var tikai brīnīties, no kurienes nāk SLD domēni. http://support.microsoft.com/kb/300684.

Kādi ir draudi? Microsoft produktu atbalsta trūkums šai konfigurācijai. No svaigiem. Mēģiniet instalēt Exchange 2010 SP1 vienā domēnā un saņemiet ziņojumu, ka šī konfigurācija vairs netiek atbalstīta.

Kā pareizi nosaukt domēnu?

Atbilde ir vienkārša. Izveidojiet konsekventu nosaukumvietu. Tas ir, ja vietnes domēns ir reālajā pasaulē, padariet Active Directory domēnu par apakšdomēnu, piemēram, corp.site. Šajā situācijā visas problēmas pazūd. Un nemaz nav nepieciešams deleģēt apakšdomēna DNS ārējam DNS serverim. Lai gan, ja jūs to darāt, vārda izšķiršana var notikt abos virzienos. (no ārējo vārdu iekšējā tīkla, no iekšējo nosaukumu interneta)

Tiem, kuri sākotnēji nedomāja, ka ir “laba” saite: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx Jauku vakaru, lasot šo darbu.

MCP/MCT Iļja Rūds