9
Sollte jedes Subnetz einen Domänencontroller haben?
Hallo zusammen,
ich versuche gerade unsere natürlich gewachsene Infrastruktur zu entwirren.
Mein Ziel ist es, das Netz aus Sicherheitsaspekten stärker zu segmentieren. Es geht um eine Windows 2012R2 Domäne mit einigen Servern und hauptsächlich Windows 10 Clients. Die Idee ist, die Sever ein separates Netz zu verlagern (bzw. die Clients rauszuschmeißen). Die Clients können ja weiterhin auf ihren DC zugreifen (korrektes DNS und korrekte Firewallregeln vorausgesetzt), auch wenn der DC in einem anderen Subnetz liegt. In Zeiten der Namensauflösung über NetBIOS und WINS war es ja eher die Regel, dass die DCs in der Broadcastdomäne verfügbar waren.
Wie ist da der Stand heute? Spricht etwas dagegen, die DCs von den Clients zu separieren (außer, dass ich dann den FQDN etwas öfter tippen muss. wir reden auch vom selben Standort, kein VPN.)?
Oder sollte man besser mit RODCs arbeiten (was mir zu Zeit wegen zusätzlichen Ressourcen und Lizenzen nicht so sympathisch ist - Es ist gerade Corona!).
Grüße
lcer
ich versuche gerade unsere natürlich gewachsene Infrastruktur zu entwirren.
Mein Ziel ist es, das Netz aus Sicherheitsaspekten stärker zu segmentieren. Es geht um eine Windows 2012R2 Domäne mit einigen Servern und hauptsächlich Windows 10 Clients. Die Idee ist, die Sever ein separates Netz zu verlagern (bzw. die Clients rauszuschmeißen). Die Clients können ja weiterhin auf ihren DC zugreifen (korrektes DNS und korrekte Firewallregeln vorausgesetzt), auch wenn der DC in einem anderen Subnetz liegt. In Zeiten der Namensauflösung über NetBIOS und WINS war es ja eher die Regel, dass die DCs in der Broadcastdomäne verfügbar waren.
Wie ist da der Stand heute? Spricht etwas dagegen, die DCs von den Clients zu separieren (außer, dass ich dann den FQDN etwas öfter tippen muss. wir reden auch vom selben Standort, kein VPN.)?
Oder sollte man besser mit RODCs arbeiten (was mir zu Zeit wegen zusätzlichen Ressourcen und Lizenzen nicht so sympathisch ist - Es ist gerade Corona!).
Grüße
lcer
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 573167
Url: https://administrator.de/contentid/573167
Printed on: April 24, 2024 at 05:04 o'clock
9 Comments
Latest comment
Guten Morgen,
das kommt stark drauf an, wie dein restliches Design ist.
Grundsätzlich trenne ich dies persönlich mittlerweile durchgehend. Aber mit passender DNS Infrastruktur musst du da den FQDN nicht öfter tippen. Wenn du aber eine für dein Netz zutreffende Aussage haben möchtest, solltest du das am Netz und mit allen Nebenparametern prüfen lassen. Es gab und gibt in einigen Netzen immer noch Hürden, die das obige nicht machbar werden lassen.
Grüße,
Christian
certifiedit.net
das kommt stark drauf an, wie dein restliches Design ist.
Grundsätzlich trenne ich dies persönlich mittlerweile durchgehend. Aber mit passender DNS Infrastruktur musst du da den FQDN nicht öfter tippen. Wenn du aber eine für dein Netz zutreffende Aussage haben möchtest, solltest du das am Netz und mit allen Nebenparametern prüfen lassen. Es gab und gibt in einigen Netzen immer noch Hürden, die das obige nicht machbar werden lassen.
Grüße,
Christian
certifiedit.net
Funktionell gesehen reicht ein Domain Controller für alle Subnetze und auch alle Niederlassungen. Einen weiteren Controller würde ich zwecks Ausfallsicherheit hinzufügen. Weitere Controller würde ich nur in Niederlassungen hinzufügen, wo ein VPN Ausfall zu einem Arbeitsausfall von mehreren Leuten führen würde. Innerhalb eines Standortes reicht also ein Pärchen.
FQDNs musst du nicht eintippen, wenn die Clients per DHCP die richtige Suchdomain übertragen bekommen haben.
FQDNs musst du nicht eintippen, wenn die Clients per DHCP die richtige Suchdomain übertragen bekommen haben.
Hi,
die Anzahl und Platzierung der DC's richtet sich nicht nach Anzahl der Subnetze sondern rein nach der qualitativen Verfügbarkeit der DC's für die AD Clients.
Wenn Du also ein Gebäude hast mit 2 Subnetzen und die Verbindung zwischen diesen Subnetzen ist z.B. über ein WLAN geroutet (dann eigentlich 3 Subnetze), welches theoretisch gestört werden könnte. Die beiden DC sind im 1. Subnetz. Wenn jetzt im 2. Subnetz ununterbrochen ein DC verfügbar sein muss - warum auch immer - dann wäre das ein Grund, einen der DC in das 2. Subnetz zu verlegen.
Wenn aber davon auszugehen ist, dass die Verbindung zwischen den Subnetzen hochverfügbar ist, dann können die DC in einem Subnetz bleiben.
Wenn das zweite Subnetz mehr oder weniger öffentlich zugänglich ist, dann könnte es Sinn machen, dort einen RODC zu platzieren und per Firewall-Regeln nur von diesem RODC Verbindungen zu den DC's im ersten Subnetz zuzulassen.
usw.
E.
die Anzahl und Platzierung der DC's richtet sich nicht nach Anzahl der Subnetze sondern rein nach der qualitativen Verfügbarkeit der DC's für die AD Clients.
Wenn Du also ein Gebäude hast mit 2 Subnetzen und die Verbindung zwischen diesen Subnetzen ist z.B. über ein WLAN geroutet (dann eigentlich 3 Subnetze), welches theoretisch gestört werden könnte. Die beiden DC sind im 1. Subnetz. Wenn jetzt im 2. Subnetz ununterbrochen ein DC verfügbar sein muss - warum auch immer - dann wäre das ein Grund, einen der DC in das 2. Subnetz zu verlegen.
Wenn aber davon auszugehen ist, dass die Verbindung zwischen den Subnetzen hochverfügbar ist, dann können die DC in einem Subnetz bleiben.
Wenn das zweite Subnetz mehr oder weniger öffentlich zugänglich ist, dann könnte es Sinn machen, dort einen RODC zu platzieren und per Firewall-Regeln nur von diesem RODC Verbindungen zu den DC's im ersten Subnetz zuzulassen.
usw.
E.
Zitat von @lcer00:
Hallo zusammen,
ich versuche gerade unsere natürlich gewachsene Infrastruktur zu entwirren.
das ist immer gutHallo zusammen,
ich versuche gerade unsere natürlich gewachsene Infrastruktur zu entwirren.
Mein Ziel ist es, das Netz aus Sicherheitsaspekten stärker zu segmentieren. Es geht um eine Windows 2012R2 Domäne mit einigen Servern und hauptsächlich Windows 10 Clients. Die Idee ist, die Sever ein separates Netz zu verlagern (bzw. die Clients rauszuschmeißen). Die Clients können ja weiterhin auf ihren DC zugreifen (korrektes DNS und korrekte Firewallregeln vorausgesetzt), auch wenn der DC in einem anderen Subnetz liegt. In Zeiten der Namensauflösung über NetBIOS und WINS war es ja eher die Regel, dass die DCs in der Broadcastdomäne verfügbar waren.
broadcastdomänen sind Schnee von gestern, Server 2012 und höher verlangen zwingend ein Microsoft DNS, Clients registrieren sich (wenn sie auf DHCP stehen) ohnehin automatisch.Wie ist da der Stand heute? Spricht etwas dagegen, die DCs von den Clients zu separieren (außer, dass ich dann den FQDN etwas öfter tippen muss. wir reden auch vom selben Standort, kein VPN.)?
das hat mit FQDN erstmal rein garnichts zu tun. Solange alle Hosts "flach" strukturiert sind, sprich hostname.domäne.irgendwas dann geht die Namensauflösung ganz von alleine... schon der Domänenbeitritt eines Clients erfordert ein funktioierendes DNS, und wer Clietns in andere Subnetze verlagert, muß sich ja sowieso Gedanken über das Routing machen. Sprich ist der Default Gateway bzw die statische Route in beiden Richtungen korrekt aufgesetzt, dann geht DNS und alles was davon abhängt, natürlich weiter.
Oder sollte man besser mit RODCs arbeiten (was mir zu Zeit wegen zusätzlichen Ressourcen und Lizenzen nicht so sympathisch ist - Es ist gerade Corona!).
Grüße
lcer
muß man ausrechnen... ein DC ist mit einem Core ca. 30-60 Sekudnen mit einem Loginvorgang beschäftigt (GPO auswerten, Cleintidentität verifizieren, NLA Check falls NLA aktiv ist...) Wenn man also verzögerte Logins am Montag morgen feststellt und hohe Last auf dem DC, der wird wohl einen zweiten DC benötigen, ich meine RODC machen nur Sinn, wenn man Filialen hat die über langsame Standleitungen angebunden sind. WEil dann alle Anmeldevorgänge aim lokalen DC stattfinden und nicht über einen, der remote ist.Grüße
lcer
Zitat von @lcer00:
In Zeiten der Namensauflösung über NetBIOS und WINS war es ja eher die Regel, dass die DCs in der Broadcastdomäne verfügbar waren.
In Zeiten der Namensauflösung über NetBIOS und WINS war es ja eher die Regel, dass die DCs in der Broadcastdomäne verfügbar waren.
Nur dann, wenn der Admin sein Handwerk nicht verstanden hat.
Auch damals konnte man ohne weiteres DCs "einsparen", wenn man DNS, WINS und ggf. auch lmhosts korrekt konfiguriert hat.
Wie ist da der Stand heute? Spricht etwas dagegen, die DCs von den Clients zu separieren
Nein, wenn der die Infrastruktur und das DNS ordentllich ist nicht.
... (außer, dass ich dann den FQDN etwas öfter tippen muss. wir reden auch vom selben Standort, kein VPN.)?
Wieso muß man die FQDN eintippen? Hast Du an den Clients nicht die search-domains richtig gesetzt?
Oder sollte man besser mit RODCs arbeiten (was mir zu Zeit wegen zusätzlichen Ressourcen und Lizenzen nicht so sympathisch ist - Es ist gerade Corona!).
Das kommt auf die Infrastruktur an. Normalerweise kann man mit einem einzigen DC alles "abfackeln". Meist packt man aber mindesten einen zweiten wegen der Redundanz dazu. Je nach Topologie und Last kann es sinnvoll sein, deutlich mehr zu haben.
lks
Hallo,
Clients und Server in separate Netze zu stecken ist sogar sehr ratsam!
Du brauchst eigentlich für dein Vorhaben nur einen DHCP-Server der in dem entsprechenden Scope die relevanten Optionen mitteilt, also DNS-Server, Domänenname und Gateway (ggfs. auch andere Optionen, aber hört sich nicht so an als wäre das bei dir notwendig).
Und wenn zwischen den Netzen eine Firewall hängt, müssen da natürlich die Regeln so angelegt werden dass deine Anwendungen mit ihren jeweiligen Servern kommunizieren können.
Da es dir um Sicherheit geht, sollten dann auch nur die Ports geöffnet werden die auch benötigt werden. Wenn alle Clients über alle Ports mit allen Servern kommunizieren können, nützt dir die Netz-Segmentierung ja auch nix.
Clients und Server in separate Netze zu stecken ist sogar sehr ratsam!
Du brauchst eigentlich für dein Vorhaben nur einen DHCP-Server der in dem entsprechenden Scope die relevanten Optionen mitteilt, also DNS-Server, Domänenname und Gateway (ggfs. auch andere Optionen, aber hört sich nicht so an als wäre das bei dir notwendig).
Und wenn zwischen den Netzen eine Firewall hängt, müssen da natürlich die Regeln so angelegt werden dass deine Anwendungen mit ihren jeweiligen Servern kommunizieren können.
Da es dir um Sicherheit geht, sollten dann auch nur die Ports geöffnet werden die auch benötigt werden. Wenn alle Clients über alle Ports mit allen Servern kommunizieren können, nützt dir die Netz-Segmentierung ja auch nix.
Zitat von @DrAlcome:
Wenn alle Clients über alle Ports mit allen Servern kommunizieren können, nützt dir die Netz-Segmentierung ja auch nix.
Wenn alle Clients über alle Ports mit allen Servern kommunizieren können, nützt dir die Netz-Segmentierung ja auch nix.
Moin,
Segmentierung macht man nicht nur wegen der Sicherheit, sondern u.a auch der einfacheren Administrierbarkeit und der Lastverteilung wegen. Sicherheit ist i.d.R. nur ein Aspekt unter vielen.
lks
Richtig, ich hab's halt nochmal angesprochen weil es ihm ja in erster Linie um den Sicherheitsaspekt geht.
In der Regel haben Domänencontroller in Broadcast-Domänen von Clients nichts verloren!
Bis auf wenige Ausnahmefälle gehören Server in ein separates Subnetz.
Bis auf wenige Ausnahmefälle gehören Server in ein separates Subnetz.
