My last posts on the subject of Active Directory have brought an important question to light:
What should the new Active Directory be called?
In this article I have made the following statement:
If you are on a greenfield site, you can freely assign the name for the Active Directory. In the meantime, names such as company.local are no longer used in new environments. A name like ad.firma.de would be better here. Nevertheless, names such as firma.local or firma.intern can still be used. However, the root domain name must not be one part. "Company" or "Internal" is therefore not possible.
After various emails and a comment, I realized that I should perhaps also justify this statement. Hence this article. I would like to say one thing in advance: Nobody has to rename their existing Active Directory or reinstall it.
However, if you install a brand new Active Directory, you should also think about the name as well as the design.
To be precise, you need to think about two names: The NetBIOS name and the DNS name (FQDN) of the new environment. The fact that a domain has two names within the Active Directory becomes clear during installation. When installing a new Active Directory, the FQDN is queried first:
The NetBIOS name then appears in one of the following dialogs:
When choosing the appropriate name, you must first of all adhere to the convention. The following specifications apply to the FQDN:
- Maximum 255 characters (complete FQDN)
- only upper/lower case letters / numbers
- Only "-" (hyphen) is permitted as a special character
- maximum 63 characters per name
The following applies to the NetBIOS name:
- 15 characters
Although a few special characters are allowed, they should be avoided and only letters and numbers should be used.
NetBIOS name and FQDN are independent of each other and can/may differ from each other. Furthermore, the FQDN must not be one part. The FQDN must therefore not be .local or .de. The FQDN must consist of at least two parts (frankysweb.local or frankysweb.de). One-part domain names are no longer supported by various services, the best-known example being Exchange.
So much for the technical requirements. Back to the actual question, why shouldn't a new Active Directory simply be called firma.local, firma.intern or firma.lan?
- Top level domains (TLDs) have been sold in every conceivable variation for some time now. The classic top level domains such as .de and .com have been supplemented with ever more exotic TLDs, so it is conceivable that at some point .intern or .local will also be sold and listed as an official TLD. This would inevitably lead to problems with name resolution.
- Public certification authorities do not issue SSL certificates for non-official TLDs, so if you want to equip internal servers with a certificate from a public CA, you will inevitably have to use a valid name. No public CA will issue an official certificate for intranet.company.local.
- The Active Directory name should be unique. A merger of two companies with the same AD name (e.g. ad.local) will cause pain, even if only one VPN connection is to be implemented.
Considering that an Active Directory is used for a very long time and renaming (if possible at all) or a new installation is only possible with great effort, these points should not be neglected. After all, who can say which TLDs will be registered in the next 5 or 10 years?
Most companies already have a domain registered anyway, so it makes sense to build on this domain. FrankysWeb serves as an example. I have registered the domain frankysweb.de, which ensures that there is no second domain that is also called frankysweb.de. Obtaining certificates for this public domain is also no problem, as it is officially registered.
The FQDN for the Active Directory could therefore be ad.frankysweb.de, for example. In turn, "frankysweb" could be used as the NetBIOS name. Users could log in with "frankysweb\username" or with "benutzername@ad.frankysweb.de". Computer names are, for example, server1.ad.frankysweb.de. This looks quite nice and avoids the problems mentioned above.
By the way, the FQDN of the Active Directory should not be the same as the registered domain name. In my case, the AD should not be called frankysweb.de, as this name for the AD would force DNS splitbrain and cause more problems than it solves.
Here is a very old MSDN article on this topic, but it is still valid:
Best Practice Active Directory Design for Managing Windows Networks
It states:
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.
So the recommendations are by no means new.
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 :-)