Zoals Mark al schreef in het eerste blog van PFE zijn wij Field Engineers, een club van specialisten die ondersteuning leveren aan de grotere klanten. We doen Exchange, SQL, Active Directory, Sharepoint, Windows OS, Biztalk, etc.: alles waar onze klanten veel van hebben en wat ze belangrijk vinden. Ik ben een Active Directory specialist en wil hier af en toe wat schrijven over wat ik zoal bij klanten aan tref. Vandaag wil ik iets kwijt over firewalls in combinatie met Active Directory.
Op dit moment ondersteun ik een klant bij de upgrade van een tamelijk complexe Active Directory: 1 forest met 10 domeinen, waaronder een leeg forest root domein en 1 account domein. Dit geheel is verdeeld over een achttal sites, met als klap op de vuurpijl: een site met een DMZ-achtige status achter een firewall. Alle DC’s in het forest moet van Windows 2000 naar Windows 2003.
Er zijn altijd bedrijven geweest met een Active Directory in een gesegmenteerd netwerk. Op zich is daar niets mis mee, al is het niet simpel om het goed te configureren. Bij dit upgrade project bleek echter dat het pas echt ingewikkeld wordt als je veranderingen in het AD netwerk gaat doen, zoals een platform upgrade. Het bleek dat er situaties ontstonden waarbij het hele proces blokkeert. Bekijk het volgende versimpelde plaatje:
DC1 heeft verbinding met DC2, maar niet met DC3. Alle replicatie moet dus via DC2. Om diverse redenen wilden we DC2 als eerste vervangen door een 2003 machine door een driestaps proces: demote DC2, rename een 2003 member server naar DC2, en promote die machine naar DC. Voordat je verder leest, probeer eens te bedenken wat er dan mis gaat.
De demotie van DC2 gaat op zich prima. Hij selecteert een replicatiepartner, en gebruikt deze voor het demotie proces. Neem even aan dat hij DC3 heeft genomen. Het promotieproces van de 2003 memberserver gaat ook prima, als die DC3 neemt. Maar nu is er iets raars aan de hand met DC1. Die weigert namelijk te repliceren met DC2 omdat hij nooit de demotie heeft gezien van de oude server. Die had DC1 immers alleen van DC3 kunnen krijgen, en dat is verboden door de firewall. Het gekke is dat er op het eerste gezicht niets aan de hand lijkt. In Active Directory Sites en Services staat immers de correcte DC naam… Puzzel nu maar eens uit hoe je dit gaat oplossen.
Een andere variant was deze. De FSMO rollen stonden op DC2, maar werden ter voorbereiding van de upgrade verplaatst naar DC3 met het idee deze als laatste te doen. In dit scenario werd DC1 als eerste verwijderd en vervangen door een 2003 DC. Dat ging vrij lang goed, tot het moment dat DC1 opkwam als 2003 DC… en weigerde zich te adverteren. Een taak van een DC is het aanmaken van user accounts, en daarvoor zijn Security ID’s (SID’s) nodig. Om die uit te kunnen delen heeft de DC een reeks toegestane SID’s nodig, en die krijgt hij van de RID Master FSMO. En ja… die staat op DC3 waar DC1 niet bij mag!
Dankzij een goede testomgeving (inclusief firewall!) kwamen deze en nog vele andere complicaties op tijd boven. Het migratieplan voor productie is erg ingewikkeld geworden en omvat vele stappen. Kortom, Active Directory en firewalls gaan wel samen, maar levert veel extra complexiteit en beheerinspanning op – zeker op het moment dat je aanpassingen moet doen. Als je dan meeneemt dat alle DC’s in een forest vanuit beveiligingsperspectief equivalent zijn dan ontstaat de vraag wat de meerwaarde is van die firewalls. Daar moet dan wel een goede business case voor zijn. Ik beveel mijn klanten altijd aan om firewalls binnen een forest zoveel mogelijk te vermijden, en er voor te zorgen dat alle DC’s elkaar in principe kunnen “zien”. Simpeler is beter.