Rozwiązywanie krótkich nazw w Windows

Rozwiązywanie krótkich nazw w Windows

  • Comments 1
  • Likes

W ramach obowiązków PFE oprócz pracy proaktywnej (prowadzenie szkoleń i warsztatów) bardzo często wykonujemy zlecenia reaktywne. Umiejętność radzenia sobie z problemami jest jednym z kryteriów odróżniająch dobrych inżynierów. Na szczęście przy awariach Active Directory kwestia jest względnie prosta. Według przybliżonych statystyk 85% problemów związane jest ze źle skonfigurowanym lub najzwyczajniej w świecie zepsutym rozwiązywaniem nazw (celowo nie piszę DNS – dlaczego, będzie jasne pod koniec tego wpisu).

Replikacja: zależy od DNS (strefa _msdcs). Logowanie: zależy od DNS (DCLocator). Dostęp i uwierzytelnianie do usług: zelży od DNS (nazwa DNS = SPN dla Kerberosa)

Po pierwsze mimo, że DNS jest podstawowym mechanizmem tłumaczenia nazw na adresy IP, nie jest on jedynym. Są one następujące (sposoby rozwiązywania nazw wymienione zostały w kolejności korzystania; za http://msdn.microsoft.com/en-us/library/gg251092.aspx)

Gdy kiedy korzystamy z pełnych nazw kwalifikowanych (FQDN), Windows skorzysta tylko z DNS. W przypadku nazw jedno-etykietowych (pojedynczy wyraz nie zawierający kropki), wszystkie trzy są wykorzystywane pod warunkiem braku odpowiedzi w poprzednim kroku. Należy pamiętać, że odpowiedź negatywna też jest odpowiedzią.

Sprawy niestety się komplikują przez dwa małe ustawienia. “Primary DNS Suffix” oraz “DNS Suffix Search List”. Oba mają zastosowanie, gdy w sieci firmowej korzystamy z krótkich nazw, w celu uzyskania dostępu do usług. Na przykład wpisując w pasek adresu w ulubionej przeglądarce https://sharepoint klient DNS w Windows przekazuje do serwera DNS wiele zapytań. Gdy stacja z której podłączamy się do Sharepointa jest członkiem domeny Active Directory corp.contoso.pl, to w konfiguracji domyślnej właśnie ta nazwa będzie dla niej “Primary DNS Suffix”. Ten suffix jako jedyny może być upraszczany (DNS Suffix Devolution: http://technet.microsoft.com/en-us/library/ee683928%28v=ws.10%29.aspx), więc lista zapytań, która trafi do serwera DNS jest następująca:

  • sharepoint
  • sharepoint.corp.contoso.pl
  • sharepoint.contoso.pl

Ponadto DNS Suffix Search List może być skonfigurowany:

Przy powyższej konfiguracji klient DNS na stacji wyśle do serwera DNS następujące zapytania:

  • sharepoint
  • sharepoint.corp1.contoso.pl
  • sharepoint.corp2.contoso.pl

Kluczowe znaczenie ma to, że w tym przypadku suffixy nie są upraszczane. Dodatkowo mają one priorytet nad suffixem podstawowym.

Dopiero teraz kiedy rozwiązywanie DNS się nie uda, przechodzimy do LLMNR i NetBios (przy czym warto pamiętać, że plik LMHosts jest sprawdzany po odpytaniu serwera WINS i broadcast w posieci). Jest to oczywiście zachowanie domyślne dla Windows. Może ono zostać zmienione poprzez modyfikację typu węzła NetBIOS (Node Type; więcej szczegółów tutaj: http://technet.microsoft.com/en-us/library/cc738412%28v=ws.10%29.aspx)

PS. Przy diagnozowaniu problemów z rozwiązywaniem nazw niezastąpionym narzędziem jest sniffer ruchu sieciowego (Network Monitor lub jego odpowiednik):

image

Comments
  • <p>Fajny artykuł</p>

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment