Porady na temat projektowania usługi Active Directory dla serwerów wieloadresowych

Klient zlecił mi wymyślenie działającego projektu usługi Active Directory dla scenariusza z następującymi wymaganiami (uproszczone, w rzeczywistości są znacznie gorsze):

• Istnieje podsieć dla systemów klienckich.
• Istnieje podsieć dla systemów serwerowych.
• Dwie sieci nie są połączone.
• Każdy serwer powinien mieć dwie karty sieciowe, jedną w sieci serwerów, a drugą w sieci klientów.
• Ruch między klientami a serwerami powinien przepływać tylko w sieci klientów.
• Ruch między serwerami powinien przepływać tylko w sieci serwerów.
• Powinno to dotyczyć także kontrolerów domeny.

Nie trzeba dodawać, że nie idzie to dobrze z tym, jak Active Directory używa DNS do lokalizowania kontrolerów domeny; każde możliwe podejście doprowadziłoby do jednego z następujących scenariuszy:

• DC rejestrują swój adres IP „po stronie klienta” w DNS domeny; klienci będą rozmawiać z nimi przy użyciu tego adresu, ale zrobią to serwery i ruch związany z replikacją AD.
• DC rejestrują swój adres IP po stronie serwera w domenie DNS; serwery będą rozmawiać z nimi za pomocą tego adresu, a ruch replikacyjny będzie płynął w tej sieci, ale klienci nie będą mogli do nich dotrzeć.
• DC zarejestrują oba adresy IP w domenie DNS; nikomu nie wiadomo, co zrobi każdy system, aby do nich dotrzeć.

Oczywiście te wymagania są całkowicie szalone i nie można spełnić wszystkich jednocześnie, chyba że przy użyciu szalonych rozwiązań, takich jak podział usługi DNS na dwie sieci i ręczne zapełnianie rekordów SRV (argh) lub zlokalizowanie serwerów DC za pomocą DNS, a klienci lokalizują DC za pomocą WINS (double-argh).

Rozwiązaniem, które wymyśliłem, jest posiadanie dwóch kontrolerów domeny w sieci „serwerów” i dwóch kontrolerów domeny w „klientach”, definiujących dwie witryny AD i przekraczających granicę między tymi dwiema sieciami tylko z ruchem replikacji kontrolerów domeny. Będzie to nadal wymagało trochę zakłóceń DNS, ponieważ każdy serwer będzie nadal miał dwie karty sieciowe (oprócz dwóch kontrolerów domeny po stronie serwera i serwerów czysto zaplecza), ale ma co najmniej pewne szanse na działanie.

Wszelkie porady inne niż ucieczka tak szybko, jak to możliwe?

Zacznę od stwierdzenia, że ​​zgadzam się z wieloma innymi - przekonaj klienta inaczej lub uciekaj.

Jednak biorąc pod uwagę podane przez ciebie wymagania (jest wiele niepublicznych), mogę wymyślić (i częściowo przetestować) przynajmniej podstawy do tego, aby tak się stało.

Należy wziąć pod uwagę kilka szczególnych aspektów.

1. Replikacja usług domenowych w usłudze Active Directory
2. Proces lokalizatora DC klientów / serwerów członkowskich
3. Rozpoznawanie nazw i ruch dla usług innych niż AD DS

Jeden i dwa mają ze sobą wiele wspólnego - generalnie jesteśmy pod tym względem kaprysem Microsoftu i musimy pracować w ramach procesów AD DS Microsoftu.

Po trzecie, mamy trochę miejsca do pracy. Możemy wybrać etykiety używane do uzyskiwania dostępu do usług (plików, instancji bazy danych itp.).

Oto, co proponuję:

Zbuduj kontrolery domeny (DC)

• Prawdopodobnie co najmniej dwa.
• Każdy DC będzie miał dwie karty sieciowe, po jednej w każdej sieci IP / witrynie AD DS - na razie nazywa je clt i srv.
• Skonfiguruj teraz tylko jedną kartę sieciową na każdym kontrolerze prądu stałego w sieci srv.

Prawidłowo skonfiguruj witryny i usługi AD

• strona srv i podsieć
• strona clt i podsieć
• odznacz „Połącz wszystkie linki do witryn” w Witrynach -> Transport między lokacjami -> Kliknij prawym przyciskiem myszy „IP”
• usuń DEFAULTIPSITELINK, jeśli istnieje (lub jeśli zmieniłeś jego nazwę), aby nie było skonfigurowanych linków do witryn. Zauważ, że jest to dla mnie nieznane - KCC prawdopodobnie zrzuci błędy do dziennika zdarzeń usługi katalogowej, mówiąc, że dwie witryny (srv i clt) nie są połączone w różnych odstępach czasu. Jednak replikacja będzie nadal kontynuowana między dwoma kontrolerami domeny, ponieważ mogą się oni kontaktować przy użyciu adresów IP w tej samej lokacji.

Skonfiguruj dodatkową strefę w zintegrowanym DNS usług AD DS

• Jeśli domeną usług AD DS jest acme.local , utwórz drugą podstawową strefę zintegrowaną AD z włączonymi aktualizacjami dynamicznymi o nazwie clt.acme.local .

Skonfiguruj drugie karty sieciowe na kontrolerze domeny

• Te karty sieciowe będą kartami sieci / witryny clt.
• Ustaw ich adresy IP
• Oto magiczna część - Właściwości adaptera -> Właściwości IPv4 -> Zaawansowane -> Karta DNS -> Ustaw sufiks DNS dla tego połączenia na clt.acme.local -> sprawdź Zarejestruj to połączenie ... -> Sprawdź Użyj tego połączenia Sufiks DNS ... -> OK przez całą drogę.
• ipconfig / registerdns
• Spowoduje to zarejestrowanie adresu IP karty clt NIC w strefie clt.acme.local - zapewniając nam metodę kontrolowania, który adres IP / sieć będzie używany później.

Skonfiguruj karty sieciowe serwera członkowskiego

• Karty sieciowe serwera członkowskiego w witrynie clt muszą mieć odpowiednio przyrostek DNS i pola wyboru, jak wyżej.
• Te ustawienia mogą być używane ze statycznymi i DHCP, nie ma znaczenia.

Skonfiguruj zachowanie resolvera DNS [stub] na stronach

• DC -> Skonfiguruj kartę sieciową DC srv NIC, aby korzystała z samego siebie i innych adresów IP karty sieciowej srv DC. Pozostaw DC Clt NIC DNS pusty (wymagany jest jednak statyczny adres IP). (Serwer DC DNS nadal domyślnie nasłuchuje na wszystkich adresach IP).
• Serwery członkowskie -> Skonfiguruj kartę członkowską srv serwera członkowskiego, aby korzystała z adresów IP witryny DC srv. Pozostaw serwer członkowski clt NIC DNS pusty (można użyć statycznego adresu IP).
• Klienci / stacje robocze -> Skonfiguruj DNS (przez DHCP lub statyczny), aby używać adresów IP karty sieciowej clt kontrolera domeny.

Skonfiguruj odpowiednio odwzorowania / zasoby

• Gdy serwery rozmawiają ze sobą, należy użyć .acme.local -> rozpoznaje adres IP sieci srv.
• Kiedy klienci rozmawiają z serwerami, pamiętaj, aby użyć pliku .clt.acme.local -> rozpoznaje adres IP sieci clt.

O czym mówię

• Replikacja usług AD DS nadal będzie występować, ponieważ kontrolery domeny mogą się wzajemnie rozwiązywać i łączyć ze sobą. Strefa acme.local i _msdcs.acme.local będzie zawierała tylko replikę AD DS NIC IP w sieci DC srv, tylko w sieci srv.
• Proces lokalizatora DC dla serwerów członkowskich i stacji roboczych będzie działał - chociaż istnieje możliwość opóźnień w różnych częściach różnych procesów AD DS, gdy witryna jest nieznana, jeśli zwróconych jest wiele adresów IP DC - zostaną one wypróbowane, zakończą się niepowodzeniem i przejdą dalej dopóki nie zadziała. Wpływ na DFS-N również nie został w pełni oceniony - ale nadal będzie działał.
• Usługi inne niż usługi AD DS będą działać poprawnie, jeśli użyjesz wyżej wymienionych etykiet .acme.local i .clt.acme.local zgodnie z opisem.

Nie przetestowałem tego całkowicie, ponieważ jest to raczej śmieszne. Jednak celem tej (wow, długiej) odpowiedzi jest rozpoczęcie oceny, czy jest to możliwe - a nie, czy należy to zrobić.

@Comments

@Massimo 1/2 Nie myl wielu witryn AD DS w strefie acme.local, a zatem rekordy SRV zapełniane przez kontrolery domeny w tych witrynach w strefie acme.local z potrzebnymi rekordami SRV w strefie clt.acme.local. Podstawowy sufiks DNS klienta (i domena Windows, do której są przyłączeni) nadal będzie acme.local. Klient / stacje robocze mają tylko jedną kartę sieciową, z sufiksem podstawowego DNS prawdopodobnie pochodzącym z DHCP, ustawionym na acme.local.

Strefa clt.acme.local nie potrzebuje rekordów SRV, ponieważ nie będzie używana w procesie lokalizatora DC. Jest używany tylko przez klientów / stacje robocze do łączenia się z usługami innych niż AD DS serwera członkowskiego przy użyciu adresów IP serwera członkowskiego w sieci clt. Procesy powiązane z usługami AD DS (lokalizator DC) nie będą używać strefy clt.acme.local, ale witryny i podsieci usług AD DS w strefie acme.local.

@Massimo 3

Będą rekordy SRV dla stron AD DS clt i srv - tylko, że będą istnieć w strefie acme.local - patrz uwaga powyżej. Strefa clt.acme.local nie potrzebuje rekordów SRV związanych z DC.

Klienci będą mogli znaleźć grzywnę DC. Klientowe serwery DNS wskazują adresy IP clt kontrolerów domeny.

Gdy proces lokalizatora DC na kliencie rozpoczyna się

• Jeśli klient zna swoją witrynę, pytaniem DNS będzie _ldap._tcp. [Site] ._ sites.dc._msdcs.acme.local SRV. Spowoduje to zwrócenie kontrolerów domeny specyficznych dla witryny, które mają zarejestrowane rekordy SRV.
• Jeśli klient nie zna swojej witryny, pytaniem DNS będzie _ldap._tcp.dc._msdcs.acme.local SRV. To zwróci wszystkie kontrolery domeny. Klient będzie próbował powiązać się z LDAP DC, dopóki nie znajdzie takiego, który odpowie. Gdy klient go znajdzie, przeprowadza wyszukiwanie witryny w celu ustalenia witryny klienta i buforuje witrynę w rejestrze, aby przyszłe instancje lokalizatora DC działały szybciej.

@Massimo 4

Ugh, niezły chwyt. Moim zdaniem istnieją dwa sposoby rozwiązania tego problemu.

1. Mniejszy wpływ (w porównaniu z 2 poniżej) polega na utworzeniu wpisu w pliku hosts na klientach / stacjach roboczych dla dc1.acme.local i dc2.acme.local wskazującego na adresy IP karty sieciowej kontrolera domeny.

lub

2. Ręcznie utwórz niezbędne rekordy SRV w pliku netlogon.dns na każdym kontrolerze domeny. To prawdopodobnie będzie miało pewne konsekwencje dla sieci serwerów. Serwery członkowskie mogą czasami komunikować się z kontrolerami domeny w sieci clt, jeśli jest to skonfigurowane.

Podsumowując, żadne z nich nie jest ładne, ale niekoniecznie jest to cel końcowy. Może klient właśnie testuje twoje technologiczne kotlety. Połóż to na stole konferencyjnym i powiedz im: „Tutaj to zadziała, ale naliczam opłatę 4x moją normalną stawkę, aby ją skonfigurować i obsługiwać. Możesz obniżyć ją do 1,5x mojej normalnej stawki - .5x opłaty PITA, wykonując [prawidłowe rozwiązanie]. ”

Jak wspomniano wcześniej, zalecam przekonać inaczej lub uciec. Ale z pewnością jest to zabawne, małe ćwiczenie w niedorzeczności. :)

W końcu wybrałem rozwiązanie dwóch witryn:

• Dwa DC dla sieci „serwerów”, dwa DC dla sieci „klientów”.
• Dwie witryny AD, jedna dla sieci „serwerów” i jedna dla „klientów”.
• Kontrolery domeny w sieci „serwerów” będą mieć tylko kartę sieciową na tym (klienci nie będą z nimi w ogóle rozmawiać), więc jest to łatwe.
• DC w strefie „klientów” będą mieć dwa, ale zarejestrują tylko w DNS swoje klienckie.
• Serwery będą rozmawiać ze swoimi DC, klienci będą rozmawiać z nimi.

Oczywiście oznacza to włączenie ruchu replikacji między dwiema sieciami; kontrolery domeny w sieci „klientów” nadal będą miały kartę sieciową siedzącą w sieci „serwerów”, ale ponieważ nie zostaną zarejestrowane w DNS, kontrolery domeny w tej sieci będą się z nimi kontaktować przy użyciu adresów IP po stronie klienta; więc karta sieciowa będzie w rzeczywistości całkowicie bezużyteczna i niektóre porty zapory będą musiały zostać otwarte. Jedyną inną opcją byłoby zniekształcanie hostsplików kontrolerów domeny , ale miejmy nadzieję, że da się tego uniknąć.

Myślę, że to najlepsze, co można zrobić, aby spełnić jak najwięcej (szalonych) wymagań.

Dziękuję za wszystkie porady :-)

Po pierwsze, kiedy świadczymy usługi dla naszych klientów, powinniśmy zapytać, jakie są ich wymagania. Umożliwienie klientowi zrozumienia, że ​​jego poziom złożoności jest niepotrzebny.

• Jaka była liczba klientów?
• To wszystko ruch wewnętrzny?
• Jaki jest poziom funkcjonalny domen?
• Czy używany jest protokół TLS?

Korzystając z metody KISS - tworzyłbym dwie sieci VLAN „SVR” i „CLT” włączające SSL / TLS i nazywające to Dniem ....