Frage Best Practices für Windows Active Directory-Benennung?


Das ist ein Kanonische Frage über Active Directory-Domänennamen.

Nach dem Experimentieren mit Windows-Domänen und Domänencontrollern in einer virtuellen Umgebung habe ich festgestellt, dass es eine schlechte Idee ist, eine Active Directory-Domäne zu haben, die mit einer DNS-Domäne identisch ist example.com Wie ein Active Directory Name ist nicht gut, wenn wir die example.com Domainname zur Nutzung als unsere Website registriert).

Diese verwandte Frage scheint diese Schlussfolgerung zu stützen, aber ich bin mir immer noch nicht sicher, welche anderen Regeln es gibt, um Active Directory-Domänen zu benennen.

Gibt es Best Practices dafür, was ein Active Directory-Name sein sollte oder nicht?


80
2017-10-21 13:10


Ursprung




Antworten:


Dies war ein lustiges Thema der Diskussion über Serverfehler. Es scheint verschiedene "religiöse Ansichten" zu diesem Thema zu geben.

Ich stimme der Empfehlung von Microsoft zu: Verwenden Sie eine Sub-Domain des bereits registrierten Internet-Domänennamens des Unternehmens.

Also, wenn du gehörst foo.com, benutzen ad.foo.com oder einige solcher.

Die abscheulichste Sache ist, wie ich es sehe, den registrierten Internet-Domain-Namen, wörtlich, für den Active Directory-Domain-Namen. Dies führt dazu, dass Sie manuell Datensätze aus dem Internet DNS (wie www) in die Active Directory-DNS-Zone, damit "externe" Namen aufgelöst werden können. Ich habe extrem dumme Dinge wie IIS gesehen, die auf jedem Domänencontroller in einer Organisation installiert wurden, auf der eine Website läuft, die eine Weiterleitung so ausführt, dass jemand eintritt foo.com in ihren Browser würde umgeleitet werden www.foo.com von diesen IIS-Installationen. Völlige Albernheit!

Die Verwendung des Internetdomänennamens bringt Ihnen keine Vorteile, sondern schafft "make work" jedes Mal, wenn Sie die IP-Adressen ändern, auf die sich externe Hostnamen beziehen. (Versuchen Sie geographisch lastabgestimmtes DNS für die externen Hosts und integrieren Sie das auch mit solch einer "Split DNS" -Situation! Gee-- das wäre lustig ...)

Die Verwendung einer solchen Subdomain hat keine Auswirkungen auf Dinge wie Exchange-E-Mail-Zustellung oder UPN-Suffix (User Principal Name), BTW. (Ich sehe oft, dass beide als Ausreden für die Verwendung des Internet-Domänennamens als AD-Domänenname angeführt werden.)

Ich sehe auch die Entschuldigung "viele große Unternehmen tun es". Große Unternehmen können knochenharte Entscheidungen genauso leicht treffen (wenn nicht noch mehr) als kleine Unternehmen. Ich kaufe das nicht, nur weil ein großes Unternehmen eine schlechte Entscheidung trifft, die es irgendwie zu einer guten Entscheidung macht.


94
2017-10-21 13:16



Aber dann NetBIOS-Name der Domain ist nicht ... nun, hübsch :) corp ist nicht so beschreibend wie foo. - Anton Gogolev
Sie können jedoch den gewünschten NetBIOS-Namen zuweisen. Viele meiner Kunden haben Namen wie "ad.example.com", aber der NetBIOS-Name ist "BEISPIEL". DCPROMO wird Sie während der Erstellung der Domäne dazu auffordern, den NetBIOS-Namen anzugeben. - Evan Anderson
Wenn Sie dies tun, achten Sie auf Probleme mit Domains, die Platzhalter haben. Wenn Sie * .foo.com haben, wird host.internal.foo.com in einigen Situationen übereinstimmen - JamesRyan
Mir ist kein E-Mail-Server-Produkt bekannt, für das Sie den AD-Domänennamen als Suffix für die E-Mail-Adresse der Benutzer verwenden müssen. Exchange hat noch nie benötigt irgendeine Art von Korrelation zwischen dem AD-Domain-Namen und E-Mail-Adresse Suffixe. - Evan Anderson
Office365 erfordert nur, dass sich Ihre Benutzer mit ihrem UPN mit einem Suffix anmelden, das Ihrer Tenant-Domäne entspricht. Da die Standardrichtlinie für Exchange-Postfachadressen beliebig definiert werden kann, wie auch Ihr UPN-Suffix, ist es trivial. Wir haben EXAMPLE.COM als unseren Firmennamen (und Mandant in Office365), BEISPIEL.NET (auch registriert) als die Gesamtstruktur, CORP.EXAMPLE.NET als die primäre Kontodomäne (mit anderen regionalen Subdomains, zB EU.EXAMPLE. NET) mit EXAMPLE als NetBIOS-Name, verwenden alle Benutzer in der Exchange-Organisation org Name@EXAMPLE.COM für UPN und für E-Mail. Office365 ist damit vollkommen zufrieden. - Ryan Fisher


Es gibt nur zwei richtige Antworten auf diese Frage.

  1. Eine nicht verwendete Subdomäne einer Domäne, die Sie öffentlich verwenden. Zum Beispiel, wenn Ihre öffentliche Webpräsenz ist example.com Ihre interne AD könnte etwa so heißen ad.example.com oder internal.example.com.

  2. Eine nicht verwendete Second-Level-Domain das du besitzt und nicht woanders verwenden. Zum Beispiel, wenn Ihre öffentliche Webpräsenz ist example.com Ihr AD könnte benannt werden example.net  solange du dich registriert hast example.net und benutze es nirgendwo sonst!

Dies sind Ihre einzigen zwei Möglichkeiten. Wenn Sie etwas anderes tun, lassen Sie sich für viel Schmerz und Leiden offen.


Aber alle benutzen .local!
Macht nichts. Du solltest nicht. Ich habe über die Verwendung von .local und anderen erfundenen TLDs wie .lan und .corp gebloggt. Unter keinen Umständen sollten Sie dies tun.

Es ist nicht sicherer. Es ist nicht "Best Practices" wie manche behaupten. Und das hat es nicht irgendein Nutzen Sie die zwei Möglichkeiten, die ich vorgeschlagen habe.

Aber ich möchte es genauso benennen wie die URL meiner öffentlichen Website, so dass meine Nutzer es sind example\user anstatt ad\user
Dies ist eine gültige, aber fehlgeleitete Sorge. Wenn Sie den ersten Domänencontroller in einer Domäne heraufstufen, können Sie den NetBIOS-Namen der Domäne auf den gewünschten Wert festlegen. Wenn Sie meinen Rat befolgen und Ihre Domain einrichten ad.example.comkönnen Sie den NetBIOS-Namen der Domäne konfigurieren example damit sich Ihre Benutzer als einloggen example\user.

In Active Directory-Gesamtstrukturen und -Vertrauensstellungen können Sie auch zusätzliche UPN-Suffixe erstellen. Es steht Ihnen nichts im Wege, @ example.com als primäres UPN-Suffix für alle Konten in Ihrer Domain zu erstellen und festzulegen. Wenn Sie dies mit der vorherigen NetBIOS-Empfehlung kombinieren, wird kein Endbenutzer jemals den vollqualifizierten Domänennamen Ihrer Domäne sehen ad.example.com. Alles, was sie sehen, wird sein example\ oder @example.com. Die einzigen Personen, die mit dem FQDN arbeiten müssen, sind die Systemadministratoren, die mit Active Directory arbeiten.

Angenommen, Sie verwenden einen Split-Horizon-DNS-Namespace, was bedeutet, dass Ihr AD-Name mit Ihrer öffentlich zugänglichen Website identisch ist. Jetzt können Ihre Benutzer nicht erreichen example.com intern, es sei denn, Sie haben sie Präfix www. in ihrem Browser oder Sie führen IIS auf allen Ihren Domänencontrollern (das ist schlecht). Sie müssen auch kuratieren zwei Nicht identische DNS-Zonen, die einen nicht zusammenhängenden Namespace verwenden. Es ist wirklich mehr Mühe als es wert ist. Stellen Sie sich nun vor, dass Sie eine Partnerschaft mit einem anderen Unternehmen haben, und sie haben auch eine Split-Horizon-DNS-Konfiguration mit ihrer AD und ihrer externen Präsenz. Sie haben eine private Glasfaserverbindung zwischen den beiden und Sie müssen eine Vertrauensstellung erstellen. Nun müssen alle Ihre Zugriffe auf öffentliche Websites den privaten Link durchqueren, anstatt nur über das Internet zu gehen. Es bereitet auch den Netzwerkadministratoren auf beiden Seiten Kopfzerbrechen. Vermeiden Sie dies. Vertrau mir.

Aber, aber, aber...
Ernsthaft, es gibt keinen Grund, eines der beiden Dinge, die ich vorgeschlagen habe, nicht zu verwenden. Jeder andere Weg hat Tücken. Ich rate dir nicht, deinen Domain-Namen zu ändern, wenn er funktioniert und an Ort und Stelle ist, aber wenn du eine neue AD erstellst, tue eines der zwei Dinge, die ich oben empfohlen habe.


87
2018-01-29 16:18



Ein kleiner Punkt - man kann etwas viel kleiner, schneller und sicherer als IIS verwenden, um die Weiterleitung zu bedienen. Selbst Haproxy oder Nginx sind wahrscheinlich zu viel - geschweige denn ein voll funktionsfähiger Server wie Apache2. - OrangeDog
Das ist wahr, aber alles das ist schlampig und unnötig. - MDMarra
Uuuuw ja, es war so schmerzhaft, als plötzlich jemand die Domain local.net anmeldete und alle Drucker, die NXDOMAIN stillschweigend vor diesem Datum hatten, antworteten plötzlich nicht mehr. Das war eine lustige Untersuchung ... - Johannes
Darf ich nur feststellen, dass .local nicht "erfunden" ist, sondern tatsächlich reserviert ist; nur nicht für diese Art der Verwendung: en.wikipedia.org/wiki/.local - mikebabcock
Zu der Zeit, als dies geschrieben wurde, war es nicht reserviert. - MDMarra


Um die Antwort von MDMarra zu unterstützen:

Du solltest Verwenden Sie NIE einen DNS-Namen mit einer einzelnen Bezeichnung für Ihren Domain-Namen entweder. Dies war / ist vor Windows 2008 R2 verfügbar. Gründe / Erklärungen finden Sie hier: Bereitstellung und Betrieb von Active Directory-Domänen, die unter Verwendung von DNS-Namen | Microsoft-Support

Vergessen Sie nicht, reservierte Wörter zu verwenden (Eine Tabelle ist im Link "Namenskonventionen" am Ende dieses Beitrags enthalten), z. B. SYSTEM oder WORLD oder RESTRICTED.

Ich stimme auch Microsoft darin zu, dass Sie zwei zusätzliche Regeln befolgen sollten (die nicht in Stein gemeißelt sind, aber immer noch):

  1. Sie sollten Ihre Domain NICHT basierend auf etwas benennen, das sich ändert oder veraltet ist. Beispiele hierfür sind die Benennung Ihrer Domain nach einer Produktlinie, eines Betriebssystems oder anderer Elemente, die sich im Laufe der Zeit ändern können. Bleib bei etwas, das entweder geografisch oder konkret genug ist, um 5 oder sogar 10 Jahre lang Sinn zu machen.
  2. Bleiben Sie bei kurzen Namen von 15 Zeichen oder weniger, dies ermöglicht es, dass der NETBIOS-Name einfach mit dem Domänennamen übereinstimmt.

Schließlich würde ich empfehlen, dass Sie so lange wie möglich langfristig denken. Unternehmen durchlaufen Fusionen und Übernahmen, sogar kleine Unternehmen. Denken Sie auch an externe Hilfe / Beratung. Verwenden Sie Domain-Namen, AD-Struktur, etc., die Berater oder Menschen hier auf SF ohne viel Aufwand erklären können.

Wissensverknüpfungen:

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

Die aktuelle (W2k12) Empfehlungsseite von Microsoft für den Stammdomänennamen


33
2018-01-29 16:35





Ich stimme nicht zu mit:

  • example.com - aus Gründen, die bereits in anderen Antworten angegeben sind

Ich könnte akzeptieren mit:

  • ad.example.com - - aus Gründen, die bereits in anderen Antworten angegeben sind

Aber ich würde es nicht selbst tun oder es empfehlen. Während der Firmenübernahme bricht Rebranding die Hölle los, besonders wenn das Management zu diesem Zeitpunkt die Dinge sofort ändern will. Umbenennen von Migrationen, Änderungen sind sehr schwierig oder teuer.

Am besten würde ich empfehlen, eine Domain zu kaufen, die für den Firmennamen irrelevant und für die Marke des Unternehmens irrelevant ist. SIMPLE.CLOUD oder Ähnliches sollte gut gehen solange du es besitzen kannst. 

Ich habe große Unternehmen mit 150.000 Nutzern gesehen, die AD verwenden, die immer noch auf alte Unternehmen verweisen, die sie vor Jahren gekauft haben, oder Firmen, die Namen geändert haben, und obwohl es auf lange Sicht keine Rolle spielt, dass Sie \ login verwenden (wenn nicht benutze UPN) es sieht immer noch schlecht aus vor dem Management, das nicht versteht, warum es nicht einfach ist, es zu ändern.


1
2017-10-27 15:33





mache ich immer mydomain.local.

local Es handelt sich nicht um eine gültige TLD. Sie konkurriert also nicht mit einem tatsächlichen öffentlichen DNS-Eintrag.

Zum Beispiel, ich mag es, das zu wissen web1.mydomain.local Wird währenddessen auf die interne IP eines Webservers auflösen web1.mydomain.com wird auf die externe IP aufgelöst.


-14
2017-09-23 20:03



FWIW, .local Abfragen hämmern auf den Root-L-Server - ~ 800 / sek, als ich schaute. - jscott
dot.Local, alias dot.Fail - PnP
Die Verwendung einer ungültigen TLD (oder einer nicht registrierten Domain) ist keine bewährte Methode. Aus allen oben genannten Gründen ist dies eine schlechte Übung. Ich gebe zu, dass ich .local benutzt habe, aber das war, bevor ich es besser wusste. - Jonathan J