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:
In einem der folgenden Dialoge dann der NetBIOS Name:
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?
- 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.
- 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.
- 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.
Hallo zusammen, mal eine dumme Frage – kann es sein, dass die Computer mit einer richtigen Domäne ewig brauchen, um zu erkennen, dass der DC im Moment nicht erreichbar ist? (Bspw. im HomeOffice)
Mit der ad.local verstehen es die Rechner sofort. Oder muss ich den NS-Eintrag in meiner Domainverwaltung (Strato, Ionos, etc.) für die Subdomain auf die private IP des DNS-Servers ändern?
Ok ich glaub ich habe es raus. Man kann eine Zone mx.doamin.tld anlegen und dort einen Host A Eintrag ohne Name eintragen.
Hallo zusammen, Hallo Frank, vielen Dank für Deine tollen Beiträge, jetzt habe ich aber noch eine Frage offen und zwar zu den Zertifikaten, angenommen ich installiere den DC und lege eine neue AD an. Die hat dann FQDN ad.doamin.tld. Nun installiere ich den Exchange und sagen wir mal einen Webserver. Diese möchte ich von außer via einer Subdomain erreichbar machen.
Wenn ich mir jetzt ein Wildcard Zertifkat hole, dann greift der ja nur auf *.domain.tld, was ja erstmals ok ist. Ich sage als Beispiel möchte ich den Exchange über mx.domain.tld und den Webserver unter web.domain.tld erreichbar haben, das heißt beide würden auch über ein Wildcard Zertifikat abgedeckt sein. Aber wie lege ich das im DNS an, ich müßte, ja dann doch eine neue Zone für domain.tld anlegen und die entsprechenden hosts dann aufnehmen z.B Host (A) = mx –> interne IP. Aber da bin ich ja wieder bei Split DNS. Wenn ich eine Zone mx.domain.tld anlege, wird es ja nicht funktionieren, oder liege ich heir falsch?
Vielen Dank im Voraus für Eure Tipps.
VG Eddie
Hallo,
ich fand das mit firma.local nicht wirklich problematisch und ich glaube kaum, dass .local in absehbarer Zeit vergeben wird, da .local doch recht oft als interner tld-Name verwendet wurde. Wer hier Bedenken hat, der kann auch .local mit .zz für Neuinstallationen ersetzen. Mit einem neutralen Namen wie z. B. mit „firma“, „praxis“, „kanzlei“ usw. wäre ich zudem noch unabhängig von möglichen späteren Firmenumbenennungen. Ich denke, dass jede Lösung seine Vorteile und Nachteil hat und es somit keine allgemeingültige Lösung geben kann. Recht gut fand ich diese Gegenüberstellung:
https://www.faq-o-matic.net/2007/06/08/welcher-name-ist-der-beste-fuer-eine-ad-domaene/
Viele Grüße
Andi
Die Verwendung von .local ist immer eine schlechte Idee, da diese seit langem bereits für mDNS verwendet wird. Daher haben wir schon vor über 10 Jahren firma.intern verwenden.
Hallo Frank,
vielen Dank für die sehr hilfreichen Anleitungen! Ich habe vor einiger Zeit die Chance genutzt und bei der Erneuerung des Domänencontrollers die Domäne von domain.local auf ad.domain.de umgestellt. Die Erklärungen hier leuchteten auch total ein und ich will nicht sagen, dass ich die Entscheidung generell bereue. Es hat sich aber ein Problem ergeben, welches ich auch mit viel Recherche bisher nicht lösen konnte und vielleicht hast du ja einen entscheidenden Hinweis.
Mir ist aufgefallen, dass ich z.B. Notebooks für Roadwarrior nicht mehr der Domäne hinzufügen kann, wenn sich diese nicht im firmeninternen Netzwerk befinden. Früher ging das ohne Probleme mittels VPN (PPTP oder OpenVPN). Jetzt ist es aber so (mit Wireshark nachvollzogen), dass beim Domänenbeitritt nicht zuerst der firmeninterne DNS Server (=DC) über den VPN-Tunnel abgefragt wird, sondern immer der DNS Server des Netzes, in dem sich das Notebook gerade befindet. Dieser leitet die Anfrage dann natürlich an den Forwarder weiter und liefert letztlich die IP des Domain-Providers zurück. In der Folge kann der DC nicht korrekt erreicht werden. Ein nslookup auf einen Host mit Domänensuffix scheitert auf gleiche Weise, ein nslookup auf einen Host ohne Suffix scheitert, weil der lokale DNS den Host nicht kennt. Lediglich ein ping auf einen Host ohne Domänensuffix wird korrekt aufgelöst, weil hier vom Betriebssystem verschiedene Wege durchprobiert werden. Für die VPN-Verbindung ist jeweils ein Suffix eingerichtet, jedoch veranlasst das die Windows 10 Rechner leider nicht, diese Verbindung dann als bevorzugten Weg für DNS-Anfragen an ad.domain.de zu nutzen.
Hast du eine Idee, wie ich dem Problem Herr werden kann?
Gruß
Markus
Hallo.
Ich kann mich den Lobeshymnen nur anschließen – immer wieder super Tipps, die den Administrator das leben erleichtern.
Nun aber zu meiner Frage.
Ich bin Systemadministrator von mehreren Firmen mit Active Directory.
Wenn ein Neuer Server bei einem Kunden fällig ist, und das Unternehmen überschaubar war, habe ich nun jede Domäne von .local auf intern.xy.com oder .at abgeändert. Soweit alles super und OK.
Nun habe ich aber 2 Firmen, die nicht mehr so überschaubar sind.
In diesen Unternehmen arbeiten jeweils ca 70 – 110 User (AD, Exchange, …).
Macht es sinn auch in diesem Fall von der firma.local auf die intern.firma.at zu wechseln?
Bei den Firmen wird demnächst der Exchange Server getauscht. Deshalb hab ich mir gedacht, in diesem Zug wäre es möglich.
Danke Mike
Hallo Michael,
ich würde jetzt nicht unbedingt im Zuge einer Exchange Migration gleich das ganze AD über den Haufen werfen. Mir ist aktuell kein Grund bekannt, .local ADs zu migrieren, in der Regel reicht es einen alternativen UPN zu konfigurieren. Auf der anderen Seite, wenn der Kunde den Aufwand bereit ist zu zahlen, warum nicht?!
Gruß,
Frank
Hallo Frank,
super Beitrag, vielen Dank!
Ich fange gerade auch teils auf einer neuen Wiese an und habe ein paar Fragen.
Es gibt eine vorhandene Domäne, welche von einem externen Hoster verwaltet wird. Diese habe ich in Office 365 eingebunden, welche auf Grund der vorhandenen Email-Adressen auch bestehen bleiben muss.
Nun bin ich dabei, einen komplett neuen lokalen Server, der als DC und Fileserver dienen soll, einzurichten. Wie richte ich nun die lokale Domäne ein, bzw. welchen Namen gebe ich dieser, damit SSO funktioniert?
Der Server muss nicht zwingend von extern erreichbar sein. Aus Sicherheitsgründen würde ich eher sagen nein.
Viele Grüße
Chris
Wenn Du ein wildcard-Zertifikt verwendest, der ja auf die TLD ausgestellt ist hast hast Du gleichermaßen weder extern noch intern ein Problem.
Hallo Peter,
Du bennenst Dein Exchange Server z.B. mail.ad.domain.de und setzt lediglich auf dem externen DNS Server von domain.de einen Hosteintrag, der dann auf Dein ReverseProxy verweist.
VG Eddie
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
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
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…
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 :-)