Vraag Best practices voor het benoemen van Windows Active Directory?


Dit is een Canonical Question over naamgeving van Active Directory-domeinen.

Na het experimenteren met Windows-domeinen en domeincontrollers in een virtuele omgeving, heb ik me gerealiseerd dat het hebben van een actief directorydomein met de naam identiek aan een DNS-domein een slecht idee is (wat betekent dat example.com als een Active Directory-naam niet goed is als we de example.com domeinnaam geregistreerd voor gebruik als onze website).

Deze gerelateerde vraag lijkt die conclusie te ondersteunen, maar ik weet nog steeds niet zeker welke andere regels er zijn bij het benoemen van Active Directory-domeinen.

Bestaan ​​er praktische tips over wat een Active Directory-naam wel of niet moet zijn?


80
2017-10-21 13:10


oorsprong




antwoorden:


Dit was een leuk gespreksonderwerp over Server Fault. Er lijken verschillende 'religieuze opvattingen' over het onderwerp te bestaan.

Ik ben het eens met de aanbeveling van Microsoft: Gebruik een subdomein van de reeds geregistreerde internetdomeinnaam van het bedrijf.

Dus als je eigenaar bent foo.com, gebruik ad.foo.com of zoiets.

Het meest gemene ding, zoals ik het zie, gebruikt de geregistreerde internetdomeinnaam, letterlijk, voor de Active Directory-domeinnaam. Dit zorgt ervoor dat je gedwongen wordt om handmatig records van internet-DNS te kopiëren (zoals www) in de Active Directory DNS-zone om "externe" namen toe te staan. Ik heb volkomen dwaze dingen gezien als IIS geïnstalleerd op elke DC in een organisatie die een website draait die een redirect uitvoert zodat iemand binnenkomt foo.com in hun browser zou worden omgeleid naar www.foo.com door deze IIS-installaties. Volslagen dwaasheid!

Het gebruik van de internetdomein levert u geen voordelen op, maar creëert elke keer dat u de IP-adressen wijzigt waarnaar externe hostnamen verwijzen, "make work". (Probeer geografisch load-balanced DNS te gebruiken voor de externe hosts en dat te integreren met zo'n "gesplitste DNS" -situatie! Goh, dat zou leuk zijn ...)

Het gebruik van een dergelijk subdomein heeft geen effect op zaken als Exchange e-mailbezorging of UPN-achtervoegsels, BTW. (Ik zie vaak dat beide worden aangehaald als excuses voor het gebruik van de internetdomeinnaam als de AD-domeinnaam.)

Ik zie ook het excuus "veel grote bedrijven doen het". Grote bedrijven kunnen botweg beslissingen net zo makkelijk (zo niet moreso) nemen als kleine bedrijven. Ik koop dat niet alleen omdat een groot bedrijf een slechte beslissing neemt, waardoor het op de een of andere manier een goede beslissing is.


94
2017-10-21 13:16



Maar dan is de NetBIOS-naam van het domein niet ... nou ja, mooi :) corp is niet zo beschrijvend als foo. - Anton Gogolev
U kunt echter elke gewenste NetBIOS-naam toewijzen. Veel van mijn klanten hebben namen als 'ad.example.com', maar de NetBIOS-naam is 'VOORBEELD'. DCPROMO zal u vragen om wat u wilt dat de NetBIOS-naam is tijdens het maken van het domein. - Evan Anderson
als u dit doet, let dan op voor problemen met domeinen die jokertekens hebben. Wanneer u * .foo.com gebruikt, zal host.internal.foo.com het in sommige situaties matchen - JamesRyan
Ik ben niet op de hoogte van een e-mailserverproduct waarvoor u de AD-domeinnaam moet gebruiken als het achtervoegsel van het e-mailadres van de gebruiker. Exchange heeft nooit vereiste enige vorm van correlatie tussen de acht-domeinnaam en e-mailadresachtervoegsels. - Evan Anderson
Office365 vereist alleen dat uw gebruikers zich aanmelden met hun UPN met een achtervoegsel dat overeenkomt met uw tenant-domein. Omdat het standaard Exchange-postbusadresbeleid kan worden gedefinieerd als alles, net als uw UPN-achtervoegsel, is het triviaal. We hebben EXAMPLE.COM als onze bedrijfsnaam (en tenant in Office365), EXAMPLE.NET (ook geregistreerd) als het forest, CORP.EXAMPLE.NET als het primaire accountdomein (met andere regionale subdomeinen, bijvoorbeeld EU.EXAMPLE. NET) met VOORBEELD als de NetBIOS-naam, gebruiken alle gebruikers in de forest-Exchange-organisatie Name@EXAMPLE.COM voor UPN en voor e-mail. Office365 is hier heel blij mee. - Ryan Fisher


Er zijn slechts twee juiste antwoorden op deze vraag.

  1. Een ongebruikt subdomein van een domein dat u openbaar gebruikt. Bijvoorbeeld als uw aanwezigheid op het internet dat is example.com uw interne AD kan zoiets heten ad.example.com of internal.example.com.

  2. Een ongebruikt tweede niveau domein die je bezit en gebruik nergens anders. Bijvoorbeeld als uw aanwezigheid op het internet dat is example.com uw AD kan een naam hebben example.net  zolang je je hebt aangemeld example.net en gebruik het nergens anders!

Dit zijn je enige twee keuzes. Als je iets anders doet, laat je jezelf open voor veel pijn en lijden.


Maar iedereen gebruikt .local!
Maakt niet uit. Dat zou je niet moeten doen. Ik heb geblogd over het gebruik van .local en andere verzonnen TLD's zoals .lan en .corp. In geen geval mag je dit ooit doen.

Het is niet veiliger. Het zijn geen 'best practices' zoals sommige mensen beweren. En dat heeft het niet ieder profiteren van de twee keuzes die ik heb voorgesteld.

Maar ik wil het hetzelfde noemen als de URL van mijn openbare website, zodat mijn gebruikers dat ook zijn example\user in plaats van ad\user
Dit is een geldige, maar misplaatste zorg. Wanneer u de eerste DC in een domein promoot, kunt u de NetBIOS-naam van het domein instellen op wat u maar wilt. Als u mijn advies volgt en uw domein instelt om te zijn ad.example.com, u kunt configureren dat de NetBIOS-naam van het domein dat is example zodat uw gebruikers zich aanmelden als example\user.

In Active Directory-forests en -vertrouwen kunt u ook extra UPN-achtervoegsels maken. Er is niets dat u ervan weerhoudt om @ example.com te maken en in te stellen als het primaire UPN-achtervoegsel voor alle accounts in uw domein. Wanneer u dit combineert met de vorige NetBIOS-aanbeveling, zal geen enkele eindgebruiker ooit zien dat de FQDN van uw domein is ad.example.com. Alles wat ze zien zal zijn example\ of @example.com. De enige mensen die moeten werken met de FQDN zijn de systeembeheerders die werken met Active Directory.

Ga er ook van uit dat u een split-horizon DNS-naamruimte gebruikt, wat betekent dat uw AD-naam dezelfde is als uw openbare website. Nu kunnen uw gebruikers niet komen example.com intern tenzij je ze hebt voorvoegsel www. in hun browser of u voert IIS uit op al uw domeincontrollers (dit is slecht). Je moet ook samenwerken twee niet-identieke DNS-zones die een onafhankelijke naamruimte delen. Het is echt meer gedoe dan het waard is. Stel je nu voor dat je een partnerschap hebt met een ander bedrijf en dat ze ook een DNS-configuratie met gedeelde horizon hebben met hun AD en hun externe aanwezigheid. Je hebt een private glasvezelverbinding tussen beide en je moet een vertrouwensrelatie creëren. Nu moet al uw verkeer naar een van hun openbare sites de privélink doorlopen in plaats van gewoon uit te gaan via internet. Het creëert ook allerlei soorten hoofdbrekens voor de netwerkbeheerders aan beide kanten. Vermijd dit. Geloof me.

Maar dan maar ...
Serieus, er is geen reden om geen van de twee dingen te gebruiken die ik heb voorgesteld. Elke andere manier heeft valkuilen. Ik zeg niet dat je moet haasten om je domeinnaam te wijzigen als deze functioneert en op zijn plek is, maar als je een nieuwe AD maakt, doe dan een van de twee dingen die ik hierboven heb aanbevolen.


87
2018-01-29 16:18



Een klein punt - men kan iets veel kleiner, sneller en veiliger gebruiken dan IIS om de omleiding te bedienen. Zelfs haproxy of nginx zijn waarschijnlijk overkill - laat staan ​​een complete server zoals apache2. - OrangeDog
Dit klopt, maar allemaal daarvan is slordig en onnodig. - MDMarra
Uuuuw ja, het was zo pijnlijk toen iemand plotseling het domein local.net registreerde en alle drukkers die vóór die datum stil NXDOMAIN kregen, antwoordden niet meer. Dat was een grappig onderzoek ... - Johannes
Mag ik alleen maar opmerken dat .local niet "verzonnen" is, het is in feite gereserveerd; gewoon niet voor dit type gebruik: en.wikipedia.org/wiki/.local - mikebabcock
Op het moment dat dit werd geschreven, was het niet gereserveerd. - MDMarra


Om het antwoord van MDMarra te ondersteunen:

Je zou moeten Gebruik NOOIT een eenduidige DNS-naam ook voor uw domeinnaam. Dit was / is beschikbaar vóór Windows 2008 R2. Redenen / verklaringen zijn hier te vinden: Implementatie en werking van Active Directory-domeinen die zijn geconfigureerd met behulp van single-label DNS-namen | Microsoft-ondersteuning

Vergeet niet om GEEN gereserveerde woorden te gebruiken (een tabel is opgenomen in de link "Naamgevingsconventies" onderaan dit bericht), zoals SYSTEEM of WERELD of BEPERKT.

Ik ben het ook met Microsoft eens dat je twee extra regels moet volgen (die niet in steen zijn gegoten, maar nog steeds):

  1. U moet uw domein NIET een naam geven op basis van iets dat zal veranderen of verouderd zal raken. Voorbeelden zijn het benoemen van uw domein na een productlijn, besturingssysteem of iets anders dat in de loop van de tijd waarschijnlijk zal veranderen. Houd vast aan iets dat zowel geografisch als concreet genoeg is om 5 of zelfs 10 jaar verder te kloppen.
  2. Houd het bij korte namen van 15 tekens of minder, dit zorgt ervoor dat de NETBIOS-naam eenvoudig dezelfde is als de domeinnaam.

Ten slotte zou ik aanbevelen dat je zoveel mogelijk op lange termijn denkt. Bedrijven doorlopen fusies en overnames, zelfs kleine bedrijven. Denk ook in termen van het krijgen van hulp van buitenaf / overleg. Gebruik domeinnamen, AD-structuur enz. Die zonder veel moeite aan consultants of mensen hier op SF kunnen worden uitgelegd.

Kennislinks:

http://technet.microsoft.com/en-us/library/cc731265%28v=ws.10%29.aspx

http://support.microsoft.com/kb/909264

http://support.microsoft.com/kb/300684/en-us

De huidige (W2k12) -aanbevelingspagina van Microsoft voor de root forest-domeinnaam


33
2018-01-29 16:35





Ik ben het niet eens met het gebruik van:

  • example.com - om redenen die al in andere antwoorden zijn vermeld

Ik accepteer het gebruik van:

  • ad.example.com - - om redenen die al in andere antwoorden zijn vermeld

Maar ik zou het zelf niet doen of het aanbevelen. Tijdens bedrijfsovernames, rebranding breekt de hel los, vooral wanneer het management op dat moment wil dat dingen meteen veranderen. Migraties hernoemen, wijzigingen zijn erg moeilijk of duur.

De beste manier om dit aan te bevelen is om een ​​domein te kopen dat irrelevant is voor de bedrijfsnaam en ook niet relevant is voor het merk van het bedrijf. SIMPLE.CLOUD of vergelijkbaar zou prima moeten doen zolang je het kunt bezitten. 

Ik heb grote bedrijven gezien met 150k-gebruikers die AD gebruiken en die nog steeds refereren aan het oude bedrijf dat ze jaren geleden hebben gekocht, of bedrijven die namen hebben gewijzigd en hoewel het er niet toe doet op de lange termijn dat je \ login gebruikt (als je dat niet kunt gebruik UPN) het ziet er nog steeds slecht uit voor het management die niet begrijpt waarom het niet triviaal is om het te veranderen.


1
2017-10-27 15:33





Dat doe ik altijd mydomain.local.

local is geen geldig TLD, dus concurreert het nooit met een echte openbare DNS-vermelding.

Ik vind het bijvoorbeeld leuk om dat te weten web1.mydomain.local zal het intern IP-adres van een webserver oplossen web1.mydomain.com zal naar het externe IP oplossen.


-14
2017-09-23 20:03



FWIW, .local vraagt ​​hamer op de hoofd L-server - ~ 800 / sec toen ik keek. - jscott
dot.Local, AKA dot.Fail - PnP
Het gebruik van een ongeldig TLD (of een niet-geregistreerd domein) is geen beste methode, het is een slechtste methode, om alle bovengenoemde redenen. Ik geef toe dat ik .local heb gebruikt, maar dat was voordat ik het beter wist. - Jonathan J