Domain Controller lokatie keuze

[relaxteb]

Op dit moment hebben wij een webcluster(192.168.30.0) met daarachter een database(192.168.10.0) segment. Dit is gescheiden door een firewall (in ons geval een pix). 10 is het veilige segment en 30 het onveilige segment





Aangezien het aantal servers groeit en dus ook het beheer daarmee flink toeneemt zijn we toe aan een domain structuur. Nou kan ik wel advies gebruiken over de plaats waar de domain controllers komen te staan.


Als we uitgaan van 1 domain zijn er een aantal opties :


2 Domain controllers in het 10 segment.

Nadeel hiervan is dat er een flink aantal poorten opengezet moet worden van het 30 naar het 10 segment.


2 Domain controllers in het 30 segment.

Nadeel hiervan is dat de Domain Controllers dus op een onveilig segment staan zonder firewall ertussen.


2 Domain controllers in een DMZ.

Dit zou een mooie optie zijn, echter hebben we geen DMZ interface meer vrij op de firewall.


1 Domain controller per segment.

Nadeel hier is dat wanneer er 1 domain controller uitvalt, dat segment een probleem heeft.


We kunnen natuurlijk ook kiezen voor 2 domains en verdelen over 4 domain controllers maar dat lijkt me een van de laatste oplossingen.

Hebben jullie nog adviezen welke we mee kunnen nemen in onze overweging ?

Bedankt alvast.

[richard_kraal]

uhm??? switchje aan je DMZ if?

[Rolfie]

Kan je niet iets doen met VLAN's en de optie "2 Domain controllers in een DMZ.". Volgens mij kan je gewoon een VLAN en die over een andere fysieke porten laten gaan.

richardkraal schreef op donderdag 02 februari 2006 @ 15:03:
uhm??? switchje aan je DMZ if?

Hoe bedoel je dit, een switchje?

[ Voor 5% gewijzigd door Rolfie op 02-02-2006 15:17 ]

[Verwijderd]

je gaat uit van 1 domain, maar je kan naar mijn idee ook uitgaan van 2. allebei de kanten 1 domain. Je webservers maken neem ik aan toch connectie's met de databases middels een database authenticatie, dus voordelen voor 1 domain heb je dan toch niet (je moet toch de user specificeren). het grote voordeel is dat je geen extra gaten hoeft te maken in firewall.

wil je toch naar 1 domain, dan zou ik een derde segment maken met een reverse proxy

[relaxteb]

je gaat uit van 1 domain, maar je kan naar mijn idee ook uitgaan van 2. allebei de kanten 1 domain. Je webservers maken neem ik aan toch connectie's met de databases middels een database authenticatie, dus voordelen voor 1 domain heb je dan toch niet (je moet toch de user specificeren). het grote voordeel is dat je geen extra gaten hoeft te maken in firewall.

Voordeel van 1 domain is dan dat we maar op 1 plek de accounts hebben (we hebben een wachtwoord policy en anders moet je weer op 2 domains je wachtwoord wijzigen), en anders moeten we 4 ipv 2 servers plaatsen.

De database authenticatie gebeurd met database users en niet met domain users.

[paulhekje]

zoals richardkraal al aangaf: je kunt een switch aansluiten op de DMZ-poort en dan daarop de 2 domain controllers aansluiten.
Domain controllers in je interne netwerk met wat open poorten of ze plaatsen in DMZ lijkt me weinig uitmaken. Je hoeft alleen domein gerelateerde poorten richting de dc's open te zetten, niet naar je db-servers.

Het veiligst is 2 aparte forests/domeinen met een trust. Als dit functioneel niet handig is, doe het dan simpel. DC's intern, minimaal aantal poorten open tussen DC's en webservers en gebruik ipsec voor deze connecties.

[ Voor 3% gewijzigd door paulhekje op 02-02-2006 20:54 ]

[_Arthur]

relaxteb schreef op donderdag 02 februari 2006 @ 15:01:

1 Domain controller per segment.
[afbeelding]
Nadeel hier is dat wanneer er 1 domain controller uitvalt, dat segment een probleem heeft.

We kunnen natuurlijk ook kiezen voor 2 domains en verdelen over 4 domain controllers maar dat lijkt me een van de laatste oplossingen.

Deze oplossing heeft de voorkeur. Geen rpc/etc/etc open door je firewall. VPN/ipsec door je firewall heen wil je niet, aangezien je firewall dan helemaal niet meer kan controleren wat er over die vpn/ipsec verbinding heen gaat.

Trusts tussen de domeinen wil je ook niet, aangezien 1 kant 'gehakt' is de andere kant ook de sigaar.

Wil je safe, alles splitsen. Dus 2 (of zelfs 4) dc's, en 1 domein in elke zone.

Zo is het ook opgezet bij een grote verzekerings toko. Alleen dan is er zelfs nog een 3e zone met idem inrichting.

[relaxteb]

bedankt voor het meedenken, ik ga nog eens met mijn collega's erover stoeien.

[Verwijderd]

_Arthur schreef op donderdag 02 februari 2006 @ 21:35:
[...]

Deze oplossing heeft de voorkeur. Geen rpc/etc/etc open door je firewall. VPN/ipsec door je firewall heen wil je niet, aangezien je firewall dan helemaal niet meer kan controleren wat er over die vpn/ipsec verbinding heen gaat.

een vpn heb je niet nodig om ipsec te gebruiken , je kan per soort traffic opgeven wat je over ipsec wilt laten lopen, maar je raakt idd wel je controle kwijt op de firewall (maar de controle is verplaatst naar de ipsec policy op de servers)

Trusts tussen de domeinen wil je ook niet, aangezien 1 kant 'gehakt' is de andere kant ook de sigaar.

ligt aan hoe je de trust opzet. Als je de webserver kant het domain laat trusten van de db kant, maar niet andersom dan kan je met 1 account wel alles beheren, maar niet met een gehacked account uit de web serverkant de db server bereiken. (buiten dat geeft een trust geen rechten, alleen de mogelijkheid om rechten te geven aan accounts uit een ander domain).

Wil je safe, alles splitsen. Dus 2 (of zelfs 4) dc's, en 1 domein in elke zone.

dat is zeker de beste oplossing, firewall staat dicht dus er is niks te proberen ook.