Active Directory: Wie soll das neue Active Directory heißen?

Meine letzten Beiträge zum Thema Active Directory haben eine wichtige Frage zu Tage gefördert:

Wie soll das neue Active Directory heißen?

In diesem Artikel habe ich folgende Aussage getätigt:

Wer sich auf einer grünen Wiese befindet, kann den Namen für das Active Directory frei vergeben. Mittlerweile werden Namen wie firma.local in neuen Umgebungen nicht mehr verwendet. Besser wäre hier ein Name wie ad.firma.de. Trotzdem können auch weiterhin Namen wie firma.local oder firma.intern verwendet werden. Der Stammdomainname darf allerdings nicht einteilig sein. “Firma” oder “Intern” geht also nicht.

Nach diversen Mails und einem Kommentar habe ich festgestellt, dass ich diese Aussage vielleicht auch begründen sollte. Daher nun dieser Artikel. Eines möchte ich schon mal vorwegnehmen: Niemand muss sein vorhandenes Active Directory umbenennen oder nun zwingend neu installieren.

Wer allerdings ein nagelneues Active Directory installiert, der sollte sich, neben dem Design, auch über den Namen Gedanken machen.

Um genau zu sein, muss man sich über zwei Namen Gedanken machen: Den NetBIOS Namen und den DNS-Namen (FQDN) der neuen Umgebung. Dass eine Domain innerhalb des Active Directory zwei Namen trägt, wird bei der Installation deutlich. Bei der Installation eines neuen Active Directory wird zunächst der FQDN abgefragt:

Active Directory FQDN

In einem der folgenden Dialoge dann der NetBIOS Name:

Active Directory NetBIOS

Bei der Wahl der entsprechenden Namen, muss man sich zunächst einmal an die Konvention halten. Die folgenden Vorgaben gelten für den FQDN:

  • maximal 255 Zeichen (kompletter FQDN)
  • nur Groß/Kleinbuchstaben / Zahlen
  • als Sonderzeichen ist nur “-“ (Bindestrich) zugelassen
  • maximal 63 Zeichen pro Name

Für den NetBIOS Namen gilt:

  • 15 Zeichen

zwar sind einige wenige Sonderzeichen erlaubt, aber es sollte darauf verzichtet werden und nur Buchstaben und Zahlen verwendet werden.

NetBIOS Name und FQDN sind von einander unabhängig und können/dürfen von einander abweichen. Des weiteren darf der FQDN nicht einteilig sein. Der FQDN darf also nicht .local oder .de lauten. Der FQDN muss mindestens aus zwei Teilen bestehen (frankysweb.local oder frankysweb.de). Einteilge Domainnamen werden von diversen Diensten nicht mehr unterstützt, bekanntestes Beispiel ist Exchange.

Soweit erst einmal zu den technischen Anforderungen. Zurück zur eigentlichen Frage, warum sollte ein neues Active Directory nicht einfach firma.local, firma.intern oder firma.lan heißen?

  1. Top Level Domains (TLD) werden seit geraumer Zeit in allen erdenklichen Variationen verkauft. Die klassischen Top Level Domains wie .de und .com wurden mit immer exotischeren TLDs ergänzt, so ist denkbar das irgendwann auch .intern oder .local verkauft wird und als offizielle TLD geführt wird. Das würde unweigerlich Probleme bei der Namensauflösung geben.
  2. Für nicht offizielle TLDs stellen öffentliche Zertifizierungsstellen keine SSL-Zertifikate aus, wer also interne Server mit einem Zertifikat einer öffentlichen CA ausstatten will, muss unweigerlich einen gültigen Namen verwenden. Ein offizielles Zertifikat für intranet.firma.local wird keine öffentliche CA ausstellen.
  3. Der Active Directory Name soll eindeutig sein. Ein Zusammenschluss von zwei Firmen mit gleichen AD-Namen (Bsp. ad.local) wird Schmerzen verursachen, selbst wenn nur eine VPN Verbindung implementiert werden soll.

 

Bedenkt man das ein Active Directory über sehr lange Zeit genutzt wird und ein Umbenennen (wenn überhaupt möglich) oder eine Neuinstallation nur mit großen Aufwand möglich ist, dann sollten diese Punkte nicht vernachlässigt werden. Denn wer kann schon sagen welche TLDs in den nächsten 5 oder 10 Jahren registriert werden?

Die meisten Firmen haben eh schon eine Domain registriert, daher macht es Sinn auf dieser Domain aufzubauen. FrankysWeb dient als Beispiel. Ich habe die Domain frankysweb.de registriert, somit ist schon einmal sichergestellt, dass es keine zweite Domain gibt, die ebenfalls frankysweb.de heißt. Für diese öffentliche Domain an Zertifikate zu kommen ist auch kein Problem, denn sie ist ja offiziell registriert.

Der FQDN für das Active Directory könnte also beispielsweise ad.frankysweb.de lauten. Als NetBIOS Name könnte wiederum “frankysweb” genutzt werden. Die Benutzer könnten sich mit “frankysweb\benutzername” oder mit “benutzername@ad.frankysweb.de” anmelden. Rechnernamen lauten beispielsweise server1.ad.frankysweb.de. Sieht doch ganz hübsch aus und geht den oben genannten Problemen aus dem Weg.

Der FQDN den Active Directorys sollte übrigens nicht gleich des registrierten Domain Namens sein. In meinem Fall sollte das AD also nicht frankysweb.de heißen, dieser Name für das AD würde DNS-Splitbrain erzwingen und macht mehr Probleme als es löst.

Hier gibt es einen sehr alten MSDN Artikel zu diesem Thema, der aber immer noch gültig ist:

Best Practice Active Directory Design for Managing Windows Networks

Darin heißt es:

As a best practice use DNS names registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names then the two infrastructures can never interact with one another.

Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name. For example, if your DNS root name were contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com, where the namespace concorp.contoso.com is not already in use on the network. This new branch of the namespace will be dedicated to Active Directory and Windows 2000 and can easily be integrated with the existing DNS implementation.

Die Empfehlungen sind also keineswegs neu.

4 Replies to “Active Directory: Wie soll das neue Active Directory heißen?”

  1. Warum sollte Split-DNS mehr Probleme machen, aber „ad.firma.de“ wäre aus heutiger Sicht wirklich Best Practice. Wen es stört sich mit benutzer@ad.frima.de anmelden zu müssen, kann immer noch den UPN ändern bzw. erweitern auf nur „firma.de“.
    Tolle Beiträge von Dir – kann nur 1001 Dank sagen und fragen wann schläfst Du noch oder hast Du schon bereits Ghostwriters…

  2. Hi,
    kleines Beispiel für die Probleme mit Split-DNS: Der Internetauftritt des Unternehmens ist via Firma.de zu erreichen. Der interne Benutzer tippt Firma.de im Browser ein, landet auf dem DC und bekommt nichts angezeigt. Der externe Benutzer sieht die Website. Dieses Problem kann auftreten wenn Firma.de der AD Name ist. Weiterer Nachteil von Split-DNS: Der Aufwand der Pflege. Einträge müssen am internen und am externen DNS eintragen werden. Oft sorgt das für diverse Leichen.
    Zum UPN: Stimmt, ein alternatives UPN sollte in die Überlegung mit einbezogen werden.
    Gruß, Frank
    PS: Danke für das Lob. Noch schlafe ich ganz gut :-)

  3. Kann mir den Lobeshymnen von Ralph nur anschliessen. Sehr verständlich, kompetent und klar geschrieben. Da könnten sich einige Referenten ein Beispiel nehmen! Habe schon Unmengen für Weiterbildungen oder Kurse bezahlt und musste feststellen das der Referent nur gut vom Kursbuch ablesen kann. Danke für die interessanten und lernreiche Artikel.

    Gruss Dave

  4. Hallo Frank,
    vielen Dank für deine vielen tollen Artikel.
    Ich habe deine Artikelserie über den Aufbau einer kleinen Exchange-2016-Organisation sehr gerne verfolgt. In diesem hast du allerdings Split-DNS verwendet. Mich würde interessieren, wie das Ganze mit dem oben geschriebenem aussehen müsste? Welche Namen die Server (DC & Exchange) erhalten und welche Auswirkungen das auf die Zertifikate hat? Welche Dinge dann noch beachtet werden müssten?

    Gruß Peter Kostin

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.