Best Practices für die Benennung von Windows Active Directory?

Dies ist eine kanonische Frage zur Benennung von Active Directory-Domänen.

Mit Windows - Domänen und Domänencontroller in einer virtuellen Umgebung Nach dem Experimentieren habe ich erkannt , dass identisch zu einer DNS - Domäne mit dem Namen einer Active Directory - Domäne ist ein schlechte Idee (Was bedeutet , dass mit example.comals Active Directory - Namen ist nicht gut , wenn wir die haben example.comDomain - Namen zur Verwendung 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 bewährte Methoden, wie ein Active Directory-Name lauten sollte oder nicht?

Dies war ein unterhaltsames Diskussionsthema zu Serverfehler. Es scheint unterschiedliche "religiöse Ansichten" zum Thema zu geben.

Ich stimme der Empfehlung von Microsoft zu : Verwenden Sie eine Unterdomäne des bereits registrierten Internetdomänennamens des Unternehmens.

Also, wenn Sie besitzen foo.com, verwenden Sie ad.foo.comoder einige solche.

Aus meiner Sicht ist es am schlimmsten, den registrierten Internetdomänennamen wörtlich für den Active Directory-Domänennamen zu verwenden. Dies führt dazu, dass Sie gezwungen sind, manuell Einträge aus dem Internet-DNS (wie www) in die Active Directory-DNS-Zone zu kopieren , damit "externe" Namen aufgelöst werden können. Ich habe völlig alberne Dinge wie IIS gesehen, die auf jedem Domänencontroller in einer Organisation installiert sind, auf der eine Website ausgeführt wird, die eine Umleitung durchführt, sodass von diesen IIS-Installationen foo.comPersonen umgeleitet werden, die in ihren Browser eintreten www.foo.com. Völlige Albernheit!

Die Verwendung des Internetdomänennamens bringt Ihnen keine Vorteile, schafft jedoch "Arbeit" bei jeder Änderung der IP-Adressen, auf die sich externe Hostnamen beziehen. (Versuchen Sie, geografisch lastausgeglichenes DNS für die externen Hosts zu verwenden, und integrieren Sie dies auch in eine solche Situation mit "aufgeteiltem DNS". Gee-- das wäre lustig ...)

Die Verwendung einer solchen Unterdomäne hat keine Auswirkungen auf Dinge wie die Zustellung von Exchange-E-Mails oder UPN-Suffixe (User Principal Name). (Ich sehe diese beiden häufig als Ausreden für die Verwendung des Internetdomänennamens als AD-Domänennamen.)

Ich sehe auch die Ausrede "viele große Unternehmen machen das". Große Unternehmen können ohne weiteres (wenn nicht sogar mehr) fundierte Entscheidungen treffen 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.

Es gibt nur zwei richtige Antworten auf diese Frage.

1. Eine nicht verwendete Unterdomäne einer Domäne, die Sie öffentlich verwenden. Wenn es sich bei Ihrer öffentlichen Webpräsenz beispielsweise um example.comIhre interne AD handelt, könnte der Name so ähnlich wie ad.example.comoder lauten internal.example.com.

2. Eine nicht verwendete Second-Level-Domain , die Sie besitzen und nirgendwo anders verwenden. Wenn Sie beispielsweise eine öffentliche Webpräsenz haben, wird example.comIhre Anzeige möglicherweise example.net so lange benannt, wie Sie sich registriert haben, example.netund sie wird nirgendwo anders verwendet!

Dies sind Ihre beiden einzigen Möglichkeiten. Wenn Sie etwas anderes tun, sind Sie vielen Schmerzen und Leiden ausgesetzt.

Aber jeder benutzt .local!
Spielt keine rolle Das solltest du nicht. Ich habe über die Verwendung von .local und anderen erfundenen TLDs wie .lan und .corp gebloggt . Unter keinen Umständen sollten Sie dies jemals tun.

Es ist nicht sicherer. Es sind keine "Best Practices", wie manche behaupten. Und es hat keinen Vorteil gegenüber den beiden von mir vorgeschlagenen Optionen.

Aber ich möchte es genauso benennen wie die URL meiner öffentlichen Website, damit meine Benutzer example\userstattdessenad\user
Dies ist eine gültige, aber irreführende Angelegenheit. Wenn Sie den ersten Domänencontroller in einer Domäne heraufstufen, können Sie den NetBIOS-Namen der Domäne auf einen beliebigen Wert festlegen. Wenn Sie meinem Rat folgen und Ihre Domain einrichten ad.example.com, können Sie den NetBIOS-Namen der Domain exampleso konfigurieren , dass sich Ihre Benutzer als anmelden example\user.

In Active Directory-Gesamtstrukturen und -Vertrauensstellungen können Sie auch zusätzliche UPN-Suffixe erstellen. Nichts hindert Sie daran, @ 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 feststellen, dass der vollqualifizierte Domänenname Ihrer Domäne ist ad.example.com. Alles was sie sehen wird example\oder sein @example.com. Die einzigen Personen, die mit dem FQDN arbeiten müssen, sind die Systemadministratoren, die mit Active Directory arbeiten.

Nehmen Sie außerdem an, dass Sie einen Split-Horizon-DNS-Namespace verwenden. Dies bedeutet, dass Ihr AD-Name mit Ihrer öffentlich zugänglichen Website identisch ist. Jetzt können Ihre Benutzer nicht example.comintern zugreifen, es sei denn, Sie haben ein Präfix www.in ihrem Browser oder Sie führen IIS auf allen Ihren Domänencontrollern aus (dies ist schlecht). Sie müssen auch zwei kuratierenNicht identische DNS-Zonen, die einen nicht zusammenhängenden Namespace gemeinsam nutzen. Es ist wirklich mehr Aufwand als es wert ist. Stellen Sie sich nun vor, Sie haben eine Partnerschaft mit einem anderen Unternehmen und dieses Unternehmen verfügt über eine Split-Horizon-DNS-Konfiguration mit AD und externer Präsenz. Sie haben eine private Glasfaserverbindung zwischen den beiden und müssen eine Vertrauensstellung erstellen. Der gesamte Datenverkehr zu öffentlichen Websites muss nun über den privaten Link erfolgen, anstatt nur über das Internet. Außerdem bereitet es den Netzwerkadministratoren auf beiden Seiten Kopfzerbrechen. Vermeiden Sie dies. Vertrau mir.

Aber im
Ernst, es gibt keinen Grund, eines der beiden Dinge, die ich vorgeschlagen habe, nicht zu verwenden. Jeder andere Weg hat Tücken. Ich sage Ihnen nicht, dass Sie sich beeilen sollen, Ihren Domain-Namen zu ändern, wenn er funktioniert und vorhanden ist, aber wenn Sie eine neue AD erstellen, führen Sie eine der beiden oben empfohlenen Aktionen aus.

So helfen Sie MDMarras Antwort:

Sie sollten auch NIEMALS einen DNS-Namen mit einfacher Bezeichnung für Ihren Domainnamen verwenden. 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 mithilfe von DNS-Namen mit einfacher Bezeichnung konfiguriert wurden Microsoft-Support

Vergessen Sie nicht, NICHT reservierte Wörter zu verwenden (eine Tabelle befindet sich im Link "Namenskonventionen" am Ende dieses Beitrags), wie 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 gelten):

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, einem Betriebssystem oder anderen Elementen, die sich im Laufe der Zeit ändern können. Halten Sie sich an etwas, das entweder geografisch oder konkret genug ist, um 5 oder sogar 10 Jahre später einen Sinn zu ergeben.
2. Halten Sie sich an Kurznamen mit maximal 15 Zeichen, damit der NETBIOS-Name problemlos mit dem Domain-Namen übereinstimmt.

Schließlich würde ich empfehlen, dass Sie langfristig so viel wie möglich denken. Unternehmen machen Fusionen und Übernahmen durch, auch kleine Unternehmen. Denken Sie auch an externe Hilfe / Beratung. Verwenden Sie Domain-Namen, AD-Strukturen usw., die Beratern oder Personen hier auf SF ohne großen Aufwand erklärt werden können.

Wissenslinks:

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

Microsofts aktuelle Empfehlungsseite (W2k12) für den Domänennamen der Stammgesamtstruktur

Ich bin nicht einverstanden mit:

• example.com - aus Gründen, die bereits in anderen Antworten genannt wurden

Ich könnte akzeptieren mit:

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

Aber ich würde es nicht selbst tun oder empfehlen. Während der Firmenübernahme bricht das Rebranding aus, besonders wenn das Management zu diesem Zeitpunkt möchte, dass sich die Dinge sofort ändern. Umbenennen von Migrationen, Änderungen sind sehr schwer oder teuer.

Ich würde am besten empfehlen, eine Domain zu kaufen, die für den Firmennamen und für die Marke des Unternehmens nicht relevant ist. SIMPLE.CLOUD oder ähnliches sollte funktionieren, solange Sie es besitzen können.

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

Das mache ich immer mydomain.local.

local ist keine gültige TLD und konkurriert daher nie mit einem tatsächlichen öffentlichen DNS-Eintrag.

Zum Beispiel möchte ich wissen können, dass dies web1.mydomain.localin die interne IP eines Webservers aufgelöst wird, während dies web1.mydomain.comin die externe IP aufgelöst wird.