Rozwiązywanie krótkich nazw w Windows
W ramach obowiazków PFE oprócz pracy proaktywnej (prowadzenie szkolen i warsztatów) bardzo czesto wykonujemy zlecenia reaktywne. Umiejetnosc radzenia sobie z problemami jest jednym z kryteriów odrózniajach dobrych inzynierów. Na szczescie przy awariach Active Directory kwestia jest wzglednie prosta. Wedlug przyblizonych statystyk 85% problemów zwiazane jest ze zle skonfigurowanym lub najzwyczajniej w swiecie zepsutym rozwiazywaniem nazw (celowo nie pisze DNS – dlaczego, bedzie jasne pod koniec tego wpisu).
Replikacja: zalezy od DNS (strefa _msdcs). Logowanie: zalezy od DNS (DCLocator). Dostep i uwierzytelnianie do uslug: zelzy od DNS (nazwa DNS = SPN dla Kerberosa)
Po pierwsze mimo, ze DNS jest podstawowym mechanizmem tlumaczenia nazw na adresy IP, nie jest on jedynym. Sa one nastepujace (sposoby rozwiazywania nazw wymienione zostaly w kolejnosci korzystania; za https://msdn.microsoft.com/en-us/library/gg251092.aspx)
- DNS
- LLMNR – dostepny od Visty w góre Link Local Multicast Name Resolution https://blogs.technet.com/b/networking/archive/2008/04/01/how-to-benefit-from-link-local-multicast-name-resolution.aspx
- NetBios
Gdy kiedy korzystamy z pelnych nazw kwalifikowanych (FQDN), Windows skorzysta tylko z DNS. W przypadku nazw jedno-etykietowych (pojedynczy wyraz nie zawierajacy kropki), wszystkie trzy sa wykorzystywane pod warunkiem braku odpowiedzi w poprzednim kroku. Nalezy pamietac, ze odpowiedz negatywna tez jest odpowiedzia.
Sprawy niestety sie komplikuja przez dwa male ustawienia. “Primary DNS Suffix” oraz “DNS Suffix Search List”. Oba maja zastosowanie, gdy w sieci firmowej korzystamy z krótkich nazw, w celu uzyskania dostepu do uslug. Na przyklad wpisujac w pasek adresu w ulubionej przegladarce https://sharepoint klient DNS w Windows przekazuje do serwera DNS wiele zapytan. Gdy stacja z której podlaczamy sie do Sharepointa jest czlonkiem domeny Active Directory corp.contoso.pl, to w konfiguracji domyslnej wlasnie ta nazwa bedzie dla niej “Primary DNS Suffix”. Ten suffix jako jedyny moze byc upraszczany (DNS Suffix Devolution: https://technet.microsoft.com/en-us/library/ee683928%28v=ws.10%29.aspx), wiec lista zapytan, która trafi do serwera DNS jest nastepujaca:
- sharepoint
- sharepoint.corp.contoso.pl
- sharepoint.contoso.pl
Ponadto DNS Suffix Search List moze byc skonfigurowany:
- Globalnie za pomoca GPO (https://support.microsoft.com/kb/294785)
- Na poziome polaczenia sieciowego za pomoca DHCP
- Recznie:
Przy powyzszej konfiguracji klient DNS na stacji wysle do serwera DNS nastepujace zapytania:
- sharepoint
- sharepoint.corp1.contoso.pl
- sharepoint.corp2.contoso.pl
Kluczowe znaczenie ma to, ze w tym przypadku suffixy nie sa upraszczane. Dodatkowo maja one priorytet nad suffixem podstawowym.
Dopiero teraz kiedy rozwiazywanie DNS sie nie uda, przechodzimy do LLMNR i NetBios (przy czym warto pamietac, ze plik LMHosts jest sprawdzany po odpytaniu serwera WINS i broadcast w posieci). Jest to oczywiscie zachowanie domyslne dla Windows. Moze ono zostac zmienione poprzez modyfikacje typu wezla NetBIOS (Node Type; wiecej szczególów tutaj: https://technet.microsoft.com/en-us/library/cc738412%28v=ws.10%29.aspx)
PS. Przy diagnozowaniu problemów z rozwiazywaniem nazw niezastapionym narzedziem jest sniffer ruchu sieciowego (Network Monitor lub jego odpowiednik):
Comments
- Anonymous
September 09, 2013
Fajny artykuł