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,
ich weiß zwar nicht ob es ganz hier ins Thema passt, aber in meiner Firma hat mein Vorgänger die AD xxx.loc genannt. Durch den Wechsel ins O365 habe ich einen neuen „UPN-Suffix“ hinzugefügt und die User umgestellt. Klappt alles sehr gut, nur besteht nun das Problem das über den VPN Tunnel (Windows Internen VPN Client) und ZyXEL Router zwar ein Ping gemacht werden kann aber jeglicher Zugriff auf die FileServer erst mal nach Benutzername und PW fragen. Stelle ich den UPN-Suffix wieder auf den alten zurück klappt es sofort.
Dazu kommt das alle neuen Mitarbeiter die gleich den neuen UPN-Suffix bekommen keine Problme haben.
Hat jemand eine Idee wie ich das lösen kann?
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
Naja, den kann ich vielleicht beantworten..
Der entfernte Rechner sucht dc.ad.firma.com und fragt nun im Zweifel den öffentlichen DNS.. Der sagt, hm ich kenne einen Weg zu firma.com.. Da ist aber schon sozusagen der Fehler, den man nun auf unterschiedliche Weise berichtigen kann..
Möglichkeit 1 wäre, ein öffentlicher DNS Eintrag, das es ad.firma.com nicht gibt. (ich erläutere hier jetzt nicht, wie das geht, weil es Unfug ist).
Möglichkeit 2 wäre ein entsprechendes portforwarding zu aktivieren und tatsächlich einen Eintrag für dc.ad.firma.com zu hinterlegen.. Dann bräuchte man fast kein VPN mehr.. Aber auch das erläutere ich nicht weiter, denn das gibt auch kranke Sicherheitsrisiken..wir wollen ja unseren DC in der Regel nicht vom inet aus erreichbar haben und auch nicht jedem auf die Nase binden, wo der DC zu finden ist..
Bleiben also noch 2 Wege.. Eine statische Route hinterlegen, die auf dem Rechner immer den Weg über den eigenen DNS / Router für das Ziel dc.ad.firma.com erzwingt und damit über die netzwetkkarte mit der IP geht oder über den vpn geht.. Das geht aber auch schief, wenn das entfernte Netzwerk zufällig die gleiche IP Maske benutzt.. Und ist nicht ganz trivial zu konfigurieren..
Ergo bleibt noch möglichkeit vier und das ist die „richtige“.. Auch und gerade bezüglich der Sicherheit und lässt sich mit einem Haken aktivieren bei ordentlichen clients… Es wird aller traffic durch das VPN gejagt… Und damit wird auch der richtige DNS getroffen und auch der richtige DC.. Denn der Rechner ist nun tatsächlich im Firmeneigenen Netz..
Nebenbeivorteil..: 1. Das Kundennetzwerk kriegt auch nicht zu sehen, was ich zum Beispiel ansurfe, es sieht nur den vpn Aufbau und die kryptierte Kommunikation..
2. Meine Unternehmensregeln ziehen auch für den entfernten Rechner.
Nachteil: Surfen könnte mit aktiviertem VPN für den Roadwarrior etwas langsam werden.. Den seine download Geschwindigkeit wird nun von der Upload Bandbreite meines Unternehmensnetzwerks und der Leistungsfähigkeit meines VPN Servers limitiert..
Beispiel typischer Netzanschluss in D auf Kabelnetz 1GBit down / 50 MBit upload.. Und der Roadwarrior sitzt nun bei nem Kunden, der nen DSL Anschluss mit 250 MBit down und 40 MBit upload…
Würde er für Internet das VPN nicht nutzen hätte er das kundennetz minus dem anderen traffic (inklusive seines VPN Traffics) zur Verfügung.. Im besten Fall also 250 up / 40 down.
Wird alles durch das vpn gejagt, reduziert sich seine uploadrate auf die 40Mbit up -VPN overhead -Anderer Traffic.. Also im besten Fall ca. 38 MBit upload.. Und der Download reduziert sich auf 50Mbit -VPN Overhead -anderer upload traffic des eigenen Unternehmens.. Sind wir im Idealfall bei 48 down sofern unser vpn Server das denn schafft..
Und nun sind noch zwei roadwarrior gleichzeitig unterwegs.. Dann teilen die sich die 48Mbit down auch noch.. Und wenn beide gleichzeitig was ins Internet hochladen, dann teilen sie sich auch wieder die 48Mbit der Firma.. Das gibt dann 24/24 für jeden.. (und das auch nur, wenn der ganze Rest des Unternehmens nix hochlädt).. Und der vpn Server leistungsstark genug ist… Aber das ist nunmal so mit vpn… Heisst größere Downloads sollte man lassen, solange man unterwegs ist.. Und auch der upload ins Internet oder zur DB Replikation sollte unterbleiben und erst stattfinden, wenn wieder zuhause… Oder halt nen synchroner Netzanschluss…
So ist aber sicher..
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
Da ist doch sozusagen der Trick mit der ad.abc.yz Domäne.. Da die lokalen Namen nun eine subdomain sind, müsste das so funktionieren ohne weiteren Aufwand..
Die mailadressen bleiben ja meier@abc.yz und die öffentliche zugänglichen Dienste bleiben auch http://www.abc.yz http://ftp.abc.yz und was auch immer.. Die lokalen/internen Rechner erhalten nun dann aber Namen wie pdc.ad.abc.yz sdc.ad.abc.yz fileserver.ad.abc.yz und die Domainuser heißen dann meier@ad.abc.yz mit der mailadresse meier@abc.yz was so ziemlich das gleiche ist, wie vorher auch meier@abc.local mit mailadresse meier@abc.yz macht also so erstmal keinen Unterschied…
Genauso wie die Namen pdc.ad.abc.yz ist im Prinzip genau wie pdc.abc.local… Und im wie dargestellt auch „richtiger“.. Denn .local ist eine top-level Domain, die evtl mal öffentlich werden könnte.. Und im Prinzip sind alle *.local Domänen ein großes Netzwerk, was ziemlicher „bullshit“ ist… ad.abc.yz gibt es aber definitiv nur ein einziges mal.. Und auch nur „meine“ Rechner können da drunter Namen bekommen.. Und es sagt auch keiner, dass es ad heißen muss… Ich würde eventuell zu local.abc.yz oder gar zu intranet.abc.yz neigen… Finde ich logischer und vor allem maskiert es was mein internes Netz wirklich tut.. ad sagt ja schon, ich bin ein windoof Netzwerk mit Domäne und active directory.. Local oder Intranet sagt darüber gar nix aus.. Außer, dass die IP Adressen, die sich dahinter verbergen sich hoffentlich ausschließlich zu privaten nicht öffentlich routbaren Adressen auflösen und somit auch von außen nicht erreichbar sind.
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 :-)