Nume de domeniu local. Informații de bază despre domeniile Active Directory. Configurarea unui locator de controler de domeniu pentru Windows XP Professional și versiunile ulterioare de Windows

A venit primăvara și, odată cu ea, o dorință sporită de a da naștere unui material fundamental care să răspundă la o întrebare care pare evidentă, dar în același timp este extrem de importantă la proiectare: ce nume să dai domeniului Active Directory pentru ca acesta să nu fie chinuitor de dureros mai târziu?

În acest articol, voi încerca să vă ghidez de la cele mai proaste opțiuni pentru un nume de domeniu Active Directory la ceea ce, după părerea mea, este cea mai bună opțiune, pe parcurs, subliniind rake-ul care poate fi depășit.

Un domeniu cu un nume cu o singură etichetă nu este potrivit pentru utilizare într-un mediu de producție și singura modalitate corectă este să scapi de el cât mai curând posibil.

Caractere nevalide în numele domeniului

De exemplu, o subliniere. Deși versiunile anterioare de Windows Server permiteau acest caracter la selectarea unui nume de domeniu DNS, acesta nu respectă standardul RFC 1123 pentru DNS. Noile versiuni de Windows Server nu mai permit denumirea de domenii contrar standardului. Dacă un domeniu cu un nume care conține un caracter de subliniere a fost moștenit, ne așteaptă mari probleme. De exemplu, nu puteți instala Exchange 2007 și versiuni ulterioare. Există o singură soluție - să scapi de caracterele nevalide din numele domeniului prin migrarea către alt domeniu (de preferință) sau prin redenumirea domeniului (nesigur).

Spațiu de nume disjuns

Unul dintre cazurile speciale ale spațiului de nume Disjoint este situația în care numele Netbios al domeniului diferă de partea cea mai din stânga a numelui DNS al domeniului.

Nume Netbios = TEST
Nume DNS = lab.site

Din punct de vedere al funcționalității, această configurație este pe deplin acceptată. Dar totuși recomand să-l evitați pentru a nu crea confuzie și ambiguitate.

.local sau ICANN

În multe tutoriale puteți vedea nume de domenii precum company.local . Într-adevăr, nu există nicio crimă în utilizarea unor astfel de nume în scopuri de instruire și testare. Este mai rău când domeniile reale sunt denumite folosind aceeași schemă:

• Numele contrazice ideologia DNS-ului global: nu garantează absența coliziunilor cu alte domenii similare (când vine timpul să stabilim relații de încredere)
• Nu este posibil să utilizați acest nume pentru acces din rețeaua globală (când este timpul să publicați)
• Un certificat SSL public nu poate fi obținut pentru un domeniu a cărui proprietate nu poate fi verificată. Această limitare este relevantă în special cu dezvoltarea serviciilor cloud, când granițele dintre serviciile on-premise și cele cloud sunt estompate. Doar un exemplu: pentru ca Single Sign On să funcționeze cu serviciile Office 365, este necesară AD Federation Services cu un certificat public

Prin urmare, vă recomand ca atunci când denumiți un domeniu, să utilizați întotdeauna un nume global înregistrat oficial în ierarhia ICANN (Internet Corporation for Assigned Names and Numbers), care este garantat pentru a elimina dezavantajele descrise mai sus.

site-ul web
argon.com.ru
irom.info

Selectați sau îmbinați

Să ne imaginăm că proiectăm o structură de domeniu pentru compania Argon, care are un site web pe site-ul adresei și folosește și adrese de e-mail din același domeniu.? Dar este mai bine să nu faceți acest lucru din următoarele motive:

• Dacă în rețeaua unei astfel de organizații introducem adresa http://site/ în browser, atunci nu vom ajunge pe site-ul companiei, ci la primul controler de domeniu pe care îl întâlnim.
• Administrarea înregistrărilor DNS publice și interne este dificilă: toate înregistrările DNS publice din zona site-ului care sunt utilizate din rețeaua internă trebuie să fie duplicate în zona DNS internă. De asemenea, este necesar să se asigure cumva sincronizarea acestor înregistrări.

De exemplu, pe Internet există un site web www.site. Pentru ca utilizatorii din rețeaua internă să o poată accesa, este necesar să creați o intrare similară în zona DNS internă

• Există posibilitatea de coliziuni între numele resurselor interne și externe.

De exemplu, serverul ftp.site este utilizat pe scară largă în rețeaua internă. Dintr-o dată a apărut nevoia de a oferi utilizatorilor de internet un serviciu de fișiere la aceeași adresă ftp.site. Ce s-a întâmplat? Utilizatorii interni nu se pot conecta la serviciul extern folosind numele specificat...

Astfel, este mai bine ca un domeniu Active Directory să aibă un spațiu de nume dedicat, diferit de spațiul de nume de pe Internet (site-ul companiei și altele asemenea). Și aici există o alegere:

• Utilizați un nume complet diferit pentru AD (site pentru un site, argon.com.ru pentru AD)
• Utilizați un nume de copil pentru AD (site pentru site, lab.site pentru AD)

Ambele opțiuni satisfac ideologia DNS și sunt lipsite de dezavantajele enumerate mai sus, dar a doua opțiune cu un domeniu copil poate fi mai convenabilă din următoarele puncte de vedere:

• suport pentru nume de domenii înregistrate (plată pentru înregistrare și găzduire DNS pentru un singur domeniu)
• disponibilitatea numelor frumoase pentru înregistrare (nu este nevoie să vă înregistrați)
• obținerea de certificate SSL publice (un singur certificat wildcard poate fi folosit atât pentru site-ul companiei, cât și la publicarea resurselor rețelei interne)

Așadar, sugerez să alegeți un domeniu dedicat pentru AD, dar un domeniu care este un copil al site-ului web al organizației.

lab.site
corp.microsoft.com

Creier impartit

Split-brain DNS înseamnă utilizarea unui nume de domeniu pentru a publica resurse atât în ​​rețeaua internă, cât și pe Internet. În acest caz, serverele DNS din rețeaua internă rezolvă adrese precum portal.lab.site în adrese IP interne și, respectiv, serverele DNS publice de pe Internet, în IP-uri externe. Exemplu:

Datorită split-brain, se obțin astfel de lucruri utile ca adrese unice pentru accesarea resurselor atât din rețeaua internă, cât și de pe Internet. Utilizatorul trebuie să cunoască doar o singură adresă portal.lab.site, prin care să poată ajunge la documentele sale, și nu contează unde se află: în biroul companiei sau într-un hotel.

Din perspectiva infrastructurii, este convenabil să aveți aceeași adresă pentru CRL sau OCSP în certificatele SSL emise de CA interne.

În absența creierului divizat, poate fi necesar să se creeze așa-numitele zone de identificare pe serverele DNS interne; astfel de zone „puncte” vor conține doar acele înregistrări pentru care este necesar să se înlocuiască valorile „publice” cu „private”. ” cele caracteristice rețelei interne (situație similară cu cea descrisă la rubrica „Selectare sau Combină”).

Exemplu de zonă precisă:

Clarificați sau rezumați

În literatură puteți găsi sfaturi pentru a denumi domenii (în special rădăcina) cu un cuvânt generic, cum ar fi Bank, Company sau Corp. Există motive pentru aceasta, deoarece în zilele noastre companiile pot experimenta în mod regulat fuziuni și achiziții și schimbări de brand. Și după cum știți, schimbarea unui nume de domeniu este foarte dificilă.

Pe de altă parte, cu aceleași fuziuni și achiziții de companii, este foarte probabilă migrarea utilizatorilor de la un domeniu la altul. În practică, am dat peste o situație în care trebuia să migrez utilizatori de pe o duzină de domenii cu același nume Bank. După cum știți, stabilirea de relații de încredere între domenii cu aceleași nume (fie DNS sau Netbios) nu este posibilă. Va trebui fie să redenumiți aceste domenii, fie să migrați datele în două etape, printr-un al treilea domeniu.

Înclin să cred că este mai bine să denumesc un domeniu în mod specific și să suport vechiul nume după ce compania este redenumită, decât să-l denumesc generic și să ajungi cu probleme tehnice serioase când vine vorba de migrare sau de stabilire a relațiilor de încredere.

Ultimele retușuri pe calea spre perfecțiune

• înregistrat la nivel global
• dedicat (copilul domeniului site-ului companiei)
• specific
• folosește creierul divizat

lab.site
corp.microsoft.com

Acestea fiind spuse, ar fi mai plăcut să folosiți adrese mai scurte user@site pentru adresele de e-mail și SIP în Lync. Nimic nu ne împiedică să facem asta, dar vor exista inconveniente.

Adresa de e-mail a utilizatorului = user@site, login login = lab\user, nume principal de utilizator = [email protected]. Este ușor să fii confuz aici nu numai pentru utilizator, ci și pentru programe precum Outlook și Lync.

După modificări minore ale contului, utilizatorii vor avea un nume principal de utilizator egal cu adresa lor de e-mail. Va exista mai puțină confuzie, iar programe precum Lync și Outlook nu vor mai cere autentificarea utilizatorului; va fi suficient ca aceștia să cunoască adresa de e-mail sau SIP.

Lucrările mele fundamentale:

Articole despre alte resurse:

• Considerații privind denumirea domeniilor Active Directory - aici vine un ghid complet de la Microsoft
• Convenții de denumire în Active Directory pentru computere, domenii, site-uri și OU - vezi subsecțiunea Păduri care sunt conectate la internet
• De ce nu ar trebui să utilizați .local în numele dvs. de domeniu Active Directory - articol similar de la un coleg străin

Ieri, am primit o scrisoare către studioul nostru de la cititorul nostru obișnuit Andrey, cu întrebarea:

Am citit cu placere blogul tau, am invatat o multime de lucruri utile pentru mine, am vrut sa stiu parerea ta despre numele domeniului Active Directory, multi scriu ca ar trebui sa se numeste *organizatie*.local, iar cineva scrie ca ar trebui să fie numit la fel ca și domeniul.

Să aruncăm o privire rapidă la care este cel mai bun nume de utilizat atunci când denumim un domeniu în cadrul unei organizații.

După cum arată practica, alegerea unui nume de domeniu poate deruta chiar și un administrator de sistem cu experiență. Când lansați utilitarul pentru prima dată dcpromo Numele de domeniu va fi generat automat și aleatoriu; dacă în această etapă numele de domeniu nu este adus în conformitate cu regulile necesare, atunci în viitor va fi mai dificil să se schimbe numele de domeniu. Să ne uităm la opțiunile posibile în ordinea popularității.

1. Domeniu numit exemplu.local

Liderul paradei noastre este numele de domeniu care se termină cu local. Există și alte variații pe această temă, de exemplu Test, firma, fabrică, nn, loc, și așa mai departe. În zilele noastre nici nu vă puteți aminti de unde a venit o astfel de dragoste; în toate cărțile sale, Microsoft își folosește întotdeauna propriile nume, cum ar fi contoso.com unde vedem clar format de denumire a domeniului. Cu toate acestea, de aproape 10 ani domeniul .local a ocupat o poziţie de conducere. Situația a început să se îmbunătățească odată cu apariția serviciilor care folosesc Certificate SSL. Acolo unde utilizarea domeniilor „nu-mi pasă” devine imposibilă. Uite, să presupunem că compania ta folosește intern Server de schimb, care necesită un certificat SSL pentru a cripta conexiunile client. În conformitate cu scenariul dvs., aveți nevoie de un certificat pentru a implementa această sarcină autoritate externă de certificare, în care trebuie să specificați toate numele serverelor utilizate pentru conexiunile externe. S-ar părea că ceea ce este în neregulă, notăm toate numele serverelor și solicităm eliberarea de certificate, dar există un lucru. Cu numele unui astfel de domeniu nu vei putea trece validarea, deoarece domeniul „nu-mi pasă” nu există și dacă încercați să explicați unei autorități de certificare externe că trebuie să puneți numele FQDN al unui domeniu inexistent în SAN, veți primi un refuz ușor:

Nu este posibil, emitem doar certificate pentru nume de domenii reale.

Dar mai este o problemă. Utilizarea numelui de domeniu nu al tăuîntr-un nume de domeniu poate duce la consecințe dezastruoase. Imaginați-vă situația dacă zona local va avea statut public. Ca o zonă com sau ru. Nu cred că merită să continui mai departe :)

2. Numele de domeniu este același cu numele de domeniu extern

Locul doi în parada noastră. În ciuda faptului că un astfel de scenariu este mai puțin popular, el încă are dreptul la viață. În afară de faptul că în viitorul apropiat veți întâmpina în continuare unele inconveniente la întreținerea rețelei, nimic altceva nu vă amenință. Principala problemă în acest scenariu este că va trebui să mențineți două servere DNS: intern si extern. În această condiție, computerele situate în interiorul rețelei vor folosi serverul DNS intern pentru a rezolva numele, iar computerele din afara perimetrului companiei vor folosi unul extern. Să presupunem că domeniul tău are un nume mândru exemplu.com. ÎN DMZ zona in care te afli site-ul web firma numita exemplu.com. În scenariul descris mai sus, computerele localizate interior organizatii nu vor putea accesează-l datorită faptului că pentru ei example.com este numele domeniului iar când introduceți această adresă în browser vor merge la controlor de domeniu. După cum am menționat mai sus, în afară de inconveniente, acest lucru nu va duce la nimic. Puteți folosi oricând cârje care vă vor redirecționa către un site extern, dar veți fi de acord că aceasta este o muncă dublă inutilă, sau în interiorul rețelei folosiți numele site-ului care începe cu www, sau afară.

3. Nume de domeniu cu un singur cuvânt

Poate cea mai incorectă opțiune dintre cele de mai sus. Domenii cu un singur nivel: Domeniu cu o singură etichetă este un domeniu care conține doar o singură componentă. Se pare că au început să fie folosite în zilele NT, când Microsoft a adoptat experiența de succes a Novell. S-a întâmplat că inițial eram administratorul FreeBSD și al unei flote mari de servere NetWare începând cu versiunea 4.11 și astfel, în acele vremuri străvechi, NetWare folosea Bindery în munca sa, care sunt tocmai numele. diagramă de domeniu cu un singur nivel, care a fost adoptat ulterior de Microsoft.

Cele mai bune practici

E timpul să rezumam. Ce nume de domeniu ar trebui să folosesc? Doar un domeniu de nivel al treilea în domeniul pe care îl dețineți. Nu ar trebui să folosiți nume de domenii mai frumoase ale altora :-). Puteți vedea un exemplu de astfel de domeniu mai jos.

Pe scurt, AD vă permite să aveți un singur punct de administrare pentru toate resursele publicate. AD se bazează pe standardul de denumire X.500, folosește sistemul de nume de domeniu (DNS) pentru a determina locația și folosește protocolul LDAP (Lightweight Directory Access Protocol) ca protocol principal.

AD combină structura logică și fizică a unei rețele. Structura logică AD constă din următoarele elemente:

• unitate organizationala – un subgrup de calculatoare, care reflectă de obicei structura companiei;
• domeniu – un grup de calculatoare care partajează o bază de date de directoare comună;
• arborele domeniului – unul sau mai multe domenii care partajează un spațiu de nume contiguu;
• pădure de domeniu – unul sau mai mulți arbori care partajează informații despre director.

Structura fizică include următoarele elemente:

• subrețea – un grup de rețea cu o zonă de adresă IP specificată și o mască de rețea;
• site-ul – una sau mai multe subrețele. Site-ul este folosit pentru a configura accesul la director și pentru replicare.

Directorul stochează trei tipuri de informații: date de domeniu, date de schemă și date de configurare. AD folosește numai controlere de domeniu. Datele de domeniu sunt replicate tuturor controlerelor de domeniu. Toți controlorii de domeniu au drepturi egale, de exemplu. toate modificările făcute de la orice controler de domeniu vor fi replicate tuturor celorlalte controlere de domeniu. Schema și datele de configurare sunt replicate în toate domeniile arborelui sau pădurii. În plus, toate obiectele de domeniu individuale și unele proprietăți ale obiectelor din pădure sunt replicate în catalogul global (GC). Aceasta înseamnă că controlerul de domeniu stochează și replică schema pentru un arbore sau o pădure, informații de configurare pentru toate domeniile din arbore sau pădure și toate obiectele și proprietățile directorului pentru propriul domeniu.

Controlerul de domeniu pe care este stocat GC conține și replică informații despre schemă pentru pădure, informații de configurare pentru toate domeniile din pădure și un set limitat de proprietăți pentru toate obiectele director din pădure (care este replicată numai între serverele GC), și toate obiectele și proprietățile directorului pentru domeniul dvs.

Controlerele de domeniu pot avea roluri diferite de master operațiuni. Masterul de operațiuni se ocupă de sarcini care sunt incomod de efectuat într-un model de replicare multi-master.

Există cinci roluri de master operațiuni care pot fi atribuite unuia sau mai multor controlere de domeniu. Unele roluri trebuie să fie unice la nivel de pădure, altele la nivel de domeniu.

Următoarele roluri există în fiecare pădure AD:

• Schema master – Gestionează actualizările și modificările schemei de director. Pentru a actualiza o schemă de director, trebuie să aveți acces la masterul schemei. Pentru a determina care server este în prezent proprietarul schemei din domeniu, trebuie să tastați comanda în fereastra liniei de comandă dsquery server -hasfsmo schema
• Maestru de nume de domeniu – gestionează adăugarea și îndepărtarea de domenii în pădure. Pentru a adăuga sau elimina un domeniu, aveți nevoie de acces la masterul de denumire a domeniului. Pentru a determina care server este în prezent masterul de denumire a domeniului, introduceți dsquery server -hasismo name în fereastra Command Prompt

Aceste roluri sunt comune întregii păduri ca întreg și sunt unice pentru aceasta.

Fiecare domeniu AD trebuie să aibă următoarele roluri:

• Master ID relativ – alocă identificatori relativi controlorilor de domeniu. De fiecare dată când un utilizator, un grup sau un obiect computer este creat, controlorii atribuie obiectului un identificator de securitate unic, constând dintr-un identificator de securitate de domeniu și un identificator unic care a fost alocat de către masterul de identificare relativ. Pentru a determina care server este în prezent stăpânul ID-urilor de domeniu relative, la promptul de comandă, introduceți dsquery server -hasfsmo rid
• Emulator PDC – În modul de domeniu mixt sau intermediar, acționează ca un controler de domeniu principal Windows NT. Acesta autentifică login-urile Windows, se ocupă de modificările parolei și replică actualizările BDC, dacă există. Pentru a determina care server este în prezent emulatorul PDC al domeniului, introduceți dsquery server -hasfsmo pdc la promptul de comandă
• Maestru de infrastructură – actualizează legăturile obiectelor comparând datele din catalog cu datele GC. Dacă datele sunt învechite, solicită actualizări de la GC și le reproduce controlorilor de domeniu rămași. Pentru a determina care server este în prezent maestru al infrastructurii domeniului, la promptul de comandă, introduceți dsquery server -hasfsmo infr

Aceste roluri sunt comune întregului domeniu și trebuie să fie unice în cadrul acestuia.

Rolurile de master operațiuni sunt atribuite automat primului controler din domeniu, dar pot fi reatribuite de dvs. ulterior. Dacă există un singur controler într-un domeniu, atunci acesta îndeplinește toate rolurile de master operațiuni simultan.

Nu este recomandat să separați rolurile de maestru de schemă și de maestru de denumire a domeniului. Dacă este posibil, atribuiți-le aceluiași controler de domeniu. Pentru o eficiență maximă, este de dorit ca masterul ID relativ și emulatorul PDC să fie, de asemenea, pe același controler, deși aceste roluri pot fi separate dacă este necesar. Într-o rețea mare în care sarcinile grele reduc performanța, masterul relativ ID și emulatorul PDC ar trebui să fie plasate pe controlere diferite. În plus, nu este recomandat să găzduiți masterul infrastructurii pe controlerul de domeniu care stochează catalogul global.

Instalarea unui controler de domeniu (DC) bazat pe Windows Server 2003 utilizând Expertul de configurare Active Directory

Controlerul de domeniu este instalat utilizând Expertul de instalare Active Directory. Pentru a promova un server la un controler de domeniu, trebuie să vă asigurați că sunt îndeplinite toate cerințele necesare:

1. Serverul trebuie să aibă cel puțin o partiție NTFS pentru a găzdui volumul de sistem SYSVOL.
2. Serverul trebuie să aibă acces la serverul DNS. Este recomandabil să instalați serviciul DNS pe același server. Dacă se utilizează un server separat, trebuie să vă asigurați că acesta acceptă înregistrările de resurse Locație serviciu (RFC 2052) și protocolul Actualizări dinamice (RFC 2136).
3. Trebuie să aveți un cont cu drepturi de administrator local pe server.

Să aruncăm o privire mai atentă la promovarea rolului unui server la un controler de domeniu Active Directory pas cu pas:

Noțiuni de bază pentru gestionarea domeniului Active Directory

O serie de instrumente din snap-in-ul Microsoft Management Console (MMC) facilitează lucrul cu Active Directory.

Complementul Active Directory Users and Computers este un MMC pe care îl puteți utiliza pentru a administra și a publica informații despre director. Este principalul instrument administrativ pentru Active Directory și este folosit pentru a îndeplini toate sarcinile legate de utilizatori, grupuri și computere, precum și pentru a gestiona unitățile organizaționale.

Pentru a lansa snap-in-ul (Utilizatori și computere Active Directory), selectați comanda cu același nume din meniul Instrumente administrative.

În mod implicit, consola Active Directory Users and Computers funcționează cu domeniul căruia îi aparține computerul. Puteți accesa computer și obiecte utilizator din acest domeniu prin arborele consolei sau vă puteți conecta la un alt domeniu. Instrumentele din aceeași consolă vă permit să vizualizați parametri suplimentari ai obiectului și să le căutați.

După ce ați obținut acces la domeniu, veți vedea un set standard de foldere:

• Interogări salvate (Interogări salvate) – criterii de căutare salvate care vă permit să repetați rapid o căutare efectuată anterior în Active Directory;
• incorporat – lista de conturi de utilizator încorporate;
• Calculatoare – container implicit pentru conturile de calculator;
• Controlere de domeniu – container implicit pentru controlere de domeniu;
• ForeignSecurityPrincipals – conține informații despre obiecte dintr-un domeniu extern de încredere. De obicei, aceste obiecte sunt create atunci când un obiect dintr-un domeniu extern este adăugat la grupul de domenii curent;
• Utilizatori – container implicit pentru utilizatori.

Unele foldere din consolă nu sunt afișate implicit. Pentru a le afișa, selectați Funcții avansate din meniul Vizualizare. Acestea sunt folderele suplimentare:

• Pierdut si gasit – proprietar pierdut, obiecte de catalog;
• Cotele NTDS – date privind cotele serviciului de agendă;
• Date program – Date stocate în serviciul director pentru aplicațiile Microsoft;
• Sistem – parametrii sistemului încorporați.

Puteți adăuga în mod independent foldere pentru unitățile organizaționale în arborele AD.

Să ne uităm la un exemplu de creare a unui cont de utilizator de domeniu. Pentru a crea un cont de utilizator, faceți clic dreapta pe containerul în care doriți să plasați contul de utilizator, selectați Nou din meniul contextual, apoi selectați Utilizator. Se va deschide fereastra New Object – User wizard:

1. Introduceți prenumele, inițiala și numele utilizatorului în câmpurile corespunzătoare. Veți avea nevoie de aceste informații pentru a crea numele afișat al utilizatorului.
2. Editează-ți numele complet. Trebuie să fie unic în cadrul domeniului și să nu aibă mai mult de 64 de caractere.
3. Introduceți numele dvs. de conectare. Utilizați lista derulantă pentru a selecta domeniul cu care va fi asociat contul.
4. Dacă este necesar, schimbați numele de utilizator de conectare pe sistemele care rulează Windows NT 4.0 sau o versiune anterioară. În mod implicit, primele 20 de caractere ale numelui complet al utilizatorului sunt folosite ca nume de conectare pentru sistemele care rulează versiuni anterioare de Windows. Acest nume trebuie să fie, de asemenea, unic în cadrul domeniului.
5. Clic Următorul. Furnizați o parolă pentru utilizator. Setările sale ar trebui să se potrivească cu politica dvs. de parole;
   Confirmare parolă – câmp folosit pentru a confirma că parola introdusă este corectă;
   Utilizatorul trebuie să schimbe parola la următoarea conectare(Solicită schimbarea parolei la următoarea autentificare) – dacă această casetă de selectare este bifată, utilizatorul va trebui să schimbe parola la următoarea autentificare;
   Utilizatorul nu poate schimba parola – dacă această casetă de selectare este bifată, utilizatorul nu poate schimba parola;
   Parola nu expiră niciodată – Dacă această casetă de selectare este bifată, parola pentru acest cont nu va expira niciodată (această setare înlocuiește politica contului de domeniu);
   Contul este dezactivat - Dacă această casetă de selectare este bifată, contul este dezactivat (această opțiune este utilă pentru a dezactiva temporar pe cineva să folosească contul).

Conturile vă permit să stocați informații de contact ale utilizatorului, precum și informații despre participarea la diferite grupuri de domenii, calea profilului, scriptul de conectare, calea folderului de acasă, lista de computere de pe care utilizatorul are permisiunea de a se conecta la domeniu etc.

Scripturile de conectare definesc comenzi care sunt executate de fiecare dată când vă conectați la un sistem. Acestea vă permit să configurați ora sistemului, imprimantele de rețea, căile către unitățile de rețea etc. Scripturile sunt folosite pentru a rula comenzi o singură dată, iar setările de mediu stabilite de scripturi nu sunt salvate pentru utilizare ulterioară. Scripturile de conectare pot fi fișiere de server de script Windows cu extensiile .VBS, .JS și altele, fișiere batch cu extensia .BAT, fișiere batch cu extensia .CMD, programe cu extensia .EXE.

Puteți atribui fiecărui cont propriul folder de acasă pentru stocarea și restaurarea fișierelor utilizator. Majoritatea aplicațiilor deschid folderul de pornire în mod implicit pentru operațiunile de deschidere și salvare a fișierelor, facilitând găsirea datelor de către utilizatori. Pe linia de comandă, folderul principal este directorul curent de pornire. Dosarul principal poate fi localizat fie pe hard disk-ul local al utilizatorului, fie pe o unitate de rețea partajată.

Politicile de grup pot fi aplicate computerelor de domeniu și conturilor de utilizator. Politica de grup simplifică administrarea, oferind administratorilor control centralizat asupra privilegiilor, permisiunilor și capabilităților utilizatorilor și computerelor. Politica de grup vă permite să:

• creați foldere speciale gestionate central, cum ar fi Documentele mele;
• controlați accesul la componentele Windows, resursele de sistem și de rețea, instrumentele panoului de control, desktopul și meniul Start;
• configurați scripturi utilizator și computer pentru a finaliza o sarcină la un moment specificat;
• Configurați politicile pentru parole și blocarea conturilor, auditare, atribuirea drepturilor utilizatorului și securitate.

Pe lângă sarcinile de gestionare a conturilor de utilizatori și a grupurilor, există multe alte sarcini de gestionare a domeniului. Alte instrumente și aplicații servesc acestui scop.

Echipamente Domenii și trusturi Active Directory(Active Directory - domenii și încredere) este folosit pentru a lucra cu domenii, arbori de domenii și păduri de domenii.

Echipamente Site-uri și servicii Active Directory(Active Directory - site-uri și servicii) vă permite să gestionați site-uri și subrețele, precum și replicarea între site-uri.

Pentru a gestiona obiectele AD, există instrumente de linie de comandă care vă permit să efectuați o gamă largă de sarcini administrative:

• Dsadd – adaugă computere, contacte, grupuri, unități organizaționale și utilizatori la Active Directory. Pentru informații de ajutor, tastați dsadd /? , de exemplu dsadd computer/?
• Dsmod – modifică proprietățile computerelor, contactelor, grupurilor, unităților organizaționale, utilizatorilor și serverelor înregistrate în Active Directory. Pentru informații de ajutor, tastați dsmod /? , de exemplu server dsmod /?
• Dsmove – Mută ​​un singur obiect într-o locație nouă dintr-un domeniu sau redenumește obiectul fără a-l muta.
• Dsget – Afișează proprietățile computerelor, contactelor, grupurilor, unităților organizaționale, utilizatorilor, site-urilor, subrețelelor și serverelor înregistrate în Active Directory. Pentru informații de ajutor, tastați dsget /? , de exemplu subrețea dsget /?
• Dquery – caută computere, contacte, grupuri, unități organizaționale, utilizatori, site-uri, subrețele și servere în Active Directory conform criteriilor specificate.
• Dsrm – șterge un obiect din Active Directory.
• Ntdsutil – vă permite să vizualizați informații despre un site, domeniu sau server, să gestionați operațiunile master și să mențineți baza de date Active Directory.

Există și instrumente de asistență Active Directory:

• LDP – Efectuează operațiuni utilizând protocolul LDAP în Administrare Active Directory.
• Răspunde – Gestionează replicarea și își afișează rezultatele într-o interfață grafică.
• Dsacls – Gestionează ACL-uri (liste de control al accesului) pentru obiectele Active Directory.
• Dfsutil – Gestionează sistemul de fișiere distribuit (DFS) și afișează informații despre funcționarea acestuia.
• Dnscmd – Gestionează proprietățile serverelor, zonelor și înregistrărilor de resurse DNS.
• Movetree – Mută ​​obiecte dintr-un domeniu în altul.
• Repadmin – Gestionează replicarea și afișează rezultatele acesteia în fereastra de linie de comandă.
• Sdcbeck – Analizează distribuția, replicarea și moștenirea listelor de control al accesului.
• Sidwalker – Setează ACL-uri pentru obiectele deținute istoric de conturi mutate, șterse sau orfane.
• Netdom – Vă permite să gestionați domenii și relații de încredere din linia de comandă.

După cum puteți vedea din acest articol, combinarea grupurilor de computere în domenii bazate pe Active Directory poate reduce semnificativ costurile sarcinilor administrative prin centralizarea gestionării computerelor de domeniu și a conturilor de utilizator și, de asemenea, vă permite să gestionați în mod flexibil drepturile utilizatorului, securitatea și un o serie de alți parametri. Materiale mai detaliate despre organizarea domeniilor pot fi găsite în literatura de specialitate.

Alegerea unui nume de domeniu nu este o sarcină dificilă, dar, după cum arată viața, destul de des după rularea dcpromo numele de domeniu este generat aleatoriu. Se pare că nu este nimic în neregulă, domeniul funcționează, imprimantele imprimă, 1C se deschide. Dar, din păcate, există o serie de situații în care generarea aleatorie a unui nume, dacă nu funcționează pentru dvs., va adăuga cu siguranță probleme. În această scurtă postare voi încerca să vorbesc despre ce să nu numești domeniile tale și de ce. Deși informațiile sunt binecunoscute, viața reală arată că erorile de denumire sunt pur și simplu endemice. Și deoarece procedura de redenumire a unui domeniu este un IT-sadomaso, este mai bine să faceți totul corect de la început.

1. Situația unu. Nume de domeniu – numededomeniu.local

Probabil cea mai obișnuită opțiune este să folosiți terminația .local sau orice alt domeniu de nivel superior neutilizat de IANA. (a la.msk sau.test sau.loc, etc.) De unde a venit este acum greu de spus, există mai multe opțiuni. Se spune că în 2000, când AD a apărut la o conferință într-o demonstrație, vorbitorul a făcut un astfel de domeniu.
Ei bine, oamenii au considerat asta ca pe un îndemn la acțiune. A doua ipoteză, deși nu o exclude pe prima, este înclinată către faptul că, cel mai probabil, MSFT însuși a scris clar o recomandare în literatură, după care .local a mers la oameni. De ce este rea această opțiune?

Sunt mai multe scenarii, dar pe cele mai dureroase le voi spune. Să presupunem că instalați Exchange Server în cadrul organizației dvs., care necesită un certificat pentru a cripta conexiunile client. Vreau certificat de la un centru comercial, totul e ca la oameni. Desigur, certificatul trebuie să indice toate numele serverelor prin care serverul va fi accesibil. Și dacă domeniul extern ne aparține și poate trece cu ușurință validarea, atunci domeniul intern a la super-firma.moscow nu există și atunci când încercați să explicați autorităților de certificare că trebuie să introduceți FQDN-ul în SAN - exchange .super-firma.moscow vei primi raspunsul:

Nu este posibil, emitem doar certificate pentru nume de domenii reale.

În acest moment, Comodo Certificate Authority vă permite să introduceți tot felul de cuvinte obscene în SAN-ul unui certificat, ceea ce restrânge semnificativ alegerea furnizorului de certificat și nu există nicio garanție că vor permite acest lucru în viitor.

2. Situația a doua. Numele de domeniu AD este același cu numele domeniului Internet extern.

Aceasta este, de asemenea, o opțiune comună, dar nu va fi nicio problemă cu certificatele. Dar există probleme cu rezolvarea numelor. Acest lucru are ca rezultat o situație în care serverele DNS externe și interne nu sunt conectate între ele, dar în același timp deservesc zone neînrudite cu aceleași nume. Într-o astfel de situație, fiecare server intern se consideră logic autoritar pentru zonă și, dacă nu știe despre nicio gazdă, declară cu autoritate - NU! Deoarece aveți niște resurse externe, cele mai comune site-uri web, în ​​mod natural, înregistrările de tip A sunt adăugate în zona de pe serverul DNS extern. Acum, când un client intern încearcă să rezolve numele unei resurse externe, cererea acestuia va merge la serverul DNS intern (desigur, acesta este un client de domeniu) și va răspunde „Nu știu, nu există așa ceva. lucru și nu trebuie să-l cauți”, pentru că vede că este un server autorizat pentru această zonă.

Pentru a rezolva această problemă, va trebui să înregistrați înregistrări externe în două zone, iar acest lucru va duce inevitabil la confuzie și rutină suplimentară. Dacă acest lucru nu vă deranjează, atunci, în acest scenariu, încercați să permiteți utilizatorilor interni să deschidă site-ul web corporativ fără prefixul www. În general, aceasta este o opțiune proastă și nu ar trebui folosită.

Salutări speciale acelor administratori care și-au numit domeniile interne după domeniile publice celebre ale altor persoane. Cred că nu trebuie să explicați ce fel de hemoroizi aveți în acest caz.

3. Situația trei. Un nume de domeniu plat format dintr-un singur cuvânt.

Dacă primele două opțiuni mai pot fi supraviețuite, atunci este timpul să introduceți sancțiuni administrative pentru numele de domenii fixe. Domeniul cu o singură etichetă (domeniu cu un singur nivel, SLD) este un domeniu care conține o singură componentă nominală. Nu știu de unde a venit mania de a le folosi, dar de mult a fost recunoscut oficial că domeniile SLD nu ar trebui folosite la construirea infrastructurilor IT.

În același timp, această informație este un acordeon atât de canadian încât nu se poate decât să se întrebe de unde provin domeniile SLD. http://support.microsoft.com/kb/300684.

Care este amenințarea? Lipsa suportului din partea produselor Microsoft pentru această configurație. Din proaspăt. Încercați să instalați Exchange 2010 SP1 pe un domeniu cu nume plat și primiți un mesaj că această configurație nu mai este acceptată.

Cum să denumești corect un domeniu?

Răspunsul este simplu. Creați un spațiu de nume consistent. Adică, având un domeniu de site în lumea reală, faceți din domeniul Active Directory un subdomeniu precum corp.site. În această situație, toate problemele dispar. Și nu este deloc necesar să delegați DNS-ul unui subdomeniu unui server DNS extern. Deși, dacă faceți acest lucru, puteți obține rezoluția numelui în ambele sensuri. (din rețeaua internă a numelor externe, din internetul numelor interne)

Pentru cei care nu au crezut inițial că există un link „bun”: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx O seară plăcută citind această lucrare.

MCP/MCT Ilya Rud