AD-Standortzuordnung gegenüber dem Festnageln eines Domänencontrollers für VPN-Clients

Remotezugriffsclients in einem VPN-Pool können am Ende mit einem Domänencontroller am anderen Ende der Welt sprechen, und das lässt sich auf zwei Arten beheben: den Pool als Active-Directory-Subnetz beschreiben, das an den Standort mit den richtigen Controllern gebunden ist, oder den Client beziehungsweise die Anwendung an einen bestimmten Controller nageln. Das erste ist eine Topologieaussage, auf die DC Locator reagieren kann. Das zweite ist eine Überschreibung pro Anwendung, die die Topologie vollständig ignoriert. Sie kosten Unterschiedliches, und heute nach dem schnelleren zu greifen ist genau der Weg, auf dem ein Verzeichnisteam am Ende beides pflegt.

Was jeder Ansatz tatsächlich ändert

Ein Subnetzobjekt ist ein Verzeichniseintrag, der sagt, zu welchem Standort ein Adressbereich gehört. Mit dem Active-Directory-Modul und einem vorhandenen Standort ist der Vorgang klein genug, um ihn vorab anzuzeigen:

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf zeigt den Schreibvorgang im Verzeichnis vorab an. Es erzeugt das Objekt nicht und prüft nicht, ob ein Client aus diesem Bereich irgendetwas erreichen kann, und genau das erwarten die Leute. DC Locator liest das Standortmodell, wenn er Diensteinträge auflöst, ein genaues Subnetzobjekt ändert also, was dem Client angeboten wird.

Festnageln wirkt auf einer anderen Ebene. Ein fester Controllername in einer Anwendungskonfiguration, eine LDAP-Zeichenkette mit einem Host darin oder ein Registrierungswert, der einen bevorzugten Server benennt, nehmen alle die Erkennung aus dem Pfad. Die Anwendung spricht mit diesem Controller, bis jemand die Einstellung ändert, und Failover ist das, was diese Anwendung selbst umsetzt.

Wo die Subnetzzuordnung gewinnt

Den Pool zuzuordnen beschreibt den Netzwerkstandort einmal, für jeden Client, der DC Locator nutzt. Wächst der Pool von einem /24 auf drei, ändert sich das Modell in zwei oder drei Objekten statt in einer Anwendungsliste. Das ist der ganze Vorteil, und er ist groß, wenn die Clientpopulation nicht unter Ihrer Kontrolle ist.

Der Haken ist, dass das Objekt zur Adresse passen muss, die der Controller tatsächlich sieht. Übersetzt das VPN-Gateway jeden Client in eine Hub-Adresse, beschreibt das Hinzufügen des unübersetzten Pools einen Netzwerkstandort, den kein Controller je beobachtet. Entscheiden Sie früh, ob das Design die Quelladresse des Clients erhält, und wenn nicht, ordnen Sie den übersetzten Bereich zu statt des Pools, den Sie auf dem VPN-Server konfiguriert haben.

Eine zweite Grenze: Das Standortmodell ist eine Präferenz und eine Topologieaussage. Es macht einen Controller nicht erreichbar und gewährt einem Benutzer nichts. Erreichbarkeit leisten Routen und Firewallrichtlinie; Autorisierung leistet die Kontorichtlinie.

Wo das Festnageln gewinnt

Festnageln ist die richtige Antwort, wenn Erkennung nicht funktionieren kann: eine Alt-Anwendung, die einen Controller über einen Namen auflöst, den Sie nicht ändern können, ein Filter, der genau eine Controlleradresse zulässt, oder eine feste Servergruppe, in der der Controller Teil des Anwendungsdesigns ist. In diesen Fällen ist die Festlegung Dokumentation einer echten Einschränkung und keine Abkürzung.

Ihr Preis ist das Gegenteil der Zuordnung. Ein festgelegter Name folgt dem Pool nicht, schaltet nicht um, wenn die Anwendung es nicht kann, und übersteht weder Umbenennung noch Außerbetriebnahme eines Controllers ohne Inventur. Er verbirgt außerdem Topologieprobleme, weil jeder festgelegte Client gesund aussieht, während das Standortmodell still verrottet.

Die gewöhnlichen Adresseinträge der Domäne durch einen bevorzugten Server zu ersetzen ist keine dritte Option. Es bricht jeden Nutzer, der den normalen Erkennungssatz erwartet, und steuert weiterhin nicht, wie ein verzeichnisbewusster Client einen Standort wählt.

Nach drei Bedingungen entscheiden

Fragen Sie sie in dieser Reihenfolge, und die Entscheidung fällt meist von selbst. Erstens: Nutzt die Anwendung überhaupt DC Locator, oder trägt sie bereits eine Controlleradresse? Zweitens: Sieht der Controller die Pooladresse oder eine übersetzte? Drittens: Wie oft ändert sich der Pool im Vergleich dazu, an wie vielen Stellen eine Festlegung aktualisiert werden müsste?

Verzeichnisbewusste Anwendungen plus quelladresserhaltendes Routing plus ein Pool, der sich ändert: Subnetz zuordnen. Eine Anwendung, die nicht erkennen kann, oder ein Filter, der eine Adresse zulässt: festnageln und begründen. Alles andere ist ein Fall für die Reparatur der Topologie statt für eine weitere Überschreibung.

Vom VPN-Client aus prüfen und die Verträge getrennt halten

Testen Sie vom tatsächlichen Fernweg aus, nicht von einer LAN-Workstation, die schon am Standort sitzt. Nur die Sicht des Clients selbst zählt:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

Ist der gemeldete Standort der zugeordnete, passt das Objekt. Meldet der Client keinen Standort, fällt die vorgetragene Adresse in kein Subnetzobjekt, was meist eine Übersetzung oder ein veraltetes Präfix bedeutet. Prüfen Sie dann, ob der gewählte Controller der beabsichtigte ist, bevor Sie annehmen, die Zuordnung sei gescheitert, denn Clients cachen Erkennungsergebnisse, und Failover darf legitim einen anderen Controller wählen.

Halten Sie die drei Verträge in einem Dokument: den Pool und seine Subnetzobjekte, die vom VPN-Weg erreichbaren Controller und die Richtlinie, die entscheidet, was ein angemeldeter Benutzer tun darf. Ein Standort ist keine Firewallregel und keine Isolationsgrenze, und die nächste Pooländerung wird entfernte Benutzer still vom Netzwerkmodell des Verzeichnisses abkoppeln, wenn Zuordnung, Routen und dokumentierte Alternativen sich nicht gemeinsam bewegen.