redundant Windows domain controller

[BjarneVB]

Hallo,

Ik ben relatief nieuw met netwerken/ server dus ik hoop dat mijn vraag niet te dom overkomt .

Ik zou graag een redundant netwerkje opbouwen met GNS3. Om te starten wou ik 2 domain controllers opzetten die volledig redundant werken.

Elke domain controller geef ik 2 netwerkkaarten:

WDC1 :
eth1 192.168.10.11
eth2 192.168.10.12

WDC2:
eth1 192.168.10.13
eth2 192.168.10.14

WDC1 is mijn "primaire" domain controller, en WDC2 mijn "backup".
Hiervoor heb ik de DNS ingesteld:

WDC1:
primaire dns: 192.168.10.11
secundaire dns: 192.168.10.13

WDC2:
primaire dns: 192.168.10.11
secundaire dns: 192.168.10.13

Nu is mijn vraag: Stel dat (misschien heel toevallig) de kabels 192.168.10.11 & 192.168.10.13 beschadigd geraken, zou ik graag terugvallen op de 2de netwerkkaarten van deze machines.
Maar aangezien ik slechts 2 ip adressen aan mijn dns kan toevoegen, vraag ik mij een beetje af hoe ik dit werkend krijg. suggesties?



Alvast bedankt!

[MAX3400]

Kan je niet beter je DC's inrichten met LACP en niet met meerdere IP's werken?

[HKLM_]

Op je DC kan je je nic’s ook teamen dan kan er 1 netwerkkabel / nic down gaan en heb je er geen last van.

https://docs.microsoft.co...s/nic-teaming/nic-teaming

[ Voor 32% gewijzigd door HKLM_ op 21-09-2020 19:27 ]

[Vorkie]

multihomed DC's zijn gewoon no way to go there aub. gedoe kan dat geven zeg.

Switch 1 en 2 maak je VRRP of stacked.

1 subnet, 1 nic.

DC 1 heeft DC2 en 127.0.0.1 als DNS.
DC2 heeft DC1 en 127.0.0.1 als DNS.
In die volgorde.

De DC's hebben forwarderds naar public DNS
de clients krijgen de DC's als DNS.

[ Voor 43% gewijzigd door Vorkie op 21-09-2020 20:20 . Reden: #25jaarindeIT #oud ]

[Hero of Time]

Vorkie schreef op maandag 21 september 2020 @ 19:26:
DC 1 heeft 127.0.0.1 en DC2 als DNS.
DC2 heeft 127.0.0.1 en DC1 als DNS.
In die volgorde.

Nee, dat is bad practice en tegen het advies van MS in. Je stelt juist de andere DC als primair in en localhost als tweede. Zie ook https://docs.microsoft.co...s.10)?redirectedfrom=MSDN. En de vele andere bronnen online die dit adviseren.

[Vorkie]

Hero of Time schreef op maandag 21 september 2020 @ 20:15:
[...]

Nee, dat is bad practice en tegen het advies van MS in. Je stelt juist de andere DC als primair in en localhost als tweede. Zie ook https://docs.microsoft.co...s.10)?redirectedfrom=MSDN. En de vele andere bronnen online die dit adviseren.

#25jaarindeIT #oud



heb aangepast, heb denk ik wel 10000000x dit gebouwd en type het nu gewoon verkeerd.... dank je

[ Voor 3% gewijzigd door Vorkie op 21-09-2020 20:22 ]

[Paul]

Welk probleem wil je hiermee oplossen? Want met 2 switches en 2 DC's (iedere DC op een andere switch) heb je al redundancy. Met het aansluiten van iedere DC op iedere switch ben je aan het voorbereiden van het opvangen van twee gelijktijdige failures.

Het kan (en ik zou het ook doen, als je hardware het ondersteunt; kost je enkel twee extra switchpoorten en twee kabels), maar zoals gezegd stack je dan de switches en maak je een port channel / nic team (als je fysieke DC's hebt. Als ze virtueel zijn team je de fysieke NICs van de host en geef je iedere DC één virtuele NIC).

[ Voor 10% gewijzigd door Paul op 21-09-2020 20:51 ]

[Trommelrem]

BjarneVB schreef op maandag 21 september 2020 @ 19:23:
Ik ben relatief nieuw met netwerken/ server dus ik hoop dat mijn vraag niet te dom overkomt .

Het meeste is hierboven al gezegd, maar hieraan kan worden toegevoegd:

Als je relatief nieuw bent met servers, ga dan zeker niet zelf een server met ADDS rol opzetten. Wil je redundancy, zet dan gewoon een Azure Active Directory Domain Services op als je software perse kerberos nodig heeft. Dan regelt Microsoft je redundancy en dan is je AzureAD leidend.

En dat is dan ook meteen een vraag die de meesten zouden hebben: Waarom zou je nog een ADDS rol willen opzetten?

[ Voor 9% gewijzigd door Trommelrem op 21-09-2020 20:56 ]

[Douweegbertje]

Ik zit in een totaal (non Windows) gebied maar ik vond het HA stukje interessant. Wat ik wilde meegeven, al kan dat dus vanwege mijn gebrek over het specifieke onderwerp n.v.t. zijn: DNS is niet voor failovers of fallback. Elke client gaat er anders mee om maar in principe is primair en secundair een alternatief op elkaar. Het kan dus prima zijn als je secundaire DNS plat ligt, er 25 of zelfs 100% van je clients niet kunnen connecten.

[MAX3400]

Douweegbertje schreef op maandag 21 september 2020 @ 20:59:
Ik zit in een totaal (non Windows) gebied
...
25 of zelfs 100% van je clients niet kunnen connecten.

En daarom "repliceert" elk DNS-record over alle DC's binnen hetzelfde domain en (bij veel bedrijven) binnen hetzelfde forest. Alleen als je round-robin gebruikt voor A-records (of soms CNAME), dan heb je bij "server uitval" een mogelijkheid dat clients niet alles meer kunnen.

Andersom: ik kan DNS dus wel inzetten voor "failover / fallback" en (grappig) juist voor langdurige uitval; als je namelijk 2 applicatie-servers hebt en die geef je via je DHCP-pool een static IP maar een self-registration in DNS, dan kan je met round-robin dus gewoon 1 server "laten uitfikken" en zodra het DNS-record dan gescavenged wordt door Windows, wijst 100% van de requests naar de levende/overlevende server.

Natuurlijk is dit een zeer fragiel en onhandig ontwerp echter het kan dus wel.

Trommelrem schreef op maandag 21 september 2020 @ 20:53:
[...]

En dat is dan ook meteen een vraag die de meesten zouden hebben: Waarom zou je nog een ADDS rol willen opzetten?

Interessant statement inderdaad. Echter, AzureAD is best afhankelijk van je internetlijn om je "on prem" infra netjes aan te sturen. Helemaal als je alleen kiest voor AzureAD gaan alle requests / autorisaties / KRB "via" je internetlijn.

Persoonlijk zou ik er voor kiezen om dan minstens een RODC on prem te houden just in case.

/edit: ik twijfel even of een RODC nog wel supported is als je AzureAD hebt. Kom ik op terug

[ Voor 25% gewijzigd door MAX3400 op 21-09-2020 21:16 ]

[Jazzy]

Douweegbertje schreef op maandag 21 september 2020 @ 20:59:
Elke client gaat er anders mee om maar in principe is primair en secundair een alternatief op elkaar. Het kan dus prima zijn als je secundaire DNS plat ligt, er 25 of zelfs 100% van je clients niet kunnen connecten.

Vrijwel alle moderne clients vallen terug op de secundaire DNS-server als de primaire geen respons geeft. Wat veel mensen vergeten is dat de client vervolgens deze secundaire DNS-server blijft gebruiken voor alle volgende queries, totdat deze een keer niet beschikbaar is en de client weer overschakelt naar de primaire (of een tertiaire indien geconfigureerd). Ik zou werkelijk geen voorbeeld van een DNS-client kunnen bedenken die deze logica niet volgt.

[MAX3400]

MAX3400 schreef op maandag 21 september 2020 @ 21:07:
[...]
Interessant statement inderdaad. Echter, AzureAD is best afhankelijk van je internetlijn om je "on prem" infra netjes aan te sturen. Helemaal als je alleen kiest voor AzureAD gaan alle requests / autorisaties / KRB "via" je internetlijn.

Persoonlijk zou ik er voor kiezen om dan minstens een RODC on prem te houden just in case.

/edit: ik twijfel even of een RODC nog wel supported is als je AzureAD hebt. Kom ik op terug

Toch even in een nieuwe reply (en ik ben ook bang volledig off-topic ondertussen) en ik zie post/zie eigenlijk wel een aantal uitdagingen waarom ik niet enkel & alleen AzureAD wil hebben maar, kom er maar in @Trommelrem (en zeker omdat ik nu op de term AD ga zitten): AzureAD doet geen device deployment.



Daarnaast, en dat is ook wel een grappig ding: AzureAD is niet geschikt voor third-party federation (over het algemeen); de enige plek waar dat (nog) wel kan is je on-prem DC die via allerlei claims / connects / tooling je SSO / MFA / blaat ontsluit naar ander spul. En helaas is er heel veel ander spul buiten de "AzureAD components"; zelfs met Azure Cloud Services, heb je nog een lange weg te gaan met sommige andere providers / SaaS-omgevingen.

Sec gezien, en het is best platgeslagen: AzureAD is identity & access management (UPN-focus dus eigenlijk); en ik durf wel te stellen dat 99% van de ADDS-omgevingen meer doet dan "alleen maar" identity & access (zoals je ook ziet in bovenstaand diagram en dan zeker het blauwe ruitje rechtsonder).

@BjarneVB sorry voor de uitgebreide info

[Brahiewahiewa]

Jazzy schreef op maandag 21 september 2020 @ 21:11:
[...]
Vrijwel alle moderne clients vallen terug op de secundaire DNS-server als de primaire geen respons geeft. Wat veel mensen vergeten is dat de client vervolgens deze secundaire DNS-server blijft gebruiken voor alle volgende queries, totdat deze een keer niet beschikbaar is en de client weer overschakelt naar de primaire (of een tertiaire indien geconfigureerd). Ik zou werkelijk geen voorbeeld van een DNS-client kunnen bedenken die deze logica niet volgt.

Dat was t/m windows 8 het geval. Windows 10 kent geen primaire en secundaire DNS servers meer.
DNS queries worden naar alle geconfigureerde DNS servers verzonden en de antwoorden worden gewogen, o.m. op basis van reactie tijd.
Documentatie vind je op microsoft.com en rants vind je op dns-leaks.com

[Trommelrem]

MAX3400 schreef op maandag 21 september 2020 @ 21:07:
Interessant statement inderdaad. Echter, AzureAD is best afhankelijk van je internetlijn om je "on prem" infra netjes aan te sturen. Helemaal als je alleen kiest voor AzureAD gaan alle requests / autorisaties / KRB "via" je internetlijn.

Persoonlijk zou ik er voor kiezen om dan minstens een RODC on prem te houden just in case.

/edit: ik twijfel even of een RODC nog wel supported is als je AzureAD hebt. Kom ik op terug

Nee, kan helaas niet. Je kunt niet op een supported manier een RODC toevoegen aan een Azure Active Directory Domain Services, omdat je geen Domain Admin bent van het domein.

Afhankelijk van het type applicatie is er wel/geen afhankelijkheid van een internetlijn, bijvoorbeeld door cached credentials.

Vandaar de vraag waarom TS zo graag de ADDS rol wilt opzetten. Welke legacy app vereist perse de aanwezigheid van een server met ADDS rol? En kan Azure Active Directory Domain Services dat wellicht vervangen?

Azure Active Domain Services =/ AzureAD.

[BjarneVB]

Hallo!

Allereerst bedankt voor de reacties! heb ik veel baat bij.

Ik zal even wat achtergrondinformatie meegeven aangezien de meesten hun afvragen waarom ik deze rol graag wil opzetten. Misschien ben ik iets te kort door de bocht gegaan door te zeggen dat ik relatief nieuw ben met servers, ik zit momenteel in mijn 3de jaar netwerkbeheer in avondonderwijs. Omdat dit het laatste jaar is, moet ik hiervoor een eindwerk maken met wat we de voorbije jaren geleerd hebben.

Ik zou graag een omgeving opzetten met enkele windows servers, linux servers en routers en switches. Hiervoor ben ik nog aan het overwegen of ik mikrotik of cisco zou gebruiken. Qua opdracht zou het al voldoende zijn om alles op te zetten zonder redundantie en enkel in vmware of virtualbox. Maar omdat het me daadwerkelijk interesseert zou ik het graag een stapje verder willen uitvoeren en heb daarom dus gekozen voor een omgeving in GNS3.

Ik heb al veel opgezocht op google en youtube, maar omdat ik met het toepassen van informatie dat ik op het internet vind geen garantie heb dat ik het ook effectief juist toegepast heb, heb ik me hier op het forum geregistreerd.

Gezien de comments op mijn post was dat ook een goede beslissing aangezien ik hier al veel bijgeleerd heb.
Waarvoor dank!!

[Jazzy]

Hier komen theorie en praktijk dus bij elkaar. Denk dat de feedback vanuit de praktijk is dat dit niet de manier is om je netwerk redundant te maken. In plaats daarvan team je de netwerkpoorten op de server en verbind je die met redundant switches.

Brahiewahiewa schreef op maandag 21 september 2020 @ 23:57:
Dat was t/m windows 8 het geval. Windows 10 kent geen primaire en secundaire DNS servers meer.
DNS queries worden naar alle geconfigureerde DNS servers verzonden en de antwoorden worden gewogen, o.m. op basis van reactie tijd.
Documentatie vind je op microsoft.com en rants vind je op dns-leaks.com

Interessant. Heb je een link voor me? Microsoft.com is vrij groot en ironisch genoeg kan ik dns-leaks.com niet resolven.

[Brahiewahiewa]

Jazzy schreef op dinsdag 22 september 2020 @ 13:02:
[...]
Interessant. Heb je een link voor me? Microsoft.com is vrij groot en ironisch genoeg kan ik dns-leaks.com niet resolven.

https://docs.microsoft.co...13-4dec-b14f-5abf85545385
of https://www.ietf.org/rfc/rfc4795.txt is makkelijker lezen

dnsleaks.com (sorry, zonder streepje) maakt zich zorgen omdat mensen die zich - vanwege het politieke klimaat in hun land - genoodzaakt voelen een VPN te gebruiken, voor nare verrassingen kunnen komen te staan

[Wim-Bart]

Multi homed is vragen om issues wanneer IP adressen zich in verschillende IP adresruimtes bevinden. Bijvoorbeeld beide Domein controllers hebben een adres in zowel 192.168.10.0/24 als 192.168.11.0/24. Met name wanneer deze zich dan ook in een zelfde Site bevinden.

De oplossing van TS is een leuke casus voor redundantie en kan in praktijk eigenlijk best werken. Wat het grappige is van het ontwerp van TS is dat hij eigenlijk (misschien onbedoeld en onbewust) ook nog eens zijn AD load balanced over 4 interfaces.

Echter zijn er ook andere methoden om de casus van TS vorm te geven. TS zou er namelijk ook voor kunnen kiezen om zonder moeilijke technieken en bijvoorbeeld op de fysieke hosts de gratis ESX neer te zetten en dan twee netwerk kaarten aansluiten op 2 switches. En deze twee netwerkkaarten aan een VSwitch te koppelen (in load balanced of fail-over). En de Virtuele Domein controller via een enkele adapter op deze VSwitch aan te sluiten.

Bijvoorbeeld: