Puncte:0

Cum pot forța DNS-ul integrat Active Directory să returneze numai înregistrări SRV pentru controlere de domeniu specifice bazate pe subrețeaua clientului?

drapel fr

Am un set de mai multe birouri conectate folosind diferite combinații de VPN-uri IPsec și o rețea MPLS. Majoritatea site-urilor formează un aranjament de plasă folosind VPN-urile, dar site-ul B are doar un singur VPN IPsec către site-ul A - site-ul B nu poate ajunge la niciunul dintre celelalte site-uri (site-urile C și D).

Site-urile A, C și D au toate un domeniu Active Directory, să spuneți „companya.com”. Controloarele de domeniu pentru companya.com sunt situate în toate cele trei site-uri și toate rulează Windows Server 2012 R2.

Site-ul B rulează propriul său domeniu Active Directory - spuneți „companyb.com”. Controloarele de domeniu pentru companyb.com sunt localizate exclusiv pe site-ul B. Unul rulează Windows Server 2019, celălalt rulează Windows Server 2012 R2.

Am stabilit o încredere bidirecțională între domeniile AD companya.com și companyb.com. Acest lucru a fost realizat folosind un forwarder condiționat în serverele AD DNS pentru companyb.com, indicând ambii controlori de domeniu de pe site-ul A pentru companya.com; în plus, am configurat o zonă stub în companya.com pentru a indica ambii controlori de domeniu de pe site-ul B pentru companyb.com.

După cum era de așteptat, ambii controlori de domeniu din site-ul A pot contacta în mod fiabil un controler de domeniu din site-ul B. Cu toate acestea, ambii controlori de domeniu din site-ul B pot contacta în mod fiabil doar controlorii de domeniu din site-ul A - deoarece am implementat un forwarder condiționat, uneori căutări DNS pentru înregistrările SRV descrierea controlorilor de domeniu în site-ul B returnează rezultate pentru site-urile C și D, pe care site-ul B nu le poate accesa deloc. Acest lucru provoacă erori sporadice, cum ar fi „Sistemul nu poate contacta un controler de domeniu pentru a răspunde cererii de autentificare. Vă rugăm să încercați din nou mai târziu.”

Trebuie să mă asigur că, atunci când controlorii de domeniu din companyb.com efectuează căutări pentru a găsi controlori de domeniu pe companya.com, sunt returnați numai controlorii de domeniu din site-ul A.

Am încercat:

  • Configurarea unui site AD pentru site-ul B, folosind subrețeaua la care sunt conectați controlorii de domeniu companyb.com. Cu toate acestea, nu cred că acest lucru funcționează, deoarece nu există nimic configurat în DNS care să specifice că site-ul B ar trebui să fie oferite rezultate numai pentru site-ul A.
  • Înlocuirea expeditorului condiționat pentru DC-urile din companyb.com cu o zonă stub. Aceeași problemă a persistat, cu excepția faptului că zona stub a provocat căutări împotriva serverelor DNS din site-urile C și D, care nu sunt accesibile.
  • Adăugarea manuală a unei zone primare integrate AD pentru companya.com pe serverele DNS ale companieib.com și adăugarea de înregistrări care indică toate controlerele de domeniu de pe site-ul A:
    • Înregistrări A multiple pentru companya.com.
    • Înregistrări multiple _gc._tcp.companya.com.
    • Înregistrări multiple _ldap._tcp.companya.com.
    • Înregistrări multiple _kerberos._tcp.companya.com.

Nu pot construi tuneluri IPsec între site-ul B și site-urile C și D și nici nu pot direcționa traficul către site-urile C și D prin tunelul existent de la site-ul B la site-ul A.

Bănuiesc că caracteristica politicilor DNS din Windows Server 2016 ar putea ajuta această situație, dar nu am acces la DC-uri care rulează Windows Server 2016. De asemenea, bănuiesc că s-ar putea să fi ratat unele înregistrări când am configurat manual o zonă DNS pe serverele companieib.com.

Orice perspectivă ar fi apreciată.

drapel cn
Acest lucru pare inutil și complicat. Procesul DC Locator este conceput pentru a selecta și testa DC-urile. Dacă eroarea este „sistemul nu poate contacta un controler de domeniu”, înseamnă că NU au existat DC-uri utilizabile în niciunul dintre rezultatele returnate. În plus, clientul ar trebui să încerce să folosească oricare dintre înregistrări, dacă nu are o înregistrare pe site-ul său local pentru domeniul țintă.
drapel fr
Ce ar putea face ca conexiunile să fie sporadice în acest caz? Am verificat VPN-ul și pot vedea traficul destinat controlorilor de domeniu în site-ul A de pe site-ul B, dar numai pentru unele solicitări; altele arată traficul de la site-ul B la site-urile C și D și un astfel de trafic nu reușește să direcționeze în absența oricăror tuneluri între subrețelele relevante.
drapel cn
Ar putea fi numeroase cauze. Trebuie să existe o captură de pachete corelată care rulează atunci când apare simptomul pentru a afla mai multe. Este posibil ca un DC să treacă testul ping LDAP, dar să nu funcționeze. Ar putea fi alocări incorecte de porturi de firewall pentru activitatea RPC.
drapel fr
După cum am sugerat, am căutat prin capturi de pachete și pot vedea încercări active de conectare la DC-uri inaccesibile. Nu este posibil ca acești DC să fi răspuns la un test ping LDAP așa cum ați descris, deoarece nu există un tunel VPN între site-ul B și site-urile C și D, așa că nu sunt sigur de ce traficul este direcționat în acest fel?
drapel cn
Depinde de ce este „conectarea” și de aplicație. Dacă este o funcționalitate nativă Windows, este de așteptat ca punctul final să se conecteze la oricare și la toate DC-urile și să le testeze. Dacă este o aplicație (disfuncțională) care se conectează la domeniul FQDN, se va conecta la prima înregistrare DC returnată, indiferent de stare. În plus, dacă un site DC nu este accesibil din alte locații, nu ar trebui să fie promovat ca DC disponibil la nivel global. Pentru asta sunt Mnemonicii DNS.
drapel fr
Văd tcp/445, categorizat Active Directory, de la site-ul B la site-urile C și D. Aplicația în cauză este Sage care se conectează la un Windows File Share pentru a-și localiza datele. Puteți detalia mnemonicii DNS? Înțelegeam despre configurația DNS că, dacă aș fi în domeniul companiei.com, aș putea defini un site AD, sitea.companya.com. Apoi, dacă clienții doresc să găsească DC-uri pe sitea, pot rezolva _ldap._tcp.sitea.companya.com. Cum funcționează acest lucru într-un trust, având în vedere că trusturile nu cunosc site-uri din alte domenii?
drapel cn
Dacă este o aplicație, nu văd înregistrările SRV care iau în considerare acest lucru. Dacă aveți înregistrări A pentru aceleași înregistrări ale părintelui și acele DC nu sunt accesibile, acest lucru ar fi de așteptat. Fie trebuie să curățați înregistrările A pentru domeniul cu probleme de pe site-ul unde apare problema, fie să modificați aplicația pentru a fi mai rezistentă și să nu folosiți înregistrări nefuncționale (putin probabil). Zonele stub sunt pentru funcționalitatea Windows nativă într-un domeniu normal, nu pentru utilizarea aplicației într-o pădure în care sunt publicate înregistrări DNS moarte pentru domeniu.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.