Przez wiele lat byłem użytkownikiem Windowsów. Pamiętam takie czasy gdy Windows NT w wersji 4.0 był dla mnie podstawowym narzędziem pracy. Udało mi się nawet bezawaryjnie obsługiwać jedną z domen NT przez 10lat (taki osobisty rekord w kategorii najdłużej działających serwerów bez zwisów, serwer dostarczał DHCP, DNS, WWW i pocztę elektroniczą). Potem nastał czas Unixa, Linuxa i tak aż do tego roku. Historia lubi zataczać koło i zostałem zmuszony do przypomnienia sobie paru rzeczy, nauczenia się nowych oraz odświeżenia znajomości z domenami Active Directory.
Razem z kolegą zaprojektowaliśmy i wykonaliśmy mała domenę AD na zlecenie. Głównymi jej elementami były dwu węzłowy klaster MS SQL, dwu węzłowy klaster HyperV przeznaczony na wirtualną maszynę z MS Exchange. Żeby całość funkcjonowała prawidłowo potrzebny był oczywiście jeszcze kontroler domeny. I tutaj zaczeły się schody. W opisanym wcześniej przypadku pojedynczy kontroler stanowi najsłabszy element sieci. Praktycznie wszystkie usługi domenowe korzystają z baz utrzymywanych przez kontroler. Nie musi to być najbardziej wydajna maszyna, powinna być jednak dobrze zabezpieczona. Ponieważ w międzyczasie zleceniodawca zdecydował się na dodanie do domeny jeszcze jednego serwera, potrzebnego do implementacji CRM, wpadłem na pomysł, że nadarza się okazja zaimplementowania na nim dodatkowego kontrolera domeny. Nic bardziej błędnego! Główne powody, dla których nie należy tak robić to:
- Komputer, który jest kontrolerem domeny nie ma możliwości dodawania użytkowników lokalnie
- Jeśli oprogramowanie instalowane na kontrolerze domeny dodaje nowe konta to stają się one kontami domenowymi
- Nie możemy ograniczyć uprawnień dla np. operatora serwera (odpowiedzialnego za lokalną usuługę np. wspomniany CRM) na tyle aby nie był on w stanie zaszkodzić domenie
Wniosek jaki stąd płynie brzmi – jeśli myślisz o dodatkowych usługach w swojej domenie np. IIS, CRM itd. to instaluj je na serwerach będących wyłącznie członkami domeny (domain members). Pomio różnych opinii spotykanych w Internecie na ten temat skłaniam się ku kategorycznemu stwierdzeniu, że kontroler domeny powinien pozostać wyłącznie kontrolerem domeny. Jeśli sieć ma być w miarę bezpieczna rzecz jasna. A to z kolei prowadzi do wniosku, że projektując domene trzeba przyjąć, że co najmniej 2 serwery musimy przeznaczyć do tej roli. A więc płacz i płać:(
Nawiązując do tematu wpisu dałem złapać się w pułapkę i dlatego musiałem zdegradować (w dokumentacji technicznej Microsftu ta czynność nazywa się depromoting) całkiem zgrabny kontroler domeny. Poradnik jak to zrobić można znaleźć na stronie Microsoft TechNet w artykule „Removing a Domain Controller from a Domain„. Zanim jednak zaczniemy działać należy się upewnić, że:
- Nie usuwamy ostatniego kontrolera w domenie (praktycznie oznacza to, że w sieci musi być jeszcze co najmniej jeden serwer przechowywujący Katalog Globalny GC) co nieodwracalnie ją zniszczy
- Nie usuwamy podstawowego serwera DNS dla domeny Active Directory (jeśli tak to trzeba wcześniej przenieść tą rolę na inny serwer zawierający Katalog Globalny GC)
MG
Tagi:
Active Directory,
kontroler domeny,
Windows