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ă.
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.)
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.
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ă.
Î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.