Puncte:3

De ce o opțiune MS GPO rupe partajările SMB care utilizează un fișier hosts pentru numele mașinii?

drapel gh

Am stabilit "Server de rețea Microsoft: nivel de validare a numelui țintă SPN al serverului" la "Necesar de la client" pe GPO-ul nostru de testare.

Sistemele noastre de testare au niște aliasuri personalizate ale mașinii în fișierele lor gazdă, dar odată ce opțiunea este activată, nu mai putem accesa partajările SMB folosind aliasul mașinii.

M-am chinuit să găsesc informații despre această interacțiune, așa că speram că cineva va putea explica interacțiunea aici și dacă există o modalitate de a o remedia?

Puncte:8
drapel fr

Nu este vorba despre fișierul „gazde” â ci sparge partajările prin care se accesează un nume de gazdă diferit de numele „real” al serverului. Rezultatul dvs. este normal, deoarece acesta este literalmente întregul scop al GPO.

GPO-ul în cauză seamănă mult cu aplicarea TLS SNI găsită pe unele servere web: clientul afirmă „Sunt aici să vorbesc cu serverul SRV01.EXAMPLE.COM” și dacă serverul nu recunoaște acel nume ca fiind unul dintre vhost-urile servește, respinge complet clientul. Deci, aici, dacă clientul afirmă că vrea să vorbească cu unul dintre aliasurile dumneavoastră /etc/hosts, dar serverul nu este conștient de alias, respinge clientul.

Kerberos are deja încorporat o aplicare similară (de aceea trebuie să înregistrați SPN-uri pentru aliasuri folosind setspn), dar GPO-ul îl face mai strict și extinde aceeași protecție și la NTLM.

(Așa cum sa menționat deja în pagina Documente, acest lucru ar trebui să prevină atacurile de retransmisie NTLM, în care un server rău intenționat A acceptă autentificarea NTLM, apoi trimite exact aceleași pachete NTLM către un server real B – atacul ar fi prevenit deoarece serverul B ar vezi „Vreau să vorbesc cu serverul A” de la client.)

Aceasta este este posibil să folosiți în continuare aliasuri de gazdă, dar necesită o cantitate din ce în ce mai mare de butoane de registry. Metoda oficială este de a folosi netdom computername REALHOST /add:THEALIAS ca în această postare TechNet, și am găsit postări pe blog care susțin că este suficient pentru a face aliasurile utilizabile chiar și cu o validare strictă a SPN, dar se pare că este nu destul de â există cel puțin una, dacă nu două, valori de registry pe care uită să le atingă.

  1. se înregistrează NETDOM Kerberos SPN-uri pentru alias în AD, permițând obținerea de bilete Kerberos pentru ele, similar cu emiterea manuală a acestor două comenzi:

    setspn -S HOST/THEALIAS REALHOST$
    setspn -S HOST/thealias.example.com REALHOST$
    

    Acest lucru este necesar pentru Kerberos și nu există nicio scuză pentru a nu utiliza Kerberos într-un mediu AD, așa că dacă alegeți să utilizați NETDOM sau să o faceți manual, ar trebui să înregistrați oricum alias-urile SPN.

    (Din punct de vedere tehnic, SMB utilizează principii „cifs/”, dar în AD sunt implicit prezenți ori de câte ori „gazdă/” SPN este înregistrat.)

  2. Apoi NETDOM adaugă alias-ul în două locuri în registrul serverului, determinând serverul să-și înregistreze numele suplimentare în AD DNS și să le anunțe prin intermediul browserului NetBIOS:

    • Cale: HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
      Nume: AlternateComputerNames
      Tip: REG_MULTI_SZ
      Date: {thealias.example.com}

    • Cale: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
      Nume: OpționalNume
      Tip: REG_MULTI_SZ
      Date: {THEALIAS}

    Ele nu par să aibă niciun efect asupra autentificării (nici măcar Kerberos), așa că cred că ambele sunt complet opționale dacă utilizați /etc/hosts sau creați înregistrări CNAME manuale în DNS.

  3. Un parametru suplimentar care NETDOM nu create, dar am găsit că este necesar pentru a accesa aliasurile din interiorul serverului însuși, este:

    • Cale: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
      Nume: BackConnectionHostNames
      Tip: REG_MULTI_SZ
      Date: {thealias.example.com}

    Acesta este necesar doar pentru conexiunile „loopback”, deci poate nu este strict necesar în general, dar cel puțin în cazul meu serverul făcut trebuie să se conecteze la propriul alias, astfel încât setarea a fost necesară.

  4. În cele din urmă, am descoperit că funcția „validare nume țintă SPN” are propria lista de nume permise care trebuie actualizate manual – altfel aliasurile ar fi respinse din cauza validării stricte a SPN, chiar dacă toate setările de mai sus sunt prezente:

    • Cale: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
      Nume: SrvAllowedServerNames
      Tip: REG_MULTI_SZ
      Date: {THEALIAS, thealias.example.com}

    Veți dori să enumerați ambele nume scurte și FQDN-urile fiecărui alias â din experimentele mele, listarea unuia nu îl implică automat pe celălalt.

Cu SPN-urile Kerberos înregistrate și SrvAllowedServerNames valoarea de registry setată, aliasurile ar trebui, în sfârșit, să funcționeze corect chiar și cu o validare strictă a țintei.

drapel gh
Super explicație și rezoluție, mulțumesc. Am bănuit părți din asta, dar nu aveam suficiente cunoștințe pentru a uni punctele.

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.