DNS dynamische Updates und Entra ID Join

Seit Windows 2000 können Computer als Mitglied einer Domäne auch per DNS-Update ihren Host-Record und PTR-Record in der DNS-Zone addieren. Was machen aber Clients, die nicht mehr Mitglied der Domäne sind, sondern z.B. nur noch Entra ID-Joined (AzureAD Join) oder Entra ID Registered in ihrem Netzwerk aktiv sind. Diese haben kein lokales Computerkonto, welches entsprechend berechtigt sein kann.

Der Abschnitt zu EntraID Join Device wurde am Ende addiert.

Klassisches Update

Kein Mensch merkt sich IP-Adressen. Hostname oder URLs sind das Maß der Dinge im Intranet und durch die Namensauflösung im LAN und Internet wird erreicht, dass eine Software über einen Namen die passende Gegenstelle findet. Die meisten Server haben dazu statische IP-Adressen die dann auch im DNS entsprechend eingetragen werden. Da beginnt bei den Domain Controllern, die ihre Einträge in der Zone "_msdsc.<ad-forest>" selbst verwalten. Die meisten Firmen und Administratoren nutzen heute "Dynamische DNS-Updates", ohne dass es ihnen so richtig bewusst ist, was da passiert und wie die Sicherheit gewährleistet ist.

Natürlich gibt es jede Menge "statische Einträge" und das ist speziell im Internet auch besser, dass gewisse Einträge statisch durch einen Administrator oder einen Provisioning-Prozess vorgegeben werden, z.B. NS-Einträge zur Delegierung von neuen Zonen, TXT-Einträge für SPF, DKIM u.a. und natürlich MX-Einträge. Hier ist eine Dynamik definitiv unerwünscht.

DynDNS und andere Dienste, mit denen sich ihr Router bei einem Provider einen Namen hinterlegt, sind auch eine Art "dynamisches DNS" aber nutzen andere Kommunikationswege, auf die ich am Ende eingehe.

Zonen-Einstellungen

Ob dynamische Updates überhaupt erlaubt sind, steuern Sie pro DNS-Zone. Bei einem Windows DNS-Server kann dies nur für AD-integrierte Zonen aktiviert werden. Dabei kennt Windows drei Einstellungen:

  • None
    Es sind keine dynamischen Updates möglich
  • NonSecure and Secure
    Dynamische Updates können unsicher und sicher erfolgen, d.h. jeder Client den den Server erreicht, kann einen DNS-Eintrag addieren.
  • Secure Only
    Nur "authentifizierte Clients" können einen Eintrag verwalten.

Ich rate davon ab, diese Einstellung auf "Nonsecure and secure" zu stellen.

Denken Sie dabei auch an die "Reverse Zonen", d.h. um aus IP-Adressen wieder Namen aufzulösen

Mit Windows 2003 hat Microsoft die "_msdsc"-Zone separiert, d.h. sie können damit die Hauptzone problemlos auch auf anderen DNS-Servern mit eigenen Update-Optionen betreiben, während sie die kritische Zone für die AD-Replikation und Domain Controller weiter auf dem Windows DNS-Server hosten.

Hier sind natürlich beide Zonen auf meinem Server "AD Integriert" und in der Standardkonfiguration.

DNS-Add/Update durch Client

Dann habe ich auf dem Server mit Wireshark einfach alle DNS-Anfragen eines Clients mit protokolliert, der schon Domainmitglied ist und neu eingeschaltet wurde. Wir sehen hier folgende Aktionen

 

  • Paket 1/2 Zuerst fragt der Client nach einem bestehenden Eintrag, der aber nicht vorhanden ist
  • Paket 3/4 Der Client versucht direkt seinen Namen einzutragen, was aber vom DNS-Server verwehrt wird.
  • Paket 5/6 Der Client fragt einen TKEY an, der vom Server beantwortet wird
    Der TKEY ist 24h gültig, so dass spätere Updates keinen neuen TKEY-Handshake nutzen
  • Paket 7/8 Der Client versucht erneut eine Eintragung mit dem signierten TKEY
    Der Client und der DNS-Server kennen ein gemeinsames Geheimnis (Computerschüssel), der hier zur Signatur genutzt wird. Der Eintrag ist erfolgreich

Das erste Paket ist der Versuch eines anonymen Updates. Daher beantwortet dies der DNS-Server im zweiten Pakt mit einem "Refused". Anders als bei einem HTTP-Zugriff (Siehe HTTP Authentication) liefert der DNS-Server aber keinerlei Information über die möglichen Verfahren zur Authentifizierung. Es bleibt also dem Client überlassen, ein passendes Anmeldeverfahren zu verwenden.

 

Mein Windows Client wählt dazu GSS-TSIG.

Der Server bestätigt die erfolgreiche Eintragung 

 

Berechtigungen des DNS-Eintrag

Die Zone steht natürlich auch "Secure Updates" und der in der Zone angelegte Eintrag ist mit entsprechenden ACLs versehen. Hier erscheint das Computerkonto mit den Berechtigungen "Read/Write" 

Der DNS-Server hat also den Eintrag nicht mit seinem Computerkonto oder SYSTEM angelegt. In den erweiterten Eigenschaften wird auch der Computer als "Besitzer" aufgeführt:

Wenn ich eine Zone auf "NonSecure and Secure" stelle, dann melden sich Domain Mitglieder aber weiter "Secure" an und sorgen so dafür, dass ihr Eintrag erstellt und die ACL korrekt gesetzt wird.

Konflikt mit statischem Eintrag

Als Test habe einen statischen Eintrag im DNS gemacht und den Client eine dynamische Registrierung durchführen lassen. Der DNS-Server lehnt die Eintragung mit einem "Refused" ab. Der Client versucht es insgesamt fünf Mal. Versuch 1 und 3 sind anonym und 2,4 und 5 mit GSS-TSIG

 

Der DNS-Server lässt sich natürlich nicht erweichen.

Konflikt mit fremden Eintrag

Ich habe dann absichtlich einem anderen Computerkonto die Berechtigungen auf den DNS-Eintrag gegeben. Das kann ja schon passieren, dass ein Computer mit dem gleichen Namen neu installiert wird, z.B. bei Cloning, VMs-Snapshots etc. Auch hier gibt es das gleiche Verhalten wie bei einem statischen Eintrag:

Der Client versucht es fünf Mal aber der DNS-Server weist alle Versuche mit einem  REFUSE ab.

Anonymer Eintrag

Offen ist noch der Test, wenn es einen Eintrag eines Clients gibt, der "unsecure" angelegt wurde. Welche ACLs hat dieser Eintrag und wer kann ihn ändern?

Reverse DNS

Zu jedem "A"-Record gehört in einem gut gepflegten Netzwerk auch ein passender PTR-Record, damit sie zu einer IP-Adresse auch einen Namen auflösen können. Wenn Sie nun aber in ihre DNS-Zonen schauen, dann finden sie oft gar keinen PTR-Record und das liegt daran, dass zumindest Windows Clients dies nicht per Default machen. Eine dynamische DNS-Eintragung der IP-Adresse zum Hostnamen erfolgt nur, wenn Sie auf der Netzwerkkarte die Option "Use this connection's DNS suffix in DNS registration" aktivieren.

Diese Checkbox ist aber per Default nicht aktiv. Sobald sie diese Checkbox aktivieren, trägt der Client die Adressen direkt ohne Neustart o.ä. nach:

Sie sie aber an dem "DNS Dynamic Update" schon sehen, versucht der Client alle Namen zu registrieren. Bei mir kommt im DNS-Server dann folgendes an:

Bei einer Anfrage per NSLOOKUP bekomme ich dann per "Round Robin" immer einen anderen Namen zurück:

Das mag verwirren. Auch bei den Berechtigungen hat das Computerkonto nun zusätzlich zu "Read/Write" auch "Vollzugriff".

Ein Risiko sehe ich darin nun aber nicht.

Gruppenrichtlinien

Der Verhalten des DNS-Clients können Sie über Gruppenrichtlinien steuern. Interessant sind hier die Einstellung für die Checkbox oder auch die generelle Möglichkeit die PTR-Erstellung zu steuern.

Die Anleitung zu "Register PTR records" schreibt:

 

Wenn nicht konfiguriert ist, dann wird ein PTR nur eingetragen, wenn vorher der A-Eintrag erfolgreich war. Der Client muss also zwei "DNS Update"-Requests senden.

DNS-Remove durch Client

Wird der Client "geplant" heruntergefahren, dann kann er sich auch wieder deregistrieren. Auch dies in in Wireshark gut zu sehen, hier am Beispiel einer Windows XP Workstation.

Interessanterweise hat ein Windows 2008R2-Server beim "Shutdown" seinen Eintrag nicht per DNS wieder ausgetragen.

Refresh und Scavening

Dynamische Einträge können also durchaus "bestehen" bleiben und irgendwann stören. Viel Speicherplatz braucht ein DNS-Eintrag allerdings nicht. Wer aber z.B. über DNS eine Liste der aktiven Clients ermitteln möchte, wird alte Einträge gerne entfernt wissen. Auf der anderen Seite kann ein alter Eintrag natürlich auch eine gewisse Information für spätere Analysen bereithalten. Hier sollten Sie sich mit den DHCP-Einstellungen abstimmen. Es macht wenig Sinn, wenn für einen DHCP-Client einen registrierten Namen weiter im DNS besteht, obwohl die IP-Adresse schon lange anderweitig vergeben ist.

Ein Windows Client aktualisiert laut Microsoft seine DNS-Einträge alle 24h, unabhängig von den per DHCP vorgegebenen Lease-Zeiten. 


Quelle: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-dns-dynamic-updates-windows-server-2003#how-windows-based-computers-update-their-dns-names

Der Wert kann über die Registrierung mit dem Schlüssel "DefaultRegistrationRefreshInterval" angepasst werden. Eleganter ist auch hier die Steuerung über Gruppenrichtlinien.

Die Richtline ändert die Konfiguration, welche umgehend aktiv wird. Beim ersten Start wird aber Windows natürlich noch ohne die entsprechende GPO die Standardwerte nutzen.

Eine Anpassung ist in der Regel nicht erforderlich

Damit wird ja nur der Refresh gesteuert. Wenn ein Client nicht mehr vorhanden ist, ist aber der DNS-Server für das Wegräumen zuständig und in der Standardeinstellung ist zumindest bei Windows diese Funktion abgeschaltet. Ein DNS-Eintrag bleibt damit "für immer" erhalten aber wenn ein anderer Client die gleiche IP-Adresse bekommt, dann addiert er einfach seinen eigenen A/AAAA-Eintrag mit der gleichen IP-Adresse. Der bestehende Eintrag stört nicht bei "Forward Lookup"-Zonen. Ein PTR-Eintrag in die Reverse-Lookup-Zone blockiert aber keinen Neueintrag. Es gibt nur mehrere Einträge.

Solche "veralteten" Einträge können Sie natürlich über das DNS-Scavening entfernen lassen.

In der Regel melden sich Clients einmal am Tag und erneuern damit ihren Eintrag. Die Einstellungen wirken natürlich auf alle Einträge und wählen Sie bitte die Werte nicht zu klein.

Ich hatte schon einen Support-Case, bei denen das Scavening auch essentielle Einträge von Domain Controllern entfernt hat, weil diese nicht oft genug aktualisiert wurde

DNS-Update durch DHCP

Schon früher gab es Endgeräte, die per DHCP ihre IP-Adresse bekommen und dann als Eintrag im DNS eingetragen wurden. Wenn die Clients aber nicht "Domainmitglied" waren, dann konnten Sie entweder ihren Namen gar nicht eintragen oder sie mussten die DNS-Zone auf "unsichere Updates" stellen. Das ist nicht sicher aber es gibt die Möglichkeit, dass der DHCP-Server die Eintragungen im Auftrag des Client macht. Bei der ersten DHCP-Anfrage bietet ein Windows Client von sich aus schon einmal einige Informationen an:

Ein DHCP-Server könnte hier schon einmal den kurzen Hostnamen auswerten. Aber das hilft ihm noch nicht weiter. Der DHCP-Server bietet dem Endgerät dann u.a. IP-Adresse an und wenn der Client die IP-Adresse dann bestätigt, sendet er als "Option 81" seinen FQDN mit. Hier am Beispiel meines Clients im Netzwerk von Net at Work.

Diese Information kann der DHCP-Server nun nutzen, um den Client im DNS einzutragen. Das wird der DHCP-Server natürlich nur tun, wenn er entsprechend autorisiert und konfiguriert ist.

Wenn Sie einen Cluster aus zwei DHCP-Servern betreiben, dann müssen Sie ein Dienstkonto für die Pflege der DNS-Einträge hinterlegen, damit bei einem Failover auf den anderen Server dieser die Einträge ebenfalls aktualisieren und löschen kann. 

Der DHCP-Server wird dann aber auch "Besitzer" der DNS-Einträge, d.h. das ist bei einem späteren Wechsel zu berücksichtigen, z.B. indem die dynamische Einträge gelöscht werden, damit sie dann der Client selbst wieder eintragen kann.

EntraID Join Device

Die Lösung über den DHCP-Server ist meines Wissens auch der einzige Weg, wie Sie z.B. "Entra ID Joined" Endgeräte in einer lokalen Umgebung in DNS einbinden können. Solche Geräte sind ja nicht "Domainmitglied" und können sich daher erst einmal nicht am Windows DNS-Server authentifizieren. Es gibt schlicht das lokale Computerkonto nicht, mit dem der DNS-Server und der Client ein "Shared Secret" besitzen. Um ihr Netzwerk aber gegen fremde Geräte zu schützen, sollten Sie über 802.1x/NPS natürlich einen Zugangsschutz definieren. Die Kette sieht dann wie folgt aus:

  • Internet PKI
    Für die Anmeldung eines Clients am Switch, WLAN oder VPN über Zertifikate brauchen Sie eine eigene PKI, die  zumindest Computerzertifikate ausstellt. Für Domain-Mitglieder können Sie das AutoEnrollment über Gruppenrichtlinien vereinfachen.
  • Intune und interne PKI
    Damit "Entra ID-Joined" Geräte sich anmelden können, muss Intune ein Computerzertifikat für die Geräte ausrollen. Das geht per PKCS oder SCEP z.B. mit dem Certificate Connector
  • Der Client verbindet sich mit der Firma
    Dazu nutzt er sein per Intune erhaltenes Zertifikat und kommt damit in das entsprechende Netzwerk
  • IP-Adresse per DHCP-Server
    Der Client stellt eine DHCP-Anfrage, die vom DHCP-Server beantwortet wird. Der Client bestätigt die angebotene IP-Adresse und liefert seinen FQDN mit. Achten Sie darauf, dass der Client auch die DNS-Domain per DHCP oder Intune Richtline bekommen hat.
  • DHCP-Server registriert Client im DNS
    Ab sofort können Sie z.B. für Fehlersuchen mit einfachen DNS-Abfragen zu einem Client eine IP-Adresse auflösen.
  • Network Location Awareness
    Eine Besonderheit müssen Sie noch beachten. Computer, die nicht Mitglied einer Domain sind, haben auf der Netzwerkkarte erst einmal kein "Domain-Profil". Auch wenn der Entra ID-joined Client sich per 802.1x authentifiziert und damit in ihrem Haus-LAN ist, so ist keine Logik aktiv, um die Erreichbarkeit eines Domain Controllers zu prüfen und dann das Firewall-Profil auf der Netzwerkkarte zu ändern. Daher können Sie solche Geräte erst einmal nicht per PING o.ä. erreichen, da Sie aus ihrer Sicht immer noch im Internet sind. Die Lösung besteht darin, eine per TLS nur im internen LAN erreichbare Gegenstelle bereitzustellen und über Intune-Richtlinien diesen als Prüfadresse zu hinterlegen. Der Entra ID-joined Client versucht dann eine TLS-Verbindung zu dieser Adresse aufzubauen und wenn er so ein gültiges und vertrauenswürdiges Zertifikat bekommt, dann geht er von einem vertrauenswürdigen Netzwerk aus. Wer schon einmal mit Direct Access zu tun hatte, kennt diesen Weg schon.

Mit der passenden Konfiguration schaffen Sie es so, dass Entra ID-Joined Devices sich nicht nur an ihrem Netzwerk anmelden, sondern per DNS auflösbar sind und das passende Firewall-Profil aktiviert haben.

Wenn Sie Unterstützung bei der Umsetzung benötigen, dann wenn Sie sich einfach an mich oder Net at Work

Weitere Links