Risiko AD-Domain

Als Firmen vor vielen Jahren ihr Active Directory aufgesetzt haben, muss ein DNS-Namen festgelegt werden. Nicht immer war die Wahl "weise" und auf dieser Seite möchte ich auf eine besonders unglückliche Konstellation eingehen, die Firmen bewusste sein sollte.

Mehrere Kunden haben die ein oder andere unglückliche Entscheidung in der Vergangenheit getroffen und der Druck nimmt immer mehr zu, den Fehler zu korrigieren. Auch wenn der Aufwand immens und damit teuer sein kann. Dies hier beschriebenen Risiken sind für einige Firmen, die ich kenne, leider real.

DNS und Active Directory

Es wurde schon viel über die Namenwahl bei einem Active Directory geschrieben und jede Variante hat ihre individuellen Vor- und Nachteile. Heute hat ja quasi jede Firma eine Internetpräsenz, die unter einen öffentlichen DNS-Namen erreichbar ist. Stellen Sie sich vor, es gäbe mal eine "MSXFAQ GmbH", die unter www.msxfaq.de im Internet erreichbar wäre. Wie könnte dann die interne Active Directory Domain lauten?

Der DNS-Name ihrer AD-Domain ist auch der Domäne in ihrem UPN. Allerdings können Sie problemlos mehrere UPN-Domains addieren und den Anmeldenamen eines Benutzers z.B. für Microsoft 365 jederzeit anpassen.

AD-Domainname

Beschreibung

msxfaq.de

Ich könnte tatsächlich intern den gleichen Namen wie extern verwenden. Das ist sicher und funktioniert sehr gut. Allerdings muss ich mich mit den Tücken von "Split-DNS" herumschlagen, denn die PCs fragen sicher den internen DNS-Server und es ist schon komisch, wenn die eigenen Mitarbeiter nicht die eigene Firmenwebseite auf "www.msxfaq.de" erreichen können, weil der Admin keinen DNS-Eintrag gesetzt hat. Mit einem HTTP-Proxy muss er aber auch noch eine Ausnahme hierfür definieren. Mit der passenden Einrichtung ändern sich so für Anwender aber Hyperlinks nicht mehr, wenn sie extern oder intern sind. Ich kann mit sogar Zertifikate für intern von eine öffentlichen PKI besorgen und erspare mir eine eigene PKI samt Verteilung des Stammzertifikats, was besonders auf Mobilgeräten oder VoIP-Telefonen nicht immer so einfach ist.

ad.msxfaq.de

Viele Firmen haben einfach eine Subdomain für ihre Active Directory genutzt. Damit gibt es weniger Konflikte und auch die DNS-Konfiguration erscheint einfacher. Wenn Benutzer aber Webseiten von intern und extern unter dem gleichen Namen erreichen müssen, kann ich mit Stub-Zonen arbeiten. Auch Zertifikate sind möglich

msxfaq.local

Einige meiner Kunden haben damals eine ".local"-Root gewählt. Das erscheint sicher und sollte im Internet keinen Konflikt bedeuten, da ".local" nicht genutzt wird. Das stimmt aber nicht ganz denn mDNS u.a. Dienste nutzen die TLD vielleicht auch. Microsoft hat in den Anfangstagen auch eine ".Local" empfohlen, was später aber dann relativiert wurde und man doch besser eine offizielle Domain kauft

msxfaq.ads

In der Frühzeit gab es eigentlich nur ".com", ".net", ".gov", ".edu" und einige Länderdomains. ".ads" war nicht belegt und ADS ist doch eine schöne Abkürzung für "Active Directory Services". Das ist sehr lange gut gegangen, bis es neue Top Level Domains gab und Google sich am 25. März 2015 ".ads" als "Advertising" reserviert hat. Es gab auch in meinem Umfeld einen Kunden, der diese Domain hatte und dessen VPN-Clients anhand einer DNS-Anfrage geprüft haben, ob sie "im Lan" sind. Da aber nun .ads auch im Internet auflösbar war, hat der VPN-Client keine Verbindung aufgebaut.

msxfaq.net (1)

Ich kann natürlich neben meiner MSXFAQ.DE auch noch eine zweite Domain kaufen, di eich im Internet nur als Platzhalter festhalte aber nicht aktiv nutze. ich kann diese aber dennoch intern für mein Active Directory nutzen und muss keinen Konflikt befürchten.

Es soll aber auch schon passiert sein, dass eine Firma vergessen hat, die Platzhalterdomain weiter zu bezahlen und sie können sicher sein, dass eine aufgegeben Domain umgehend von jemandem "gesichert" wird.

msxfaq.net (2)

Kniffliger wird, es wenn mir die Domain nicht gehört, sondern eine andere Firma diese hält. Das ist aus meiner Sicht ein "Worst Case" Szenario, auf das ich weiter eingehe

Fremde Domain als AD-Domain

"Eigentlich kann ich doch jede beliebige Domain in meinem lokalen Netzwerk verwenden, solange es keine Verbindung mit dem Internet hat". Diese Aussage habe ich schon früher gehört und sie war schon damals nicht richtig aber es tat weniger weh. Mittlerweile sind die meisten Computer irgendwie mit dem Internet verbunden und auch nicht mehr immer im "internen Firmennetzwerk", sondern unterwegs oder ganz oft im Homeoffice. Durch die Nutzung von Microsoft 365 und anderer Cloud-Angebote, zeitnahe Virenpattern-Updates, Lizenzprüfungen u.a. Anwendungen ist eine Verbindung zum Internet schon quasi Pflicht. Selbst wer zu Hause arbeitet und ein VPN zur Firma aufgebaut hat, wird oft keinen geschlossenen "Tunnel" nutzen, da dieser Umweg für Cloud-Anwendungen extrem nachteilig ist. Aber welche Probleme habe ich damit, wenn ich immer noch eine DNS-Domain als Active Directory Domain nutze, die mir nicht gehört und von einer anderen Firma genutzt wird oder werden könnte? Ich nutze wieder die Domain "msxfaq.de" als meine eigene Firmendomain und behaupte mal, dass MSXFAQ.NET jemand anderem gehören aber von mir als AD-Domain genutzt würde..

  • Blinder Fleck
    All meine Clients sind in der Domain "msxfaq.net" und jegliche Namensauflösung landet intern auf meinem DNS-Server und auch der Browser wird die lokale Domain meist nicht über einen Proxy-Server senden. Ich kann also keinerlei Dienste der richtigen MSXFAQ.NET-Adresse erreichen und bin quasi Blind in diese Richtung. Aber ich gebe gerne zu, das dieses "Problem" die meisten Firmen nur wenig tangieren wird und notfalls könnte man ja auch noch tricksen, dass es doch geht. Den Fall eines "Kaufs" der anderen Firma mit längerer Koexistenz ist wohl noch unwahrscheinlicher.
  • DNS-Spuren
    Es kritischer wird es aber nun, wenn ihre Anwender im Homeoffice sind. Der PC weiß ja erst einmal nicht, dass er nicht in der Firma ist und versucht dies durch DNS-Anfragen u.a. Prüfungen zu ermitteln. In diesem Fall landen aber nun all diese DNS-Anfragen bei dem Besitzer der MSXFAQ.NET im Internet. Im einfachsten Fall passiert nichts und der echte Besitzer wundert sich vielleicht über ein paar komische DNS-Anfragen. Er könnte aber auch alle DNS-Anfragen mitschneiden und sieht dann sehr wohl all die Anfragen nach Domain Controllern, z.B. _ldap_tcp.msxfaq.net, WPAD-Adressen etc. Es dürfte ein paar Wochen dauern aber mit etwas Glück hat der MSXFAQ.NET Besitzer allein über die DNS-Anfragen einen guten Überblick über die internen Servernamen und ihre Topologie
  • ISATAP
    Kennen Sie die Technik, per DNS-Auflösung in einer IPv4-Welt eine "Brücke" in die IPv6-Welt zu schlagen? Als MSXFAQ.NET-Besitzer kann ich so ein ISATAP-Gateway bauen und ehe Sie sich versehen, sind alle ihre PCs aus dem Homeoffice auch noch per IPv6 miteinander verbunden. Nicht umsonst hat der Microsoft DNS-Server diesen Namen "geblockt" aber darauf muss der Besitzer der MSXFAQ.NET keine Rücksicht nehmen. Er addiert einfach einen seiner bösen PCs mit in das Netzwerk und schaut sich um. Ein PC ist vielleicht nicht sicher genug oder dient als Brücke durch das VPN in ihr Firmennetzwerk.
  • VPN Probe Host
    Viele VPN-Systeme starten eine DNS-Anfrage auf einen internen Namen, der im Internet nicht auflösbar ist um dann ein VPN zu starten. Das macht Direct Access schon seit Windows 2008 so. Zum Glück prüft der Client nicht nur die Erreichbarkeit per HTTPS sondern auch den Fingerprint des NLS-Zertifikats. Das kann der echte Besitzer kaum austricksen. Aber nicht jede VPN-Lösung funktioniert so
  • (k)einen WebServer mit offiziellem Zertifikat
    Ich kann meinen Server im MSXFAQ.NET-Active Directory nie ein TLS-Zertifikat einer offiziellen PKI geben, was eine Nutzung mit Smartphones und andere Geräten ohne Trust zu einer eigenen Enterprise-CA vereinfachen würde. Aber der echte Besitzer kann sehr wohl einen Webserver mit einem öffentlichen Zertifikat aufsetzen und ihre Anwender werden bei einem Zugriff auf ihr Intranet oder jeden anderen Webserver zuhause nicht mal eine Zertifikatswarnung erhalten.
  • Browser Zoneneinstellung (IE Zonen)
    Da ihre Browser auch noch die AD-Domain als "Trusted Intranet" ansehen, werden Sie auch einige Funktionen erlauben, die "im Internet" besser nicht aktiv sind. Wie werden wohl ihre Anwender reagieren, wenn die eigene Intranet-Seite mit gültigem Zertifikat und dem internen AD-Domainnamen in der Adressleiste den Download eines "Updates" anbietet. Viel einfacher können Sie es einem Trojaner gar nicht mehr machen.
  • Anmelde-Credentials
    Ein Browser könnte sich z.B. abhängig von der 401-Meldung des Webservers versuchen, sich per Kerberos oder NTLM anzumelden. Vielleicht sogar mit schwachen Crypto-Verfahren (RC4, DES, NTLMv1) und damit das Kennwort ermitteln. Viele Administratoren zögern nämlich damit, die Mindestanforderungen auf den Client höher einzustellen, als die Default-Einstellungen von Microsoft.
  • Password Phishing
    Wenn Kerberos/NTLM nicht funktioniert, dann kann der MSXFAQ.NET-Besitzer immer noch eine nette Anmeldseite anzeigen, und den Benutzer bitten die Anmeldung über das Eingabeformular durchzuführen. Quasi als "Backup" und damit den Anwender dazu verleiten, sein AD-Kennwort direkt auf dem Silbertablett zu präsentieren.
  • Abmahnugn
    Es wird immer passieren, dass es auf der Welt mehrere Firmen mit gleichem Namen gibt. Das lässt sich kaum vermeiden und es gibt ja genug Länderdomains, so dass ein Koexistenz möglich ist. Stellen Sie sich aber mal vor, der echte Besitzer hat ein Markenzeichen auf die strittiger Domain und fordert von ihnen die Unterlassung? Er kann ja anhand der DNS-Anfragen sehr gut nachvollziehen, dass Sie diesen Namen immer noch nutzen. Ob so ein Ansinnen vor Gericht dann erfolgt hat, kann ich nicht sagen. Es bleibt ein Risiko, was besser ihr juristischer Beistand bewerten sollte.
  • Inhalts-Phishing
    Zum Schluss noch mal nur etwas nerviges. Der echt Besitzer kann eine eigene "Intranet-Seite" aufbauen und damit Fehlinformationen verteilen und den Betrieb doch merklich stören. Ich denke nur an die Anrufe der Heimanwender, die gar nicht verstehen, wie ihnen geschieht.

Sie sehen also, dass es viel wichtige Gründe gibt, in ihrem Active Directory auf keinen Fall eine DNS-Domain zu nutzen, die ihnen nicht gehört oder nicht gehören könnte.

Kaufen

Der einfachste Weg ist natürlich die DNS-Domain zu kaufen. Allerdings wird der Besitzer sicher sehr schnell ermitteln, wer der Käufer ist und günstig wird es sicher nicht. Vermutlich weiß er schon, dass sie genau diese Domain im internen Active Directory nutzen und eine Änderung ziemlich teuer ist. Entsprechend wird er versuchen einen hohen Preis zu erzielen. Eventuell hilft es, einen Strohmann oder spezialisierte Agentur einzuschalten und selbst unsichtbar zu bleiben. Dennoch habe ich schon gesehen, dass 5-6-stellige Kaufpreise aufgerufen wurden

Manchmal wurde sogar nur eine "Miete" angeboten. Das ist natürlich tückisch, da der Domaininhaber ja weiterhin der Vermieter bleibt und Mietverträge auch an die Marktbedingungen angepasst werden können. Insbesondere wenn Sie die Domain nun sogar offiziell weiter benutzen und deren Verwendung vielleicht sogar noch ausbauen. Ich würde mich darauf nicht einlassen.

Aber was ist denn die Antwort, wenn die Domain nicht gekauft werden kann?

Schutz durch NRPT

Langfristig wird es darauf hinauslaufen, dass sie die Nutzung der fremden Domain aufgeben. Aber auf die Schnelle geht das natürlich nicht. Sie können aber als erste Gegenmaßnahme dafür sorgen, dass ihre Clients für die MSXFAQ.NET-Domain niemals die DNS-Server im Internet fragen sondern immer die lokalen Server. Normalerweise erhält ein Client per DHCP die DNS-Server. Im Firmennetzwerk sind dies die internen DNS-Server, die meist auf dem Domain Controller mitlaufen. Im Homeoffice ist dies dann der DSL-Router und im Hotel der Router zum WLAN.

Es wird kaum funktionieren, über die "hosts" oder "lmhosts" die Internen Server auf IP-Adressen aufzulösen, damit keine DNS-Abfragen erfolgt. Aber schon mit Windows 7 können sie über eine Gruppenrichtlinie oder andere Optionen zur Steuerung von Registrierungsschlüsseln eine NRPT-Tabelle pflegen. Diese "Name Resolution Policy Table schreibt Windows vor, wie wer welche DNS-Domain aufzulösen hat.

Wenn Sie genau einen Standort haben, dann gibt es dort meist auch zwei DNS-Server mit privaten IP-Adressen, die sie per NRPT den Clients auch im Homeoffice vergeben können. Damit lösen die Clients ihre interne AD-Domain nicht mehr über die Default DNS-Server auf. Das funktioniert dann natürlich nur, wenn der Anwender ein VPN aufgebaut hat. Ansonsten sind die Namen nicht auflösbar.

Das ganz funktioniert natürlich nur mit Domain-Joined Computern ab Windows 7. Linux und Mac-Systeme sind ebenso außen vor wie Tablets (IOS/Android) und Smartphones.

Das Setup wird auch etwas aufwändiger, wenn Sie mehrere AD-Standorte mit lokalen DNS-Servern haben und per NRTP dann pro AD-Standort die DNS-Server hinterlegen müssen oder eine globale Richtlinie setzen und per AD-Site-Richtlinie dann die globalen Einstellungen wieder außer Kraft zu setzen. Nur dann können die DNS-Server im internen LAN per DHCP zugewiesen werden.

Diese "Lösung" ist eher ein Quick Fix, den sie ausgiebig testen sollten. Er kann aber die Not lindern

Änderung der DNS-Domain

Auf Dauer werden Sie aber wohl nicht umhin kommen, die aktuelle AD-Domain umzubauen, damit es keinen Konflikt mehr gibt. Dazu stellen ich ihnen drei Optionen kurz vor:

Option Beschreibung

Domain Rename

Die erste Frage lautet immer: "kann man die Domain nicht umbenennen". Und tatsächlich können Sie Active Directory Domänen tatsächlich auch umbenennen. Microsoft Hat den Prozess schon früh (Windows 2000/2003/2008) beschrieben aber für die neueren Versionen wurden die Anleitungen nicht aktualisiert. Sie könnten nun davon ausgehen, dass so ein Rename auch weiter möglich ist. Aber ist das wirklich ein realistisches Szenario denn es gibt ein STOP-Kriterium und das heißt Exchange. Sobald Exchange im Forest installiert ist, können sie den Forest und die Domain nicht mehr umbenennen. Die Verzahnung von Exchange mit dem AD ist so eng, dass dies scheitern wird. Teilweise ist sogar der DN in der Datenbank hinterlegt und kann nicht geändert werden.

Aber auch ohne Exchange ist es alles andere als einfach. Die Mitglieder der Domäne bekommen den Rename sogar noch mit zwei Neustarts mit aber sie müssen für jeden Service prüfe, wie er auf geänderte LDAP-Pfade reagiert.

Domain Migration

Wenn ein Rename entweder durch Exchange verbaut ist oder aufgrund der Komplexität zu risikobehaftet ist, bleibt nur der Neuaufbau der Domain oder des kompletten Forest und eine Migration aller Dienste. Das ist gar nicht mal ein so seltener Fall, denn bei jeder Merger&Aquicistion&Divorce-Aktion von Firmen passiert dies. Migriert wird immer irgendwie. Innerhalb einer Firma läuft es dann auf die gleiche Reihenfolge hinaus:

  • Neues AD aufbauen und parametrisieren
  • Trust zwischen den Forstes aufbauen und ADMT einrichten
  • Benutzer und Gruppen mit SID-History migrieren
  • Clients migrieren
    Manchmal per ADMT aber oft in Kombination einer Neuinstallation der Clients mit aktueller Windows Version oder beim Hardwaretausch
  • Server und Services umstellen
    Auch hier teilweise durch Migration, Neuinstallation, Rückbau oder auch Umzug in die Cloud
  • Rückbau der alten Umgebung

Im Gegensatz zu einem DomainRename kann so eine Umstellung sich auch über Monate oder gar Jahre hinziehen und hat ein geringeres Risiko wie bei einer "Big Bang"-Umstellung

Domain Rückbau/AzureAD

Wenn Sie eine starte Cloud-Nutzung haben, dann kann man schon mal fragen, ob sie ein lokales Active Directory überhaupt noch benötigen. Endgeräte können auch Mitglied des AzureAD sein und mit Intune verwaltet werden. Das klingt vielleicht etwas mutig aber sollte durchaus betrachtet werden.

Welche Option in ihrem Fall das beste Ergebnis liefert, lässt sich erst nach eine Analyse und Risikoabschätzung sagen. Alle drei Optionen haben ihre Vor- und Nachteile und habe ich alle schon begleitet.

Zusammenfassung

Die Nutzung einer DNS-Domain als interner Active Directory Name, die sie nicht im Besitz haben oder unglücklich verloren haben, ist ein permanentes Sicherheitsrisiko für ihre Anwender und die Firma. Sie müssen aus meiner Sicht handelt und mit NRTP können sie eine Besserung erreichen aber keine dauerhafte Lösung. Lesen und verstehen Sie die hier beschrieben Risiken und bewerten Sie, wie lange Sie die aktuelle Umgebung weiter betreiben wollen.

Weitere Links