Crearea unui subdomeniu al domeniului nostru public pentru utilizare corporativă/internă Active Directory. Domeniul public este, de asemenea, domeniul nostru Office 365 și Azure

Domeniul nostru AD intern actual este un exemplu.local (înființat cu mult înainte de a mă alătura echipei noastre când aceasta era cea mai bună practică)

Domeniul nostru Office 365 este un domeniu public, înregistrat cu GoDaddy, pe care îl folosim pentru e-mail, sharepoint, echipe etc. și un chiriaș Azure, numiți-l exemplu.com. Știu că este cea mai bună practică în zilele noastre să configurați un subdomeniu al celui public și suntem bine cu corp.example.com ca subdomeniu care va fi folosit pentru AD/DNS-ul nostru intern.

Sunt destul de familiarizat cu DNS, deși nu sunt expert și nu am creat niciodată un subdomeniu public.

În pași scurti, vă rog cineva să descrie cum să procedați în acest sens? Am citit atâta documentație cât există și cea mai mare parte este de acord în concept cu chestia subdomeniului, dar este în conflict cu privire la modul de a proceda de fapt pentru a face acest lucru. Nu avem foarte mulți utilizatori corporativi, cei mai mulți dintre ei sunt pe site-uri la distanță și nu trebuie să acceseze AD-ul nostru corporativ. AD-ul nostru este destul de simplu, nu există o mulțime de politici de grup sau ceva care s-ar putea pierde la crearea unui domeniu nou.

Plănuiesc să distrug domeniul nostru actual example.local (nu voi încerca să-l redenumesc) și să configurez un nou server /DC pentru subdomeniu și AD. Am capacitatea de a gestiona DNS-ul nostru pe GoDaddy, trebuie doar să știu pașii corespunzători și cum să-i traduc înapoi în AD.

Poate cineva să mă ghideze oferindu-mi o scurtă prezentare a pașilor care trebuie urmați și în ce ordine să le fac? Sunt puțin confuz cu privire la cum să spun AD și DNS intern că este un subdomeniu al unuia înregistrat public.

Nu cred că dns-ul creierului divizat va fi necesar, deoarece avem un domeniu total diferit care nu este implicat în nimic din toate acestea pentru site-ul nostru public. În acest moment, așa cum stau lucrurile, fqdn-ul serverelor noastre interne este server.example.local. Așteptările mele când termin cu asta este ca fqdn-ul serverelor noastre interne să fie server.corp.example.com. (Așa cum am menționat mai sus, example.com este domeniul public principal pe care îl folosesc pentru a crea subdomeniul în subordine.)

Vă mulțumesc anticipat pentru orice ajutor pe care îl puteți oferi. Serverul AD/DNS intern pentru noul subdomeniu rulează standardul Windows 2019.

Sharyn

Acest document MSFT subliniază configurația de bază în scenariul subdomeniului pe care îl descrieți: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772970(v=ws.10)

Nu trebuie să „spuneți” DC ca atare că sunt subordonați zonei din amonte. Pur și simplu instalați rolul AD și DNS, specificați domeniul FQDN și va configura subzona ca fiind autorizată pentru DC-uri în timpul configurării.

Configurarea vă va da un avertisment dacă aveți clientul DNS configurat pe adaptorul de rețea al DC cu o adresă de gazdă DNS externă, deoarece va încerca să înregistreze noul său nume DNS. Dar ignoră asta, DNS-ul în amonte nu trebuie să știe despre asta.

Pentru resursele găzduite intern care trebuie accesate de pe Internet, ai aloca un IP public și un nume DNS public resursei tale interne - cum ar fi un site web sau VPN - și ai ajunge la el în acest fel, mai degrabă decât să expui/delegați spațiul de nume privat deloc - asta cu siguranță trebuie evitat dacă este posibil. Acesta este scenariul descris în documentul MSFT. Referitor la punctul 4, nu va trebui să vă faceți griji cu privire la dezactivarea înregistrărilor dinamice pe furnizorul dvs. de DNS, deoarece mă îndoiesc că oricum este activat.

Decizia principală ar fi modul în care rezolvați numele extern pentru membrii domeniului dvs. Membrii ar trebui să folosească DC-urile ca gazde DNS, desigur. DC-urile vor trebui să rezolve numele pe internet. În mod ideal, DC-urile ar trimite interogări către un anumit furnizor DNS - acest lucru ușurează viața atunci când vine vorba de firewall. Punctul 5 din articolul pe care l-am legat discută opțiunile.

Cred că în scenariul tău, ai folosi DNS-ul ISP-ului tău - oricum ai face-o acum. Merită să vă uitați la furnizorii de servicii DNS precum OpenDNS sau Cloudflare care oferă securitate DNS dacă furnizorul dvs. actual nu o face - protecție suplimentară împotriva site-urilor de phishing și așa mai departe este grozavă, iar aceste servicii pot fi gratuite sau destul de ieftine. Doar asigurați-vă că cel pe care îl selectați are puncte locale de prezență (cel puțin naționale) dacă mergeți pe acel traseu. Soluția este de a lăsa DC-urile să folosească indicii de rădăcină, dar asta înseamnă că trebuie să facă interogări pe tot Internetul și cu siguranță aș prefera OpenDNS etc decât această opțiune. Ar trebui să definiți mai mulți expeditori, cu excepția cazului în care știți că IP-ul expeditorului este de fapt un VIP cu mai multe gazde dedesubt.

MSFT doco are, de asemenea, o serie de alte capitole care ar putea merita să le aruncați o privire. Cu toate acestea, lucruri precum un server rădăcină DNS intern sunt irelevante, cu excepția cazului în care veți expune spațiul de nume intern și îl veți delega de la registratorul DNS din amonte. Din nou, acesta este un scenariu pe care doriți să îl evitați.

De asemenea, odată instalat primul DC, în configurația rețelei, nu uitați să verificați că propriul IP este gazda DNS principală, plus 127.0.0.1. Dacă redirecționerul DNS este configurat pentru a transmite interogări către DNS-ul dvs. extern, nu cred că aveți nevoie de el definit și în configurația rețelei (test pentru a verifica că DC poate rezolva numele externe, desigur).

Pentru DC-urile ulterioare, înainte de a instala ADDS, configurați rețeaua astfel încât primul DC să fie DNS-ul său principal, apoi el însuși, apoi 127.0.0.1. Odată ce Configurarea este finalizată pe al doilea DC și replicarea sa încheiat, asigurați-vă că primul DC îl poate rezolva și setați configurația rețelei astfel încât al doilea DC să fie prima gazdă DNS (reținând celelalte intrări).

Personal nu am idee de ce ar putea fi benefic să ai un domeniu intern numit corp.company.com în loc, de exemplu, companie.lan. Sau orice altceva cu adevărat. Dacă cunoașteți beneficii, vă rugăm să le împărtășiți.

Dacă utilizați un subdomeniu public pentru AD, nu trebuie să adăugați nimic la configurația zonei DNS publice. Este important nu să publice orice înregistrări interne în mod public.

Singura idee proastă ar fi să folosiți numele dvs. de domeniu public company.com ca nume de domeniu AD intern. În afară de asta, vei fi bine