BpDk 0 Geschrieben 19. Dezember 2018 Melden Teilen Geschrieben 19. Dezember 2018 Hallo Leute, wir haben in unserer DMZ eine Win2012 R2 VM laufen, die als Remote-Desktop Gateway dient. Das Remotedesktop Gateway ist Mitglied der Domäne. Damit dies möglich ist, wurden an der Firewall die dafür benötigten Ports (ESP Tunnel, DNS, LDAP,LSASS,IKE) zum "PRIMÄREN" DC freigeschaltet. Nun haben wir das Problem, dass beim Neustart der VM das "Domänen-Netwerk-Profil" nicht erkannt wird und deshalb im "Öffentlichen-Netzwerk-Profil" landet. Beim Auswerten der Firewall-Logs ist aufgefallen, dass versucht wird sich mit dem sekundären DC zu verbinden. Diese Pakete werden natürlich verworfen. Ich vermute daher kommt das Problem. Kann ich dem Server sagen, dass er lediglich mit dem primären DC kommunizieren soll, bzw in welchem Szenario wird versucht den sekundären DC zu erreichen? Ich bedanke mich im voraus für hilfreiche Antworten. Liebe Grüße Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 19. Dezember 2018 Melden Teilen Geschrieben 19. Dezember 2018 Moin, dein Problem ist, dass das Konstrukt nicht besonders sinnvoll ist. Ein Rechner in der DMZ hat typischerweise nichts in der Domäne im LAN zu suchen. Umgekehrt sind solche Gateways heute typischerweise nicht mehr in der DMZ lokalisiert, sondern werden über Konstrukte wie Reverse Proxies angesprochen. Ob das bei einem RDS-Gateway auch gilt, kann ich mangels Fachschwerpunkt an der Stelle nicht sagen. Da dein RDS-Gateway normales Domänenmitglied ist, nutzt es die normalen Kommunikationswege zum AD, also alle verfügbaren DCs. Das einzuschränken, wäre wenig sinnvoll, denn dann würde der Ausfall eines DCs zum vollständigen Funktionsverlust des Gateways führen. Gruß, Nils Zitieren Link zu diesem Kommentar
BpDk 0 Geschrieben 19. Dezember 2018 Autor Melden Teilen Geschrieben 19. Dezember 2018 vor 4 Minuten schrieb NilsK: Moin, dein Problem ist, dass das Konstrukt nicht besonders sinnvoll ist. Ein Rechner in der DMZ hat typischerweise nichts in der Domäne im LAN zu suchen. Umgekehrt sind solche Gateways heute typischerweise nicht mehr in der DMZ lokalisiert, sondern werden über Konstrukte wie Reverse Proxies angesprochen. Ob das bei einem RDS-Gateway auch gilt, kann ich mangels Fachschwerpunkt an der Stelle nicht sagen. Da dein RDS-Gateway normales Domänenmitglied ist, nutzt es die normalen Kommunikationswege zum AD, also alle verfügbaren DCs. Das einzuschränken, wäre wenig sinnvoll, denn dann würde der Ausfall eines DCs zum vollständigen Funktionsverlust des Gateways führen. Gruß, Nils Vielen Dank für deine schnelle Antwort. Du hast natürlich Recht was den Aufbau betrifft. Mittlerweile betreiben wir für andere Anwendungen ein Reverse-Proxy und könnten diesen nutzen. Das Gateway wurde vorher in Betrieb genommen. Wie kann ich die DC Authentifizierung einschränken? Ich vermute über die Registry? Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 19. Dezember 2018 Melden Teilen Geschrieben 19. Dezember 2018 Moin, der einfachste Weg wäre, die DMZ als AD-Site zu definieren und in dieser Site nur einen DC zu haben. Dann das Subnet der DMZ dieser Site zuordnen. Dadurch würden die Server aus der DMZ immer primär diesen DC anzusprechen versuchen. Allerdings hat das den Nachteil, dass dieser DC im Normalbetrieb von keinem anderen Client verwendet wird. Wird man also kaum wollen. Grundsätzlich kann man auch per Registry spezifische DCs vorgeben - meine ich zumindest. Da ich das allerdings für einen sehr schlechten Weg halte, recherchiere ich das nicht weiter. Das müsstest du dann selbst suchen. Ändere das Design. Alles andere ist Murks. Gruß, Nils Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 19. Dezember 2018 Melden Teilen Geschrieben 19. Dezember 2018 Ich würde das Konstrukt umbauen und das GW in ins interne Netze holen. Vor allem wenn ja sogar schon der reversproxy da ist. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.