Nazywanie nowego lasu usługi Active Directory - dlaczego DNS nie jest podzielony na horyzont?

Mamy nadzieję , że wszyscy wiemy, jakie są zalecenia dotyczące nazewnictwa lasu usługi Active Directory i są one dość proste. Mianowicie można to streścić w jednym zdaniu.

Użyj subdomeny istniejącej, zarejestrowanej nazwy domeny i wybierz taką, która nie będzie używana zewnętrznie. Na przykład, jeśli mam włączyć i zarejestrować hopelessn00b.comdomenę, mój wewnętrzny las AD powinien mieć nazwę internal.hopelessn00b.comlub ad.hopelessn00b.comlub corp.hopelessn00b.com.

Istnieją w przeważającej mierze ważne powody, aby unikać używania „fałszywych” tlds lub nazw domen z pojedynczą etykietą , ale trudno mi znaleźć podobnie przekonujące powody, aby unikać używania domeny root ( hopelessn00b.com) jako mojej nazwy domeny i używania poddomeny takiej jak corp.hopelessn00b.comzamiast . Naprawdę, jedynym uzasadnieniem, które mogę znaleźć, jest to, że dostęp do zewnętrznej strony internetowej z wewnętrznej strony wymaga A namerekordu DNS i wpisywania www.przed nazwą strony w przeglądarce, co jest dość „meh”, jeśli chodzi o problemy.

Więc czego mi brakuje? Dlaczego o wiele lepiej jest używać ad.hopelessn00b.commojej nazwy lasu usługi Active Directory hopelessn00b.com?

Dla przypomnienia, to naprawdę mój pracodawca potrzebuje przekonania - szef sprzedaje się, a po udzieleniu mi szansy na utworzenie nowego lasu AD nazwanego corp.hopelessn00b'semployer.comdla naszej wewnętrznej sieci, chce pozostać przy lesie AD o nazwie hopelessn00b'semployer.com( to samo, co nasza zewnętrzna zarejestrowana domena). Mam nadzieję, że uda mi się znaleźć jakiś ważny powód lub powody, dla których najlepsza praktyka jest lepszą opcją, więc mogę go przekonać ... ponieważ wydaje się to łatwiejsze niż rzucenie gniewu i / lub znalezienie nowej pracy, przynajmniej dla chwila. Teraz „Microsoft najlepszych praktyk” i wewnętrznie dostępu do publicznie dostępnej stronie internetowej dla naszej firmy nie wydają się być cięcia, i jestem naprawdę , naprawdę , naprawdę nadzieję, że ktoś tu jest coś bardziej przekonujący.

Tyle rep. Chodź do mnie cenny.

Ok, więc Microsoft dość dobrze udokumentował, że nie powinieneś używać podzielonego horyzontu lub wymyślonej TLD, ponieważ łączysz się z nią wiele razy (krzycz na mojego bloga!). Jest kilka powodów.

1. wwwProblem, który już wskazano powyżej. Irytujące, ale nie łamiące porozumienia.

2. Zmusza cię do utrzymywania zduplikowanych rekordów dla wszystkich serwerów publicznych, które są również dostępne wewnętrznie, nie tylko www. mail.hopelessnoob.comjest częstym przykładem. W idealnym scenariuszu miałbyś osobną sieć obwodową dla takich rzeczy jak mail.hopelessnoob.comlub publicwebservice.hopelessnoob.com. W niektórych konfiguracjach, takich jak ASA z interfejsów wewnętrznych i zewnętrznych , należy albo wewnątrz-NAT wewnątrz lub split-horizon DNS w każdym razie , ale dla większych organizacji z legalnej sieci obwodowej gdzie internetowych stoi zasoby nie są za zakręt granicy NAT - powoduje to niepotrzebną pracę.

3. Wyobraź sobie ten scenariusz - jesteś hopelessnoob.comwewnętrznie i zewnętrznie. Masz korporację, z którą współpracujesz, do której dzwonisz example.comi robią to samo - dzielą horyzont wewnętrznie za pomocą swojej usługi AD i publicznie dostępnej przestrzeni nazw DNS. Teraz konfigurujesz VPN typu lokacja-lokacja i chcesz wewnętrznego uwierzytelnienia, aby zaufanie przechodziło przez tunel, a jednocześnie miało dostęp do zewnętrznych zasobów publicznych, aby wyjść przez Internet. Jest to prawie niemożliwe bez niewiarygodnie skomplikowanego routingu zasad lub posiadania własnej kopii wewnętrznej strefy DNS - teraz właśnie utworzyłeś dodatkowy zestaw rekordów DNS do utrzymania. Więc musisz poradzić sobie z spinaniem włosów na końcu iich koniec, routing zasad / NAT i wszelkiego rodzaju inne sztuczki. (Byłem w tej sytuacji z AD, które odziedziczyłem).

4. Jeśli kiedykolwiek wdrożysz DirectAccess , drastycznie uprości to zasady rozpoznawania nazw - prawdopodobnie dotyczy to również innych technologii VPN z dzielonym tunelem.

Niektóre z nich to przypadki skrajne, niektóre nie, ale wszystkich można łatwo uniknąć. Jeśli potrafisz to zrobić od samego początku, równie dobrze możesz to zrobić we właściwy sposób, abyś nie wpadł na żadne z nich przez dekadę.

To stwierdzenie: „Naprawdę, jedyne uzasadnienie, jakie wydaje mi się znaleźć, to to, że dostęp do zewnętrznej strony internetowej z wewnętrznego wymaga rekordu SRV DNS i wpisanie www. Przed nazwą strony w przeglądarce” nie jest prawdą.

Oznacza to, że musisz przechowywać kopię wszystkich swoich publicznych rekordów na serwerach AD DNS, co może powodować problemy, szczególnie jeśli nie zrobisz tego poprawnie - przegap niektórych itp. Jeśli ktoś chce dostać się do ftp.firma. com, ale zapomnisz utworzyć alias w wewnętrznym DNS (lub nie zautomatyzowałeś go prawidłowo), ludzie w domu nie mogą w ogóle trafić na publiczną stronę FTP.

Jest to dość dobrze rozwinięte w pytaniu, które łączysz: najlepsze praktyki nazewnictwa Windows Active Directory?

Jeśli utrzymywanie wielu kopii stref DNS jest łatwym problemem do prawidłowego rozwiązania, na zawsze, myślę, że możesz zrobić, co chcesz. Aż stwardnienie rozsiane zmieni coś, co je psuje. Państwo mogli tylko śledzić ich zaleceń.

Nie dbam wystarczająco o przedstawiciela, aby dziś udzielić długiej odpowiedzi ... więc krótko.

Kiedyś dobrze mi było z split-dns i implementowałem go wiele razy, dopóki Evan i Mark nie przekonali mnie inaczej. Szczerze mówiąc, NIE jest tak, że nie da się tego zrobić ... może, a niektórzy mogą sobie z tym poradzić (pomimo narzutu i włożonej pracy).

2 lata temu pojawiły się dla mnie 2 konkretne rzeczy, które NIE zestalały się przy użyciu:

1. Jak wskazałeś w swoim pytaniu, po prostu nie możesz pozwolić użytkownikom wewnętrznym na dostęp do Twojej zewnętrznej witryny za pośrednictwem samej nazwy domeny. Nie pytaj, dlaczego to była taka wielka sprawa, ale mieliśmy wewnętrznych użytkowników, którzy wściekliby się, wpisując tylko nazwę domeny w przeglądarce www, nie wywołując rzeczywistej witryny, ponieważ rekord domeny odpowiada domenie AD i nie jest najważniejszym celem wwwi NIE MOŻNA wewnętrznie.
2. Problemy z wymianą - Exchange AutoDiscover może nie uzyskać certyfikatów i wyświetli błąd. Może się to zdarzyć zarówno wewnętrznie, jak i zewnętrznie. Stało się to jeszcze bardziej widoczne, gdy zaczęliśmy mieć „Zewnętrzne leśne skrzynki pocztowe” w naszej organizacji Exchange i nie widzieli tego samego wewnętrznego DNS, co my.

Mam nadzieję, że to pomaga.