Partager via

Rozwiązywanie krótkich nazw w Windows

  • Article

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)

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:

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):

image

Comments

  • Anonymous
    September 09, 2013
    Fajny artykuł