Lokalt domännamn. Förstå Active Directory-domäner


I sällsynta fall kan en domäntjänstadministratör ställas inför uppgiften att byta namn på den aktuella domänen. Orsakerna kan vara olika, men en sådan situation är fullt möjlig. Trots att denna uppgift inte kan kallas trivial, men ibland måste du ta itu med det, är det extremt viktigt att göra allt korrekt, eftersom resultatet av händelser annars kan vara kritiskt farligt, upp till en helt icke-funktionell företagsinfrastruktur. Så senare i den här artikeln kommer du att lära dig om förutsättningarna för denna operation, några begränsningar och hur du kan byta namn på din domän. Innan vi börjar, en stark begäran: utför inte dessa steg i din produktionsmiljö förrän du framgångsrikt har bytt namn på din testdomän i din labbmiljö. Låt oss börja.

Förutsättningar

Innan du börjar byta namn på din domän bör du tänka på följande information:

  • Active Directory skog funktionsnivå. Du kan endast utföra domänbyteuppgifter om alla domäner i skogen är utrustade med åtminstone operativsystemet Windows Server 2003 (i det här fallet finns det inga begränsningar för utgåvor). Dessutom måste funktionsnivån höjas till åtminstone nivån för Windows Server 2003. Det vill säga, om du har valt Windows Server 2000 funktionsnivå i din skog, kommer följande operation helt enkelt att bli omöjlig;
  • Domänplats. En Active Directory-skog kan ha olika nivåer av domäner. Det vill säga, det kan antingen finnas en separat domän, eller så kan skogen inkludera underordnade domäner. Om du ändrar platsen för domänkontrollanten i skogen måste du skapa en förtroenderelation;
  • DNS-zon. Redan innan du utför domänbyteoperationen måste du skapa en ny DNS-zon;
  • Administrativa meriter. För att utföra en domänbyteoperation måste du vara inloggad med ett administrativt konto som är medlem i gruppen Enterprise Admins;
  • Distributed File System (DFS) servrar. Om du har distribuerat DFS-tjänster eller konfigurerat roamingprofiler i din företagsmiljö, observera att DFS-rotservrarna måste köra, som ett minimum, Windows Server 2000 SP3 eller högre operativsystem;
  • Inkompatibilitet med Microsoft Exchange-servrar. Det mest obehagliga ögonblicket är att om en Microsoft Exchange Server 2003 Service Pack 1-e-postserver är utplacerad i din Active Directory-skog, kommer domänbytet att utföras utan problem, men det användarkonto under vilket själva domänbyteprocessen kommer att utföras måste vara medlem i gruppen Full Exchange Administrator. Alla nyare e-postservrar (inklusive Exchange Server 2016) är inte kompatibla med domänbyteoperationer.

Observera också att medan du byter namn på domänen måste du frysa alla kommande Active Directory-skogskonfigurationsaktiviteter. Med andra ord måste du se till att din skogskonfiguration inte ändras förrän domänbyteoperationen är helt slutförd (du kommer att se detaljerad information om hur du utför denna åtgärd nedan). Dessa operationer inkluderar: skapa eller ta bort domäner i din Active Directory-skog, skapa eller ta bort applikationskatalogpartitioner, lägga till eller ta bort domänkontrollanter i skogen, skapa eller ta bort ett direkt etablerat förtroende och lägga till eller ta bort attribut som kommer att replikeras till den globala katalog.

För säkerhets skull skulle jag också råda dig att göra en fullständig säkerhetskopia av systemtillståndet på varje domänkontrollant i Active Directory-skogen. Om denna uppgift utförs kommer denna försiktighetsåtgärd definitivt inte att vara överflödig.

Om din infrastruktur uppfyller de ovan nämnda kraven och alla nödvändiga säkerhetskopior har gjorts, kan du börja byta namn på domänen.

Process för att byta namn på Active Directory-domän

Först, för att kontrollera det ursprungliga namnet på din domän, kan du öppna fönstret för systemegenskaper. Som du kan se i motsvarande illustration heter min domän "Biopharmaceutic.local":

Ris. 1. Kontrollera det ursprungliga Active Directory-domännamnet

Nu bör du skapa en ny DNS-zon "biopharm.local" så att dina medlemsservrar och klienter enkelt kan ansluta sig till det nya domännamnet efter att domänbytet har slutförts. För att göra detta, öppna " DNS Manager» ( DNS Manager) och vara i " Direkt visningsområde» ( Framåtsökningszon) välj alternativet för att skapa en ny zon. I huvudsak skapas zonen som vanligt: ​​på den första sidan av guiden New Zone, läs den inledande informationen och gå vidare till den andra sidan. På sidan för zontyp väljer du den primära zonen ( Primär zon) och se till att alternativet att spara zonen i Active Directory är aktiverat. På sidan för zonreplikeringsomfång bör du lämna standardalternativet markerat - " För alla DNS-servrar som körs på domänkontrollanter i denna domän: Biopharmaceutic.local» ( Till alla DNS-servrar som körs på domänkontrollanter i denna domän: Biopharmaceutic.local). På sidan med zonnamn bör du ange det nya domännamnet (biopharm.local), och på sidan för dynamisk uppdatering, lämna även alternativet " Tillåt endast säkra dynamiska uppdateringar (rekommenderas för Active Directory)» ( Tillåt endast säkra dynamiska uppdateringar (rekommenderas för Active Directory)), som är valt som standard. Du kan se flera steg för att skapa en ny zon nedan:

Ris. 2. Skapa en ny DNS-zon

Nästa steg i att byta namn på domänen är att generera en beskrivning av skogens nuvarande tillstånd. I huvudsak är detta den första domänbyteoperationen som kommer att använda ett kommandoradsverktyg Rendom. Detta verktyg genererar en textbeskrivning av din nuvarande skogsstruktur i form av en XML-fil med namnet Domainlist.xml. Den här filen innehåller en lista över alla domänkatalogpartitioner samt programkatalogpartitioner som finns i din Active Directory-skog. Varje post för varje domän och programkatalogpartition avgränsas av XML-taggar Och. Dessutom innehåller varje post data som inkluderar den globalt unika objektidentifieraren (GUID) för partitionens rotobjekt, DNS-namnet på domänen eller applikationskatalogen och NetBIOS-namnet för domänen.

För att skapa en sådan fil, öppna en kommandotolk under lämpligt konto och kör kommandot " slumpmässig/lista" Den genererade filen kommer att sparas i rotkatalogen på ditt användarkonto. Därefter måste du öppna den här filen med valfri textredigerare.

Inuti den här filen måste du ändra domännamnet i avsnittet som begränsas av taggar Och och NetBIOS-namnet inuti taggarna Och). Var noga med att notera att du inte bör ändra GUID inuti motsvarande taggar.

I följande illustration kommer du att se processen för att utföra kommandot ovan, platsen för filen Domainlist.xml och ändringarna av den första delen av filen. I mitt fall kommer domännamnet i denna konfiguration att ändras 4 gånger:

Ris. 3. Generera och ändra filen Domainlist.xml

För att säkerställa att du har gjort de nödvändiga ändringarna i lämplig fil kan du köra kommandot " rendom/showforest" Som du kan se i följande illustration har alla mina poster ändrats till "Bopharm":

Ris. 4. Visa potentiella ändringar

När du kör följande kommando ( rendera/ladda upp) verktyget Rendom översätter den nya skogsstrukturen som anges i den redigerade filen till en sekvens av instruktioner för kataloguppdatering som kommer att köras lokalt och på distans på varje domänkontrollant i skogen. Generellt sett kommer ändringar att göras i katalogsektionen i Domännamnsguidens konfiguration för att byta namn på Active Directory-domänen. Dessutom kommer en Dclist.xml-fil att skapas, som används för att spåra framsteg och status för varje domänkontrollant i skogen för domänbyteoperationen. Förresten, vid det här laget fryser Rendom-verktyget din Active Directory-skog från att göra några ändringar i dess konfiguration. Processen att utföra detta kommando är synlig nedan:

Ris. 5. Utför kommandot rendom /upload

Följande kommando körs för att kontrollera domänkontrollanternas beredskap innan domänbyteoperationen. Under detta steg måste du köra kommandot förberedande kontroll på varje domänkontrollant i skogen. Detta för att säkerställa att Active Directory-databasen på varje domänkontrollant i skogen är i rätt tillstånd och är redo att göra ändringar som gör att du kan byta namn på din domän. Kör därför kommandot " överlämna/förbereda", som visas i följande illustration:

Ris. 6. Förbereder domänen för att döpa om

Det mest avgörande ögonblicket. Utför kommandot " rendera /köra" När detta kommando körs på en domän exekveras instruktioner för att byta namn på domänen. I grund och botten, just nu, kontaktas varje domänkontrollant i skogen individuellt, vilket får varje domänkontrollant att utföra instruktionerna för domänbyte. När denna operation har slutförts kommer varje domänkontrollant att startas om. Se följande illustration för processen att byta namn på en domän:

Ris. 7. Process för att byta namn på domän

Men det är inte allt. Även om din domän i stort sett redan har bytt namn, har du fortfarande uppgiften att fixa GPO:erna och deras länkar efter att domänbyte-operationen är klar. Använd ett kommandoradsverktyg för att återställa grupprincipobjekt samt GPO-länkar i varje omdöpt domän Gpfixup.exe. Denna procedur bör inte försummas på grund av det faktum att utan dess användning, efter att ha slutfört domänbyteoperationen i den nya skogen, kommer grupppolicyer helt enkelt inte att fungera korrekt. Observera att detta kommando måste köras en gång på varje omdöpt domän. Kör därför kommandot en gång gpfixup med parametrar /olddns:Biopharmaceutic.local(det gamla namnet på domänen du döpte om) och /newdns:Biopharm.local(nytt namn på den omdöpta domänen), och sedan kommandot gpfixup med parametrar /oldnb:Biofarmaceutiskt Och /newnb:Biopharm(det gamla och det nya NETBIOS-namnet på din domän). Denna procedur visas nedan:

Ris. 8. Åtgärda grupprincipobjekt

Det finns bara två kommandon kvar att utföra: kommandot " rendom/rengör", som låter dig ta bort alla referenser till gamla domännamn i din Active Directory, samt kommandot " rendom/slut", i huvudsak frigör Active Directory-skogen från att göra ändringar i dess konfiguration. Du kan se processen för att utföra dessa kommandon i följande illustration:

Ris. 9. Fyll i Active Directory-domänbytet

För att ändringarna ska gälla för medlemsservrar och slutklienter måste du starta om deras datorer två gånger. Du måste dock byta namn på domänkontrollanterna manuellt. Som du kan se i följande illustration förblir mitt domänkontrollantnamn detsamma.

Denna procedur är mycket mer komplicerad än att byta namn på en medlemsserver som är en vanlig medlem av en domän. För denna uppgift behöver vi verktyget " NETDOM", som börjar från Windows 2008 ingår i OS, och för Windows 2003 kommer behöva installera" Supportverktyg ".

Gör så här för att byta namn på en domänkontrollant:
1. Se först till att domänens funktionsnivå inte är lägre Windows 2003 och kolla efter behörigheter" Domänadministratörer " ("Domänadministratörer ").
2. Öppna en förhöjd kommandotolk och lägg till ett extra namn för den styrenhet som vi ska byta namn på (i vårt exempel SRV-DC1-GAMMEL.TEST.LOKALT byta namn till SRV-DC1.TEST.LOKALT ):

NETDOM datornamn SRV-DC1-OLD.TEST.LOCAL /add:SRV-DC1.TEST.LOCAL


3. Använda redigeraren " ADSIEDIT.msc" se till att namnet läggs till korrekt. I editorn, hitta domänkontrollantobjektet och kontrollera värdet på egenskapen " msDS-AdditionalDnsHostName"som borde vara lika med" SRV-DC1.TEST.LOKALT ".


4. Nu måste du se till att den uppdaterade SPN attributen lyckades replikeras helt till andra domänkontrollanter i skogen. Verktyget kommer att hjälpa oss med detta " READMIN" eller " REPLMON" För Windows 2003.


För att påskynda processen kan replikering tvingas fram i snap-in " DSSITE.msc". Högerklicka helt enkelt på anslutningen och välj " Replikera nu".


5. Gör nu det nya domänkontrollantnamnet till primärt:

NETDOM datornamn SRV-DC1-OLD.TEST.LOCAL /makeprimary:SRV-DC1.TEST.LOCAL


6. Starta om servern.
7. Kontrollera igen att den uppdaterade SPN attribut och poster i DNS lyckades replikera helt till andra domänkontrollanter och servrar DNS i skogen, och fastighetsvärdet" msDS-AdditionalDnsHostName" är nu lika med det gamla servernamnet.


Om det är akut tidsbrist kan du återigen tvinga fram replikering och överbelasta zonerna DNS på andra kontroller om de visar det tidigare namnet på vår server.
8. Nu tar vi bort det gamla kontrollernamnet, som nu är ytterligare:

NETDOM datornamn SRV-DC1.TEST.LOCAL /ta bort:SRV-DC1-OLD.TEST.LOCAL


9. Framtvinga eller vänta på fullständig replikering, och slutligen ladda om och kontrollera framåt- och bakåtdomänzoner DNS för skivor med det gamla namnet. Om vi ​​hittar några raderar vi dem eller korrigerar dem vid behov till ett nytt namn. Det är också värt att kontrollera värdet på attributet " igen. msDS-AdditionalDnsHostName", som måste vara tom.

I slutet av proceduren, när ovanstående steg har slutförts, kontrollera noggrant loggarna Active Directory på alla domänkontrollanter för fel och användning av " DCDIAG”Vi ser till att skogen fungerar som den ska.

Det är 2015, internet har blivit utbrett, varje företag med självrespekt har länge haft sin egen webbplats. Du behöver inte gå långt - även varje stadssjukhus har sina egna webbresurser. Men ändå har systemadministratörer fortfarande inte lärt sig att skapa normala namn för sina domäner.

Kostnaden för en andranivådomän (till exempel bissquit.com) är lite mer än 500 rubel per år. Detta är väldigt lite även för vanliga medborgare som du och jag, och det är bara slantar för företag ännu mer. Jag köpte min domän långt innan idén att starta den här bloggen dök upp. Det är bara bekvämt. Låt oss till och med ta en fjärranslutning via rdp - jag anger mitt domännamn istället för en tråkig IP-adress.

På Internet, på frågan om "bästa praxis för aktiva katalogdomäner", innehåller nästan varje webbplats omfattande rekommendationer för att namnge AD-domäner och ger förklaringar till varför du behöver göra det på detta sätt. Låt oss ta en närmare titt på vilka rekommendationer vi pratar om:

  • För att namnge din AD-domän, använd en underdomän till din organisations officiellt registrerade domän.

Du förstod allt rätt, bara ett råd. Detta är allt! Man kan prata mycket om detaljerna och små nyanser, men 80-90 % av diskussionerna kommer ner på ett enda råd, uttryckt ovan. Alla problem härrör från det faktum att en person vet att detta bör göras, men inte förstår varför det är omöjligt eller starkt rekommenderat att göra det annorlunda. Mer information från och med nu.

1. Varför kan du inte använda interna, externt olösliga namn som .local, .corp, .lan?

Burk. Så mycket som möjligt. De flesta använder dem exakt. Jag har exempel bland vänner vars organisationer har 2000+ personer och använder .local-domänen. Alla svårigheter börjar om du plötsligt behöver en riktig AD-domän. Detta kan hända när du använder hybridmolninstallationer (Exchange + Office365 är ett utmärkt exempel). "Varför inte bara byta namn på domänen, för med en viss version av AD är detta fullt möjligt?" - du frågar. Ja, i princip är det möjligt, men du kommer att behöva möta svårigheterna med att migrera domänberoende tjänster. Bland dem finns samma Exchange och andra, men här räcker enbart Exchange mer än nog.

2. "Okej, låt oss köpa ett riktigt externt namn - my-company.com, och låt oss också kalla domänen AD" är inte heller ett alternativ. Det kommer att finnas problem med att lösa andra resurser som finns på my-company.com, såsom företagets webbplats. Och dessutom kommer dina DNS-servrar inte att vara auktoritativa för denna domän, även om de kommer att betrakta sig själva som sådana. Detta kommer också att orsaka problem.

Det finns andra överväganden när det gäller domännamn, inklusive att skapa en domän som liknar den riktiga men i en annan toppdomän. Men det förefaller mig som att det inte är någon mening med att göra detta, eftersom en del av problemen fortfarande kvarstår, och det finns helt enkelt inga uppenbara fördelar i jämförelse med att använda domänen corp.my-company.com (namnet tas som en exempel).

För den som gillar att göra allt på sitt eget sätt har problem med certifikat nyligen tillkommit, så det är ingen idé att använda interna namn nu alls.

Frågan om att välja ett domännamn beror tekniskt på i vilken rad du anger namnet när du skapar AD-domänen och inget mer. Men konsekvenserna som kommer att följa av att välja fel namn kommer att orsaka dig många problem i framtiden, och därför är det i planeringsstadiet mycket viktigt att göra allt effektivt. Återigen är det en bra idé att läsa artiklar från erfarna administratörer

Kort sagt låter AD dig ha en enda administrationspunkt för alla dina publicerade resurser. AD är baserad på namngivningsstandarden X.500, använder Domain Name System (DNS) för att bestämma plats och använder Lightweight Directory Access Protocol (LDAP) som sitt primära protokoll.

AD kombinerar den logiska och fysiska strukturen i ett nätverk. AD logiska strukturen består av följande element:

  • organisatorisk enhet – en undergrupp av datorer som vanligtvis återspeglar företagets struktur.
  • domän – en grupp datorer som delar en gemensam katalogdatabas;
  • domänträd – en eller flera domäner som delar ett sammanhängande namnområde;
  • domänskog – ett eller flera träd som delar kataloginformation.

Den fysiska strukturen innehåller följande element:

  • subnät – en nätverksgrupp med ett specificerat IP-adressområde och nätverksmask;
  • webbplats – ett eller flera undernät. Webbplatsen används för att konfigurera åtkomst till katalogen och för replikering.

Katalogen lagrar tre typer av information: domändata, schemadata och konfigurationsdata. AD använder endast domänkontrollanter. Domändata replikeras till alla domänkontrollanter. Alla domänkontrollanter har lika rättigheter, d.v.s. alla ändringar som görs från en domänkontrollant kommer att replikeras till alla andra domänkontrollanter. Schemat och konfigurationsdata replikeras över alla domäner i trädet eller skogen. Dessutom replikeras alla individuella domänobjekt och vissa skogsobjektegenskaper till den globala katalogen (GC). Detta innebär att domänkontrollanten lagrar och replikerar schemat för ett träd eller en skog, konfigurationsinformation för alla domäner i trädet eller skogen och alla katalogobjekt och egenskaper för sin egen domän.

Domänkontrollanten som GC:n lagras på innehåller och replikerar schemainformation för skogen, konfigurationsinformation för alla domäner i skogen och en begränsad uppsättning egenskaper för alla katalogobjekt i skogen (som endast replikeras mellan GC-servrar), och alla katalogobjekt och egenskaper för din domän.

Domänkontrollanter kan ha olika operationsmasterroller. Operationsmastern hanterar uppgifter som är obekväma att utföra i en multimasterreplikeringsmodell.

Det finns fem operationsmasterroller som kan tilldelas en eller flera domänkontrollanter. Vissa roller måste vara unika på skogsnivå, andra på domännivå.

Följande roller finns i varje AD-skog:

  • Schema master – Hanterar uppdateringar och ändringar av katalogschema. För att uppdatera ett katalogschema måste du ha tillgång till schemamastern. För att avgöra vilken server som för närvarande är ägare till schemat i domänen, måste du skriva kommandot i kommandoradsfönstret dsquery server -hasfsmo schema
  • Domännamnmästare – sköter till- och borttagning av domäner i skogen. För att lägga till eller ta bort en domän behöver du tillgång till domännamnsmastern. För att avgöra vilken server som för närvarande är domännamnsmaster, skriv in dsquery server -hasismo name i kommandotolksfönstret

Dessa roller är gemensamma för hela skogen som helhet och är unika för den.

Varje AD-domän måste ha följande roller:

  • Relativ ID-mästare – tilldelar relativa identifierare till domänkontrollanter. Varje gång en användare, grupp eller datorobjekt skapas, tilldelar styrenheter objektet en unik säkerhetsidentifierare, bestående av en domänsäkerhetsidentifierare och en unik identifierare som har tilldelats av den relativa identifierarmästaren. För att avgöra vilken server som för närvarande är master för relativa domän-ID:n, vid kommandotolken anger du dsquery server -hasfsmo rid
  • PDC-emulator – I blandat eller mellanliggande domänläge, fungerar som en Windows NT-huvuddomänkontrollant. Det autentiserar Windows-inloggningar, hanterar lösenordsändringar och replikerar uppdateringar till BDC om några. För att avgöra vilken server som för närvarande är domänens PDC-emulator, skriv in dsquery server -hasfsmo pdc vid kommandotolken
  • Infrastrukturmästare – uppdaterar objektlänkar genom att jämföra dess katalogdata med GC-data. Om uppgifterna är inaktuella begär den uppdateringar från GC och replikerar dem till de återstående domänkontrollanterna. För att avgöra vilken server som för närvarande är master över domäninfrastrukturen, vid kommandotolken, skriv in dsquery server -hasfsmo infr

Dessa roller är gemensamma för hela domänen och måste vara unika inom den.

Operationsmasterroller tilldelas automatiskt till den första kontrollern i domänen, men kan omtilldelas av dig senare. Om det bara finns en kontroller i en domän, utför den alla operationer som huvudroller samtidigt.

Det rekommenderas inte att separera rollerna som schemamästare och domännamnmästare. Om möjligt, tilldela dem till samma domänkontrollant. För maximal effektivitet är det önskvärt att den relativa ID-mastern och PDC-emulatorn också finns på samma styrenhet, även om dessa roller kan separeras vid behov. I ett stort nätverk där tunga belastningar minskar prestandan bör den relativa ID-mastern och PDC-emulatorn placeras på olika kontroller. Dessutom rekommenderas det inte att vara värd för infrastrukturmastern på domänkontrollanten som lagrar den globala katalogen.

Installera en Windows Server 2003-baserad domänkontrollant (DC) med hjälp av Active Directory Setup Wizard

Domänkontrollanten installeras med hjälp av Active Directory Installation Wizard. För att uppgradera en server till en domänkontrollant måste du se till att alla nödvändiga krav är uppfyllda:

  1. Servern måste ha minst en NTFS-partition för att rymma SYSVOL-systemvolymen.
  2. Servern måste ha tillgång till DNS-servern. Det är lämpligt att installera DNS-tjänsten på samma server. Om en separat server används måste du se till att den stöder Service Location-resursposter (RFC 2052) och Dynamic Updates-protokollet (RFC 2136).
  3. Du måste ha ett konto med lokala administratörsrättigheter på servern.

Låt oss ta en närmare titt på hur man främjar rollen som en server till en Active Directory-domänkontrollant steg för steg:

Grunderna för Active Directory Domain Management

Ett antal verktyg i snapin-modulen Microsoft Management Console (MMC) gör det enklare att arbeta med Active Directory.

Snap-in-modulen Active Directory Users and Computers är en MMC som du kan använda för att administrera och publicera kataloginformation. Det är det huvudsakliga administrativa verktyget för Active Directory och används för att utföra alla uppgifter relaterade till användare, grupper och datorer, samt för att hantera organisationsenheter.

För att starta snapin-modulen (Active Directory-användare och datorer), välj kommandot med samma namn på menyn Administrationsverktyg.

Som standard fungerar Active Directory Users and Computers-konsolen med den domän som din dator tillhör. Du kan komma åt dator- och användarobjekt i den här domänen via konsolträdet eller ansluta till en annan domän. Verktyg i samma konsol låter dig se ytterligare objektparametrar och söka efter dem.

Efter att ha fått åtkomst till domänen kommer du att se en standarduppsättning mappar:

  • Sparade frågor (Sparade frågor) – sparade sökkriterier som gör att du snabbt kan upprepa en tidigare utförd sökning i Active Directory;
  • inbyggt – lista över inbyggda användarkonton;
  • Datorer – standardbehållare för datorkonton;
  • Domänkontrollanter – standardbehållare för domänkontrollanter;
  • Utländska säkerhetshuvudmän – innehåller information om objekt från en betrodd extern domän. Vanligtvis skapas dessa objekt när ett objekt från en extern domän läggs till i den aktuella domängruppen;
  • Användare – standardbehållare för användare.

Vissa konsolmappar visas inte som standard. För att visa dem, välj Avancerade funktioner från menyn Visa. Det här är de extra mapparna:

  • LostAndFound – förlorad ägare, katalogobjekt;
  • NTDS-kvoter – Uppgifter om katalogtjänstkvoter.
  • Programdata – Data som lagras i katalogtjänsten för Microsoft-applikationer;
  • Systemet – inbyggda systemparametrar.

Du kan självständigt lägga till mappar för organisationsenheter till AD-trädet.

Låt oss titta på ett exempel på hur du skapar ett domänanvändarkonto. För att skapa ett användarkonto, högerklicka på behållaren där du vill placera användarkontot, välj Nytt från snabbmenyn och välj sedan Användare. Fönstret New Object – User Wizard öppnas:

  1. Ange användarens förnamn, initial och efternamn i lämpliga fält. Du behöver denna information för att skapa användarens visningsnamn.
  2. Redigera ditt fullständiga namn. Den måste vara unik inom domänen och inte vara mer än 64 tecken lång.
  3. Ange ditt inloggningsnamn. Använd rullgardinsmenyn för att välja den domän som kontot ska kopplas till.
  4. Om det behövs, ändra ditt inloggningsanvändarnamn på system som kör Windows NT 4.0 eller tidigare. Som standard används de första 20 tecknen i användarens fullständiga namn som inloggningsnamn för system som kör tidigare versioner av Windows. Detta namn måste också vara unikt inom domänen.
  5. Klick Nästa. Ange ett lösenord för användaren. Dess inställningar bör matcha din lösenordspolicy;
    Bekräfta lösenord – fält som används för att bekräfta att det angivna lösenordet är korrekt;
    Användaren måste byta lösenord vid nästa inloggning(Kräv lösenordsändring vid nästa inloggning) – om den här kryssrutan är markerad måste användaren ändra lösenordet vid nästa inloggning;
    Användaren kan inte ändra lösenordet – om den här kryssrutan är markerad kan användaren inte ändra lösenordet;
    Lösenordet upphör aldrig – Om den här kryssrutan är markerad kommer lösenordet för det här kontot aldrig att upphöra att gälla (denna inställning åsidosätter domänkontopolicyn);
    Kontot är inaktiverat - Om den här kryssrutan är markerad är kontot inaktiverat (det här alternativet är användbart för att tillfälligt inaktivera någon från att använda kontot).

Konton låter dig lagra användarens kontaktinformation, samt information om deltagande i olika domängrupper, profilsökväg, inloggningsskript, hemmappssökväg, lista över datorer från vilka användaren får logga in på domänen, etc.

Inloggningsskript definierar kommandon som körs varje gång du loggar in på ett system. De låter dig konfigurera systemtid, nätverksskrivare, sökvägar till nätverksenheter, etc. Skript används för att köra kommandon en gång, och miljöinställningarna som ställs in av skripten sparas inte för senare användning. Inloggningsskript kan vara Windows-skriptserverfiler med tilläggen .VBS, .JS och andra, batchfiler med tillägget .BAT, batchfiler med tillägget .CMD, program med tillägget .EXE.

Du kan tilldela varje konto sin egen hemmapp för att lagra och återställa användarfiler. De flesta applikationer öppnar hemmappen som standard för att öppna och spara filer, vilket gör det lättare för användare att hitta sina data. På kommandoraden är hemmappen den aktuella startkatalogen. Hemmappen kan finnas antingen på användarens lokala hårddisk eller på en delad nätverksenhet.

Grupppolicyer kan tillämpas på domändator och användarkonton. Grupprincip förenklar administrationen genom att ge administratörer centraliserad kontroll över privilegier, behörigheter och möjligheter för användare och datorer. Med grupppolicy kan du:

  • skapa centralt hanterade specialmappar, såsom Mina dokument;
  • kontrollera åtkomst till Windows-komponenter, system- och nätverksresurser, kontrollpanelverktyg, skrivbordet och Start-menyn;
  • konfigurera användar- och datorskript för att slutföra en uppgift vid en angiven tidpunkt;
  • Konfigurera policyer för lösenord och kontolås, revision, tilldelning av användarrättigheter och säkerhet.

Utöver uppgifterna att hantera användarkonton och grupper, finns det många andra domänhanteringsuppgifter. Andra verktyg och applikationer tjänar detta syfte.

Utrustning Active Directory-domäner och -förtroende(Active Directory - domäner och förtroende) används för att arbeta med domäner, domänträd och domänskogar.

Utrustning Active Directory-webbplatser och tjänster(Active Directory - webbplatser och tjänster) låter dig hantera webbplatser och undernät, såväl som replikering mellan webbplatser.

För att hantera AD-objekt finns det kommandoradsverktyg som låter dig utföra ett brett utbud av administrativa uppgifter:

  • Dsadd – lägger till datorer, kontakter, grupper, organisationsenheter och användare till Active Directory. För hjälpinformation, skriv dsadd /? , till exempel dsadd dator/?
  • Dsmod – ändrar egenskaperna för datorer, kontakter, grupper, organisationsenheter, användare och servrar registrerade i Active Directory. För hjälpinformation, skriv dsmod /? , till exempel dsmod server /?
  • Dsmove – Flyttar ett enstaka objekt till en ny plats inom en domän, eller byter namn på objektet utan att flytta det.
  • Dsget – Visar egenskaperna för datorer, kontakter, grupper, organisationsenheter, användare, webbplatser, undernät och servrar registrerade i Active Directory. För hjälpinformation, skriv dsget /? , till exempel dsget subnet /?
  • Dquery – söker efter datorer, kontakter, grupper, organisationsenheter, användare, webbplatser, undernät och servrar i Active Directory enligt angivna kriterier.
  • Dsrm – tar bort ett objekt från Active Directory.
  • Ntdsutil – låter dig se information om en webbplats, domän eller server, hantera operationsmasters och underhålla Active Directory-databasen.

Det finns också Active Directory-stödverktyg:

  • LDP – Utför åtgärder med LDAP-protokollet i Active Directory Administration.
  • Replymon – Hanterar replikering och visar dess resultat i ett grafiskt gränssnitt.
  • Dsacls – Hanterar ACL:er (åtkomstkontrollistor) för Active Directory-objekt.
  • Dfsutil – Hanterar det distribuerade filsystemet (DFS) och visar information om dess funktion.
  • Dnscmd – Hanterar egenskaperna för servrar, zoner och DNS-resursposter.
  • Movetree – Flyttar objekt från en domän till en annan.
  • Repadmin – Hanterar replikering och visar dess resultat i kommandoradsfönstret.
  • Sdcbeck – Analyserar distribution, replikering och nedärvning av åtkomstkontrollistor.
  • Sidwalker – Ställer in ACL:er för objekt som historiskt ägs av flyttade, borttagna eller föräldralösa konton.
  • Netdom – Låter dig hantera domäner och förtroenderelationer från kommandoraden.

Som du kan se i den här artikeln kan en kombination av datorgrupper till domäner baserade på Active Directory minska kostnaderna för administrativa uppgifter avsevärt genom att centralisera hanteringen av domändatorer och användarkonton, och gör det också möjligt för dig att flexibelt hantera användarrättigheter, säkerhet och en mängd andra parametrar. Mer detaljerat material om organisationen av domäner finns i relevant litteratur.

Igår fick vi ett brev till vår studio från vår vanliga läsare Andrey, med frågan:

Jag läser din blogg med nöje, jag lärde mig en massa användbara saker för mig själv, jag ville veta din åsikt om namnet på Active Directory-domänen, många skriver att den ska heta *organisation*.local, och någon skriver att den ska heta samma som domänen.

Låt oss ta en snabb titt på vad som är det bästa namnet att använda när du namnger en domän inom en organisation.

Som praxis visar kan valet av ett domännamn förbrylla även en erfaren systemadministratör. När du startar verktyget för första gången dcpromo Domännamnet kommer att genereras automatiskt och slumpmässigt om domännamnet i detta skede inte överensstämmer med nödvändiga regler, kommer det i framtiden att bli svårare att ändra domännamnet. Låt oss titta på de möjliga alternativen i ordning efter popularitet.

1. Domän med namnet example.local

Ledaren för vår hitparad är domännamnet som slutar med lokal. Det finns andra varianter på detta tema, till exempel testa, firma, fabrik, nn, loc, och så vidare. Nuförtiden kan du inte ens komma ihåg var sådan kärlek kom ifrån i alla sina böcker, Microsoft använder alltid sina egna namn som; contoso.com där vi tydligt ser format för domännamn. Men i nästan 10 år domänen .lokal intog en ledande position. Situationen började förbättras med ankomsten av tjänster som använder SSL-certifikat. Där användningen av "don't care"-domäner blir omöjlig. Titta, låt oss säga att ditt företag använder internt Exchange-server, som kräver ett SSL-certifikat för att kryptera klientanslutningar. Enligt ditt scenario behöver du ett certifikat för att implementera denna uppgift extern certifieringsmyndighet, där du måste ange alla namn på de servrar som används för externa anslutningar. Det verkar som att det som är fel, vi skriver ner alla servernamn och ansöker om utfärdande av certifikat, men det finns en sak. Med namnet på en sådan domän du kommer inte att kunna godkänna valideringen, eftersom domänen "bryr sig inte" inte existerar och om du försöker förklara för en extern certifieringsmyndighet att du behöver lägga in FQDN-namnet för en icke-existerande domän i SAN, kommer du att få ett mjukt avslag:

Det är inte möjligt, vi utfärdar endast certifikat för riktiga domännamn.

Men det finns ett problem till. Användning av domännamn inte din i ett domännamn kan leda till katastrofala konsekvenser. Föreställ dig situationen om zonen lokal kommer att ha offentlig status. Som en zon com eller ru. Jag tycker inte det är värt att fortsätta :)

2. Domännamnet är detsamma som det externa domännamnet

Andra plats i vår schlagerparad. Trots att ett sådant scenario är mindre populärt har det fortfarande rätt till liv. Förutom att du inom en snar framtid fortfarande kommer att uppleva en del besvär när du underhåller nätverket, är det inget annat som hotar dig. Huvudproblemet i det här scenariot är att du måste underhålla två DNS-servrar: inre och yttre. Under detta villkor kommer datorer som finns inuti nätverket att använda den interna DNS-servern för att lösa namn, och datorer utanför företagets omkrets kommer att använda en extern. Låt oss anta att din domän har ett stolt namn exempel.com. I DMZ zon du befinner dig i hemsida företag namnges exempel.com. I scenariot som beskrivs ovan, är datorerna lokaliserade inuti organisationer de kommer inte att kunna komma åt det på grund av att exempel.com är det för dem domän namn och när du anger den här adressen i webbläsaren kommer de att gå till domänkontrollant. Som jag noterade ovan, förutom besvär, kommer detta att leda till ingenting. Du kan alltid använda kryckor som omdirigerar dig till en extern webbplats, men du kommer att acceptera att detta är onödigt dubbelarbete, eller inuti nätverket använd webbplatsens namn som börjar med www, eller utanför.

3. Ett-ords domännamn

Kanske det mest felaktiga alternativet av ovanstående. Ennivådomäner: Domän med en etikettär en domän som endast innehåller en komponent. Tydligen började de användas under NTs dagar, när Microsoft anammade den framgångsrika erfarenheten av Novell. Det hände så att jag till en början var administratör för FreeBSD och en stor flotta av NetWare-servrar från och med version 4.11, och på den tiden använde NetWare Bindery i sitt arbete, vilket är just namnen ennivådomändiagram, som senare antogs av Microsoft.

Bästa metoder

Det är dags att summera det. Vilket domännamn ska jag använda? Endast en tredjenivådomän i den domän du äger. Du ska inte använda andras vackrare domännamn :-). Du kan se ett exempel på en sådan domän nedan.


2024 gtavrl.ru.