Najlepsze praktyki nazewnictwa Windows Active Directory?

To jest kanoniczne pytanie dotyczące nazewnictwa domen Active Directory.

Po eksperymentowaniu z domenami Windows i kontrolerami domen w środowisku wirtualnym zdałem sobie sprawę, że posiadanie domeny example.comActive Directory o takiej samej example.comnazwie jak domena DNS jest złym pomysłem (co oznacza, że ​​posiadanie nazwy Active Directory nie jest dobre, gdy mamy nazwę domeny zarejestrowany do użytku jako nasza strona internetowa).

To pokrewne pytanie wydaje się potwierdzać ten wniosek , ale nadal nie jestem pewien, jakie są inne reguły dotyczące nazw domen Active Directory.

Czy są jakieś najlepsze praktyki dotyczące tego, jaka nazwa usługi Active Directory powinna lub nie powinna być?

To był zabawny temat dyskusji na temat błędu serwera. Wydaje się, że na ten temat istnieją różne „poglądy religijne”.

Zgadzam się z zaleceniem Microsoftu : Użyj subdomeny już zarejestrowanej nazwy domeny internetowej firmy.

Tak więc, jeśli jesteś właścicielem foo.com, użyj ad.foo.comlub coś takiego.

Moim zdaniem najbardziej podła rzecz jest używanie zarejestrowanej nazwy domeny internetowej, dosłownie, dla nazwy domeny Active Directory. Powoduje to konieczność ręcznego kopiowania rekordów z Internetu DNS (np. www) Do strefy DNS usługi Active Directory, aby umożliwić rozpoznanie nazw „zewnętrznych”. Widziałem całkowicie głupie rzeczy, takie jak IIS instalowane na każdym kontrolerze domeny w organizacji prowadzącej witrynę sieci Web, która dokonuje przekierowania w taki sposób, że ktoś wchodzący foo.comdo przeglądarki zostałby przekierowany www.foo.comprzez te instalacje IIS. Zupełnie głupota!

Korzystanie z nazwy domeny internetowej nie daje żadnych korzyści, ale tworzy „działaj” za każdym razem, gdy zmieniasz adresy IP, których dotyczą nazwy hostów zewnętrznych. (Spróbuj użyć geograficznie równoważonego obciążenia DNS dla hostów zewnętrznych i zintegruj to z taką sytuacją „podzielonego DNS”! Gee - to by było fajne ...)

Korzystanie z takiej subdomeny nie ma wpływu na takie rzeczy jak dostarczanie wiadomości e-mail Exchange lub sufiksy głównej nazwy użytkownika (UPN), BTW. (Często widzę oba wymienione jako wymówki dla używania nazwy domeny internetowej jako nazwy domeny AD).

Widzę też wymówkę, że „robi to wiele dużych firm”. Duże firmy mogą podejmować decyzje oparte na kościach równie łatwo (jeśli nie więcej) niż małe firmy. Nie kupuję tego tylko dlatego, że duża firma podejmuje złą decyzję, która w jakiś sposób sprawia, że ​​jest to dobra decyzja.

Istnieją tylko dwie poprawne odpowiedzi na to pytanie.

1. Niewykorzystana subdomena domeny, której używasz publicznie. Na przykład, jeśli Twoja publiczna obecność w Internecie jest example.comTwoją wewnętrzną reklamą, może być nazwana jak ad.example.comlub internal.example.com.

2. Niewykorzystana domena drugiego poziomu, której jesteś właścicielem i której nie używasz nigdzie indziej. Na przykład, jeśli Twoja publiczna obecność w Internecie to example.comtwoja reklama może być nazwana example.net tak długo, jak się zarejestrujesz example.neti nie używaj jej nigdzie indziej!

To są twoje jedyne dwie możliwości. Jeśli robisz coś innego, narażasz się na wiele bólu i cierpienia.

Ale wszyscy używają .local!
Nie ma znaczenia Nie powinieneś Pisałem na blogu o użyciu .local i innych wymyślonych TLD, takich jak .lan i .corp . W żadnym wypadku nie powinieneś tego robić.

To nie jest bardziej bezpieczne. Nie są to „najlepsze praktyki”, jak twierdzą niektórzy ludzie. I nie ma żadnej przewagi nad dwoma opcjami, które zaproponowałem.

Ale chcę nazwać to tak samo, jak adres URL mojej publicznej witryny, aby moi użytkownicy byli example\userzamiast.ad\user
To jest ważna, ale myląca obawa. Podczas promowania pierwszego kontrolera domeny w domenie możesz ustawić nazwę NetBIOS domeny na dowolną. Jeśli zastosujesz się do moich rad i skonfigurujesz swoją domenę ad.example.com, możesz skonfigurować nazwę NetBIOS domeny exampletak, aby użytkownicy logowali się jako example\user.

W lasach i relacjach zaufania w usłudze Active Directory można również tworzyć dodatkowe sufiksy UPN. Nic nie stoi na przeszkodzie, aby utworzyć @ example.com jako główny sufiks UPN dla wszystkich kont w domenie. Po połączeniu tego z poprzednim zaleceniem NetBIOS żaden użytkownik końcowy nigdy nie zobaczy, że nazwa FQDN Twojej domeny to ad.example.com. Wszystko, co zobaczą, będzie example\lub @example.com. Jedynymi osobami, które będą musiały pracować z FQDN, są administratorzy systemów współpracujący z Active Directory.

Załóżmy również, że używasz przestrzeni nazw DNS z dzielonym horyzontem, co oznacza, że ​​nazwa AD jest taka sama jak publiczna witryna internetowa. Teraz użytkownicy nie mogą uzyskać example.comdostępu wewnętrznego, chyba że masz ich prefiks www.w przeglądarce lub nie uruchomisz usług IIS na wszystkich kontrolerach domeny (to źle). Musisz także wyleczyć dwanieidentyczne strefy DNS, które dzielą rozłączną przestrzeń nazw. To naprawdę więcej kłopotów niż jest warte. Teraz wyobraź sobie, że masz partnerstwo z inną firmą, a oni również mają konfigurację DNS z dzielonym horyzontem z ich AD i ich obecnością zewnętrzną. Masz między nimi prywatne łącze światłowodowe i musisz utworzyć zaufanie. Teraz cały Twój ruch do którejkolwiek z publicznych witryn musi przechodzić przez prywatny link zamiast po prostu wychodzić przez Internet. Powoduje to również wszelkiego rodzaju problemy głowy dla administratorów sieci po obu stronach. Unikaj tego. Zaufaj mi.

Ale ale, ale ...
Poważnie, nie ma powodu, aby nie używać jednej z dwóch rzeczy, które zasugerowałem. Każdy inny sposób ma pułapki. Nie mówię ci, abyś spieszył się ze zmianą nazwy domeny, jeśli działa i jest na swoim miejscu, ale jeśli tworzysz nową reklamę, zrób jedną z dwóch rzeczy, które zaleciłem powyżej.

Aby pomóc w odpowiedzi MDMarra:

NIGDY nie należy NIGDY używać nazwy DNS o pojedynczej etykiecie dla nazwy domeny. To było / jest dostępne przed Windows 2008 R2. Przyczyny / wyjaśnienia można znaleźć tutaj: Wdrażanie i działanie domen Active Directory, które są konfigurowane przy użyciu nazw DNS o pojedynczej etykiecie | Wsparcie Microsoft

Nie zapomnij NIE używać słów zastrzeżonych (tabela znajduje się w linku „Konwencje nazewnictwa” na dole tego postu), takich jak SYSTEM, WORLD lub RESTRICTED.

Zgadzam się również z Microsoftem, że powinieneś przestrzegać dwóch dodatkowych zasad (które nie są ugruntowane, ale nadal):

1. NIE powinieneś nazywać swojej domeny na podstawie czegoś, co zmieni się lub stanie się nieaktualne. Przykłady obejmują nazywanie domeny po linii produktu, systemie operacyjnym lub cokolwiek innego, co może się z czasem zmienić. Trzymaj się czegoś wystarczająco geograficznego lub konkretnego, aby miało to sens 5, a nawet 10 lat później.
2. Trzymaj się krótkich nazw o długości 15 znaków lub mniej, dzięki temu nazwa NETBIOS będzie łatwo taka sama jak nazwa domeny.

Na koniec zaleciłbym, abyś zastanowił się przez jak najdłuższy czas. Firmy przechodzą fuzje i przejęcia, nawet małe firmy. Pomyśl także o uzyskaniu pomocy / konsultacji z zewnątrz. Używaj nazw domen, struktury AD itp., Które będą łatwe do wyjaśnienia dla konsultantów lub ludzi tutaj na SF.

Linki wiedzy:

http://technet.microsoft.com/en-us/library/cc731265%28v=ws.10%29.aspx

http://support.microsoft.com/kb/909264

http://support.microsoft.com/kb/300684/en-us

Bieżąca strona rekomendacji Microsoft (W2k12) dla nazwy domeny lasu głównego

Nie zgadzam się na używanie:

• example.com - z powodów podanych już w innych odpowiedziach

Mogę zaakceptować za pomocą:

• ad.example.com - - z powodów już podanych w innych odpowiedziach

Ale nie zrobiłbym tego sam ani nie poleciłbym tego. Podczas przejęcia firmy rebranding całego piekła zostaje uwolniony, szczególnie gdy zarząd w tym momencie chce, aby wszystko się zmieniło. Zmiana nazw migracji, zmiany są bardzo trudne lub kosztowne.

Najlepszym sposobem, który poleciłbym, jest zakup domeny, która nie ma znaczenia dla nazwy firmy, a także nie dotyczy marki firmy. SIMPLE.CLOUD lub podobny powinien działać dobrze, o ile możesz go posiadać.

Widziałem duże firmy z 150 tys. Użytkowników korzystających z AD, które wciąż odwołują się do starej firmy, którą kupili lata temu, lub firm, które zmieniły nazwy i chociaż na dłuższą metę nie ma znaczenia, że ​​używasz \ login (jeśli nie możesz użyj UPN), nadal wygląda to źle przed zarządem, który nie rozumie, dlaczego zmiana tego nie jest trywialna.

Zawsze tak robię mydomain.local.

local nie jest prawidłową TLD, więc nigdy nie konkuruje z rzeczywistym publicznym wpisem DNS.

Na przykład lubię być w stanie wiedzieć, że web1.mydomain.localrozwiąże to wewnętrzny adres IP serwera WWW, podczas gdy web1.mydomain.comprzejdzie do zewnętrznego adresu IP.