Problemy z klientami, usługami i programami mogą wystąpić, jeśli zmienisz ustawienia zabezpieczeń i przydziały praw użytkownika

Windows XP

Aby zwiększyć świadomość niepoprawnie skonfigurowanych ustawień zabezpieczeń, zmień ustawienia zabezpieczeń za pomocą narzędzia edytora obiektów zasady grupy. W przypadku korzystania z edytora obiektów zasady grupy przydziały praw użytkowników są rozszerzone w następujących systemach operacyjnych:

• Windows XP Professional z dodatkiem Service Pack 2 (SP2)

• Windows Server 2003 z dodatkiem Service Pack 1 (SP1)

Rozszerzona funkcja to okno dialogowe zawierające link do tego artykułu. To okno dialogowe jest wyświetlane po zmianie ustawienia zabezpieczeń lub przypisania praw użytkownika na ustawienie, które zapewnia mniejszą zgodność i jest bardziej restrykcyjne. Jeśli bezpośrednio zmienisz to samo ustawienie zabezpieczeń lub przypisanie praw użytkownika przy użyciu rejestru lub za pomocą szablonów zabezpieczeń, efekt będzie taki sam jak zmiana tego ustawienia w edytorze obiektów zasady grupy. Okno dialogowe zawierające link do tego artykułu nie jest jednak wyświetlane.

Ten artykuł zawiera przykłady klientów, programów i operacji, na które mają wpływ określone ustawienia zabezpieczeń lub przypisywanie praw użytkownika. Jednak przykłady nie są autorytatywne dla wszystkich systemów operacyjnych firmy Microsoft, dla wszystkich systemów operacyjnych innych firm lub dla wszystkich wersji programów, których dotyczy problem. Nie wszystkie ustawienia zabezpieczeń i przypisania praw użytkownika są zawarte w tym artykule.

Zalecamy sprawdzenie zgodności wszystkich zmian konfiguracji związanych z zabezpieczeniami w lesie testowym przed wprowadzeniem ich w środowisku produkcyjnym. Las testowy musi odzwierciedlać las produkcyjny w następujący sposób:

• Wersje systemów operacyjnych dla klientów i serwerów, programy klienckie i serwerowe, wersje dodatków Service Pack, poprawki, zmiany schematu, grupy zabezpieczeń, członkostwa w grupach, uprawnienia do obiektów w systemie plików, foldery udostępnione, rejestr, usługa katalogowa Active Directory, ustawienia lokalne i zasady grupy oraz typ i lokalizacja liczby obiektów

• Wykonywane zadania administracyjne, używane narzędzia administracyjne i systemy operacyjne służące do wykonywania zadań administracyjnych

• Wykonywane operacje, takie jak:

  • Uwierzytelnianie przy użyciu komputera i logowania użytkownika

  • Resetowanie hasła przez użytkowników, komputery i administratorów

  • Przeglądania

  • Ustawianie uprawnień dla systemu plików, folderów udostępnionych, rejestru i zasobów usługi Active Directory przy użyciu Edytora ACL we wszystkich klienckich systemach operacyjnych we wszystkich domenach kont lub zasobów ze wszystkich klienckich systemów operacyjnych ze wszystkich domen kont lub zasobów

  • Drukowanie z kont administracyjnych i nieadministracyjnych

Windows Server 2003 SP1

Prawa użytkownika

Na poniższej liście opisano prawo użytkownika, określono ustawienia konfiguracji, które mogą powodować problemy, opisano, dlaczego należy zastosować prawo użytkownika i dlaczego warto usunąć prawo użytkownika, oraz przedstawiono przykłady problemów ze zgodnością, które mogą wystąpić po skonfigurowaniu prawa użytkownika.

1. Uzyskiwanie dostępu do tego komputera z sieci

   1. Tle
      
      Możliwość interakcji ze zdalnymi komputerami z systemem Windows wymaga dostępu do tego komputera od prawej strony użytkownika sieci. Oto przykłady takich operacji sieciowych:

      • Replikacja usługi Active Directory między kontrolerami domeny we wspólnej domenie lub lesie

      • Żądania uwierzytelniania do kontrolerów domeny od użytkowników i komputerów

      • Dostęp do folderów udostępnionych, drukarek i innych usług systemowych znajdujących się na komputerach zdalnych w sieci

      
      
      Użytkownicy, komputery i konta usług uzyskują lub tracą dostęp do tego komputera od użytkownika sieciowego, będąc jawnie lub niejawnie dodani lub usunięci z grupy zabezpieczeń, która otrzymała to prawo użytkownika. Na przykład konto użytkownika lub konto komputera może zostać jawnie dodane przez administratora do niestandardowej grupy zabezpieczeń lub wbudowanej grupy zabezpieczeń albo niejawnie dodane przez system operacyjny do grupy zabezpieczeń obliczanej, takiej jak Użytkownicy domeny, Uwierzytelnieni użytkownicy lub Kontrolery domeny przedsiębiorstwa.
      
      Domyślnie konta użytkowników i konta komputerów uzyskują dostęp do tego komputera z prawej strony użytkownika sieciowego po obliczeniu grup, takich jak Wszyscy lub, najlepiej, uwierzytelnieni użytkownicy, a w przypadku kontrolerów domeny grupa Kontrolery domeny przedsiębiorstwa są definiowane w domyślnych kontrolerach domeny zasady grupy Object (GPO).

   2. Ryzykowne konfiguracje
      
      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Usuwanie grupy zabezpieczeń Kontrolery domeny przedsiębiorstwa z tego użytkownika

      • Usuwanie grupy Uwierzytelnieni użytkownicy lub grupy jawnej, która umożliwia użytkownikom, komputerom i kontom usług prawo użytkownika do łączenia się z komputerami przez sieć

      • Usunięcie wszystkich użytkowników i komputerów z tego użytkownika

   3. Powody, dla których warto przyznać temu użytkownikowi prawo

      • Przyznanie dostępu do tego komputera od użytkownika sieci do grupy Kontrolery domeny przedsiębiorstwa spełnia wymagania uwierzytelniania, które replikacja usługi Active Directory musi mieć na potrzeby replikacji między kontrolerami domeny w tym samym lesie.

      • To prawo użytkownika umożliwia użytkownikom i komputerom dostęp do udostępnionych plików, drukarek i usług systemowych, w tym usługi Active Directory.

      • To prawo użytkownika jest wymagane, aby użytkownicy mieli dostęp do poczty przy użyciu wczesnych wersji programu Microsoft Outlook Web Access (OWA).

   4. Powody, dla których należy usunąć prawo tego użytkownika

      • Użytkownicy, którzy mogą połączyć swoje komputery z siecią, mogą uzyskiwać dostęp do zasobów na komputerach zdalnych, do których mają uprawnienia. Na przykład to prawo użytkownika jest wymagane, aby użytkownik łączył się z udostępnionymi drukarkami i folderami. Jeśli to prawo użytkownika zostanie przyznane grupie Wszyscy i jeśli niektóre foldery udostępnione mają skonfigurowane zarówno uprawnienia do udostępniania, jak i systemu plików NTFS, tak aby ta sama grupa miała dostęp do odczytu, każdy może wyświetlać pliki w tych folderach udostępnionych. Jest to jednak mało prawdopodobna sytuacja w przypadku nowych instalacji systemu Windows Server 2003, ponieważ domyślny udział i uprawnienia NTFS w systemie Windows Server 2003 nie obejmują grupy Wszyscy. W przypadku systemów uaktualnianych z systemu Microsoft Windows NT 4.0 lub Windows 2000 ta luka może być bardziej ryzykowna, ponieważ domyślne uprawnienia udostępniania i systemu plików dla tych systemów operacyjnych nie są tak restrykcyjne, jak uprawnienia domyślne w systemie Windows Server 2003.

      • Nie ma ważnego powodu, aby usunąć grupę Kontrolery domeny przedsiębiorstwa z tego prawa użytkownika.

      • Grupa Wszyscy jest zwykle usuwana na rzecz grupy Uwierzytelnieni użytkownicy. Jeśli grupa Wszyscy zostanie usunięta, grupa Uwierzytelnieni użytkownicy musi otrzymać to prawo użytkownika.

      • Domeny systemu Windows NT 4.0 uaktualnione do systemu Windows 2000 nie udzielają jawnie dostępu do tego komputera od użytkownika sieci bezpośrednio do grupy Wszyscy, grupy Uwierzytelnieni użytkownicy ani do grupy Kontrolery domeny przedsiębiorstwa. Dlatego po usunięciu grupy Wszyscy z zasad domeny systemu Windows NT 4.0 replikacja usługi Active Directory zakończy się niepowodzeniem z komunikatem o błędzie "Odmowa dostępu" po uaktualnieniu do systemu Windows 2000. Winnt32.exe w systemie Windows Server 2003 pozwala uniknąć tej błędnej konfiguracji, przyznając grupie kontrolerów domeny przedsiębiorstwa prawo podczas uaktualniania podstawowych kontrolerów domeny systemu Windows NT 4.0 (PDCs). Nadaj temu użytkownikowi prawo do grupy Kontrolery domeny przedsiębiorstwa, jeśli nie jest on obecny w edytorze obiektów zasady grupy.

   5. Przykłady problemów ze zgodnością

      • Windows 2000 i Windows Server 2003: Replikacja następujących partycji zakończy się niepowodzeniem z błędami "Odmowa dostępu" zgłoszonymi przez narzędzia monitorowania, takie jak REPLMON i REPADMIN lub zdarzenia replikacji w dzienniku zdarzeń.

        • Partycja schematu usługi Active Directory

        • Partycja konfiguracji

        • Partycja domeny

        • Partycja wykazu globalnego

        • Partycja aplikacji

      • Wszystkie sieciowe systemy operacyjne firmy Microsoft: Uwierzytelnianie konta użytkownika z zdalnych komputerów klienckich sieciowych nie powiedzie się, chyba że użytkownik lub grupa zabezpieczeń, do których jest użytkownikiem, otrzymała to prawo użytkownika.

      • Wszystkie systemy operacyjne sieci firmy Microsoft: Uwierzytelnianie konta z klientów sieci zdalnej nie powiedzie się, chyba że konto lub grupa zabezpieczeń, do których należy konto, otrzymało to prawo użytkownika. Ten scenariusz dotyczy kont użytkowników, kont komputerów i kont usług.

      • Wszystkie sieciowe systemy operacyjne firmy Microsoft: Usunięcie wszystkich kont z tego prawa użytkownika uniemożliwi każdemu kontu zalogowanie się do domeny lub uzyskanie dostępu do zasobów sieciowych. Jeśli grupy obliczeniowe, takie jak Kontrolery domeny przedsiębiorstwa, Wszyscy lub Uwierzytelnieni użytkownicy, zostaną usunięte, musisz jawnie przyznać temu użytkownikowi prawo do kont lub grup zabezpieczeń, do których należy konto, do uzyskiwania dostępu do komputerów zdalnych przez sieć. Ten scenariusz dotyczy wszystkich kont użytkowników, wszystkich kont komputerów i wszystkich kont usług.

      • Wszystkie systemy operacyjne sieci firmy Microsoft: Konto administratora lokalnego używa "pustego" hasła. Łączność sieciową z pustymi hasłami nie jest dozwolona dla kont administratorów w środowisku domeny. W tej konfiguracji może zostać wyświetlony komunikat o błędzie "Odmowa dostępu".

2. Zezwalaj na logowanie lokalne

   1. Tle
      
      Użytkownicy próbujący zalogować się na konsoli komputera z systemem Windows (za pomocą skrótu klawiaturowego CTRL+ALT+DELETE) i konta próbujące uruchomić usługę muszą mieć lokalne uprawnienia logowania na komputerze hostingowym. Przykładowe operacje logowania lokalnego obejmują administratorów, którzy logują się na konsolach komputerów członków, lub kontrolerów domeny w całym przedsiębiorstwie i użytkowników domeny, którzy logują się na komputerach członków w celu uzyskania dostępu do swoich pulpitów przy użyciu kont nieuprzywilejanych. Użytkownicy korzystający z połączenia pulpitu zdalnego lub usług terminalowych muszą mieć dostęp do logowania lokalnego bezpośrednio na komputerach docelowych z systemem Windows 2000 lub Windows XP, ponieważ te tryby logowania są traktowane jako lokalne dla komputera hostingowego. Użytkownicy logujący się na serwerze z włączonym serwerem terminali, którzy nie mają prawa dostępu do tego użytkownika, nadal mogą rozpocząć zdalną sesję interakcyjną w domenach systemu Windows Server 2003, jeśli użytkownik ma prawo zezwalać na logowanie za pośrednictwem usług terminalowych.

   2. Ryzykowne konfiguracje
      
      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Usuwanie administracyjnych grup zabezpieczeń, w tym operatorów kont, operatorów kopii zapasowych, operatorów wydruku lub operatorów serwera oraz wbudowanej grupy Administratorzy z domyślnych zasad kontrolera domeny.

      • Usuwanie kont usług używanych przez składniki i programy na komputerach członków i kontrolerach domeny w domenie z domyślnych zasad kontrolera domeny.

      • Usuwanie użytkowników lub grup zabezpieczeń logujących się na konsoli komputerów członkowskich w domenie.

      • Usuwanie kont usług zdefiniowanych w lokalnej bazie danych Menedżera kont zabezpieczeń (SAM) komputerów członkowskich lub komputerów grupy roboczej.

      • Usuwanie nie wbudowanych kont administracyjnych uwierzytelniających się za pośrednictwem usług terminalowych uruchomionych na kontrolerze domeny.

      • Dodawanie wszystkich kont użytkowników w domenie jawnie lub niejawnie za pośrednictwem grupy Wszyscy do prawego logowania lokalnego Odmów logowanie lokalne. Ta konfiguracja uniemożliwi użytkownikom logowanie się na dowolnym komputerze członkowskim lub na kontrolerze domeny w domenie.

   3. Powody, dla których warto przyznać temu użytkownikowi prawo

      • Użytkownicy muszą mieć prawo Zezwalaj na logowanie użytkownikowi lokalnemu do uzyskiwania dostępu do konsoli lub pulpitu komputera grupy roboczej, komputera członka lub kontrolera domeny.

      • Użytkownicy muszą mieć to prawo do logowania się za pośrednictwem sesji usług terminalowych uruchomionej na komputerze członkowskim lub kontrolerze domeny opartym na systemie Windows 2000.

   4. Powody, dla których należy usunąć prawo tego użytkownika

      • Brak ograniczenia dostępu konsoli do uzasadnionych kont użytkowników może spowodować, że nieautoryzowani użytkownicy pobierzą i wykonują złośliwy kod w celu zmiany swoich praw użytkownika.

      • Usunięcie prawu zezwalania na dziennik lokalny zapobiega nieautoryzowanym logowaniu na konsolach komputerów, takich jak kontrolery domeny lub serwery aplikacji.

      • Usunięcie tego prawa logowania uniemożliwia zalogowanie się kont innych niż domena na konsoli komputerów członkowskich w domenie.

   5. Przykłady problemów ze zgodnością

      • Serwery terminali systemu Windows 2000: Aby użytkownicy mogli logować się na serwerach terminali systemu Windows 2000, jest wymagane zezwalanie na logowanie się do lokalnych praw użytkowników.

      • Windows NT 4.0, Windows 2000, Windows XP lub Windows Server 2003: Konta użytkowników muszą mieć prawo do logowania się na konsoli komputerów z systemem Windows NT 4.0, Windows 2000, Windows XP lub Windows Server 2003.

      • Windows NT 4.0 i nowsze: na komputerach z systemem Windows NT 4.0 lub nowszym, jeśli dodasz logowanie zezwalaj lokalnie na użytkownika lokalnego, ale niejawnie lub jawnie udzielisz także prawa do logowania lokalnego Odmów, konta nie będą mogły zalogować się do konsoli kontrolerów domeny.

3. Pomijanie sprawdzania przechodzenia

   1. Tle
      
      Pomijanie sprawdzania prawego użytkownika umożliwia użytkownikowi przeglądanie folderów w systemie plików NTFS lub w rejestrze bez sprawdzania uprawnień specjalnych dostępu do folderu przechodzenia. Pomijanie opcji sprawdzania prawego użytkownika nie zezwala użytkownikowi na wyświetlenie zawartości folderu. Umożliwia użytkownikowi przechodzenie tylko do jego folderów.

   2. Ryzykowne konfiguracje
      
      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Usuwanie kont nieadekrancyjnych, które logują się na komputerach z usługami terminalowymi opartymi na systemie Windows 2000 lub na komputerach z systemem Windows Server 2003, które nie mają uprawnień dostępu do plików i folderów w systemie plików.

      • Usunięcie grupy Wszyscy z listy podmiotów zabezpieczeń, którzy domyślnie korzystają z tego użytkownika. Systemy operacyjne Windows, a także wiele programów, zaprojektowano zgodnie z oczekiwaniami, że każdy, kto może legalnie uzyskać dostęp do komputera, będzie miał prawo do sprawdzania przechodzenia przez obejście. W związku z tym usunięcie grupy Wszyscy z listy podmiotów zabezpieczeń mających domyślnie tego użytkownika może prowadzić do niestabilności systemu operacyjnego lub do niepowodzenia programu. Lepiej pozostawić to ustawienie domyślne.

   3. Powody, dla których warto przyznać temu użytkownikowi prawo
      
      Ustawieniem domyślnym dla prawej opcji sprawdzania przechodzenia przez obejście jest zezwolenie każdej osobie na pomijanie sprawdzania przechodzenia. W przypadku doświadczonych administratorów systemu Windows jest to oczekiwane zachowanie i odpowiednio konfigurują one listy kontroli dostępu do systemu plików (SACLs). Jedynym scenariuszem, w którym konfiguracja domyślna może doprowadzić do wpadki, jest sytuacja, w której administrator, który konfiguruje uprawnienia, nie rozumie tego zachowania i oczekuje, że użytkownicy, którzy nie będą mogli uzyskać dostępu do folderu nadrzędnego, nie będą mogli uzyskać dostępu do zawartości żadnych folderów podrzędnych.

   4. Powody, dla których należy usunąć prawo
      
      tego użytkownika Aby uniemożliwić dostęp do plików lub folderów w systemie plików, organizacje, które są bardzo zaniepokojone zabezpieczeniami, mogą skusić się na usunięcie grupy Wszyscy, a nawet grupy Użytkownicy, z listy grup, w których sprawdzanie przebiegu obejścia jest prawidłowe.

   5. Przykłady problemów ze zgodnością

      • Windows 2000, Windows Server 2003: Jeśli przejście przez obejście sprawdzania prawego użytkownika zostanie usunięte lub zostanie niepoprawnie skonfigurowane na komputerach z systemem Windows 2000 lub Windows Server 2003, ustawienia zasady grupy w folderze SYVOL nie będą replikowane między kontrolerami domeny w domenie.

      • Windows 2000, Windows XP Professional, Windows Server 2003: Komputery z systemem Windows 2000, Windows XP Professional lub Windows Server 2003 rejestrują zdarzenia 1000 i 1202 i nie będą mogły stosować zasad komputera i zasad użytkownika, gdy wymagane uprawnienia systemu plików zostaną usunięte z drzewa SYSVOL w przypadku usunięcia lub niepoprawnego skonfigurowania obejścia pola wyboru użytkownika.
        
         

      • Windows 2000, Windows Server 2003: Na komputerach z systemem Windows 2000 lub Windows Server 2003 karta Przydział w Eksploratorze Windows zniknie po wyświetleniu właściwości woluminu.

      • Windows 2000: Osoby, które nie są administratorami, które logują się na serwerze terminali systemu Windows 2000, mogą otrzymać następujący komunikat o błędzie:

        Userinit.exe błąd aplikacji. Nie można poprawnie zainicjować aplikacji 0xc0000142 kliknij przycisk OK, aby zakończyć działanie aplikacji.

      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Użytkownicy z komputerami z systemem Windows NT 4.0, Windows 2000, Windows XP lub Windows Server 2003 mogą nie mieć dostępu do folderów udostępnionych lub plików w folderach udostępnionych i mogą otrzymywać komunikaty o błędach "Odmowa dostępu", jeśli nie otrzymają prawa do sprawdzania przebiegu obejścia.
        
        
         

      • Windows NT 4.0: Na komputerach z systemem Windows NT 4.0 usunięcie funkcji sprawdzania przebiegu obejścia po prawej stronie użytkownika spowoduje, że kopia pliku będzie upuszczać strumienie plików. Jeśli usuniesz prawo tego użytkownika, gdy plik zostanie skopiowany z klienta systemu Windows lub z klienta macintosh do kontrolera domeny systemu Windows NT 4.0 z uruchomionym programem Services dla komputerów Macintosh, docelowy strumień plików zostanie utracony, a plik będzie wyświetlany jako plik tekstowy.

      • Microsoft Windows 95, Microsoft Windows 98: Na komputerze klienckim z systemem Windows 95 lub Windows 98 polecenie net use * /home zakończy się niepowodzeniem z komunikatem o błędzie "Odmowa dostępu", jeśli grupa Uwierzytelnieni użytkownicy nie otrzyma prawa użytkownika do sprawdzania przebiegu obejścia.

      • Outlook Web Access: Osoby, które nie są administratorami, nie będą mogły zalogować się do programu Microsoft Outlook Web Access i otrzymają komunikat o błędzie "Odmowa dostępu", jeśli nie zostanie im przyznana funkcja sprawdzania przechodzenia przez pomijanie.

Ustawienia zabezpieczeń

Poniższa lista określa ustawienie zabezpieczeń, a lista zagnieżdżona zawiera opis ustawienia zabezpieczeń, identyfikuje ustawienia konfiguracji, które mogą powodować problemy, opisuje przyczynę zastosowania ustawienia zabezpieczeń, a następnie opisuje przyczyny usunięcia ustawienia zabezpieczeń. Następnie lista zagnieżdżona zawiera symboliczną nazwę ustawienia zabezpieczeń i ścieżkę rejestru ustawienia zabezpieczeń. Ponadto przedstawiono przykłady problemów ze zgodnością, które mogą wystąpić po skonfigurowaniu ustawienia zabezpieczeń.

1. Inspekcja: zamknij system natychmiast, jeśli nie możesz zarejestrować inspekcji zabezpieczeń

   1. Tło

      • Inspekcja: Zamknij system natychmiast, jeśli nie można zarejestrować inspekcji zabezpieczeń, określa, czy system zostanie zamknięty, jeśli nie można zarejestrować zdarzeń zabezpieczeń. To ustawienie jest wymagane w przypadku oceny C2 programu Trusted Computer Security Evaluation Criteria (TCSEC) oraz dla typowych kryteriów oceny zabezpieczeń technologii informatycznych, aby zapobiec zdarzeniom objętym inspekcją, jeśli system inspekcji nie może zarejestrować tych zdarzeń. Jeśli system inspekcji zakończy się niepowodzeniem, system zostanie zamknięty i zostanie wyświetlony komunikat o błędzie Zatrzymania.

      • Jeśli komputer nie może rejestrować zdarzeń w dzienniku zabezpieczeń, krytyczne dowody lub ważne informacje dotyczące rozwiązywania problemów mogą nie być dostępne do sprawdzenia po zdarzeniu zabezpieczeń.

   2. Ryzykowna konfiguracja
      
      Oto szkodliwe ustawienie konfiguracji: Inspekcja: Zamknij system natychmiast, jeśli ustawienie Nie można zarejestrować inspekcji zabezpieczeń jest włączone, a rozmiar dziennika zdarzeń zabezpieczeń jest ograniczony przez opcję Nie zastąp zdarzeń (wyczyść dziennik ręcznie), opcję Zastąp zdarzenia stosownie do potrzeb lub opcję Zastąp zdarzenia starsze niż liczba dni w Podgląd zdarzeń. Zobacz sekcję "Przykłady problemów ze zgodnością", aby uzyskać informacje o konkretnych zagrożeniach dla komputerów z oryginalną wydaną wersją systemu Windows 2000, Windows 2000 z dodatkiem Service Pack 1 (SP1), Windows 2000 SP2 lub Windows 2000 z dodatkiem SP3.

   3. Powody włączenia tego ustawienia
      
      Jeśli komputer nie może rejestrować zdarzeń w dzienniku zabezpieczeń, krytyczne dowody lub ważne informacje dotyczące rozwiązywania problemów mogą nie być dostępne do sprawdzenia po zdarzeniu zabezpieczeń.

   4. Powody wyłączenia tego ustawienia

      • Włączanie inspekcji: Zamknij system natychmiast, jeśli nie można zarejestrować ustawienia inspekcji zabezpieczeń zatrzymuje system, jeśli z jakiejkolwiek przyczyny nie można zarejestrować inspekcji zabezpieczeń. Zazwyczaj zdarzenia nie można rejestrować, gdy dziennik inspekcji zabezpieczeń jest pełny i gdy określoną metodą przechowywania jest opcja Nie zastąp zdarzeń (ręczne czyszczenie dziennika) lub Zastąp zdarzenia starsze niż liczba dni.

      • Obciążenie administracyjne związane z włączeniem inspekcji: Zamknij system natychmiast, jeśli nie można zarejestrować inspekcji zabezpieczeń, ustawienie może być bardzo wysokie, szczególnie w przypadku włączenia opcji Nie zastępowaj zdarzeń (ręczne czyszczenie dziennika) dla dziennika zabezpieczeń. To ustawienie zapewnia indywidualną odpowiedzialność działań operatora. Administrator może na przykład zresetować uprawnienia wszystkich użytkowników, komputerów i grup w jednostce organizacyjnej ( OU), gdzie inspekcja została włączona przy użyciu wbudowanego konta administratora lub innego konta udostępnionego, a następnie odmówić zresetowania tych uprawnień. Jednak włączenie ustawienia zmniejsza niezawodność systemu, ponieważ serwer może być zmuszony do zamknięcia przez przytłaczające go zdarzeń logowania i innych zdarzeń zabezpieczeń, które są zapisywane w dzienniku zabezpieczeń. Ponadto zamknięcie systemu operacyjnego, programów lub danych nie jest wdzięku, nieodwracalnym uszkodzeniem. Chociaż system plików NTFS gwarantuje, że integralność systemu plików zostanie zachowana podczas niezaładowanego zamknięcia systemu, nie może zagwarantować, że każdy plik danych dla każdego programu będzie nadal w użytecznej formie po ponownym uruchomieniu systemu.

   5. Nazwa symboliczna:
      
      Crashonauditfail

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

   7. Przykłady problemów ze zgodnością

      • Windows 2000: Z powodu błędu komputery z oryginalną wydaną wersją systemu Windows 2000, Windows 2000 z dodatkiem SP1, Windows 2000 z dodatkiem SP2 lub Windows Server z dodatkiem SP3 mogą przestać rejestrować zdarzenia przed osiągnięciem rozmiaru określonego w opcji Maksymalny rozmiar dziennika dla dziennika zdarzeń zabezpieczeń. Ten błąd został rozwiązany w dodatku Service Pack 4 (SP4) dla systemu Windows 2000. Zanim rozważysz włączenie tego ustawienia, upewnij się, że kontrolery domeny systemu Windows 2000 mają zainstalowany dodatek Service Pack 4 dla systemu Windows 2000.
        
         

      • Windows 2000, Windows Server 2003: Komputery z systemem Windows 2000 lub Windows Server 2003 mogą przestać odpowiadać, a następnie mogą spontanicznie ponownie uruchomić się, jeśli ustawienie Inspekcja: Zamknij system natychmiast, jeśli nie można zarejestrować inspekcji zabezpieczeń, dziennik zabezpieczeń jest pełny i nie można zastąpić istniejącego wpisu dziennika zdarzeń. Po ponownym uruchomieniu komputera zostanie wyświetlony następujący komunikat o błędzie zatrzymania:

        STOP: C0000244 {Audit Failed}
        Próba wygenerowania inspekcji zabezpieczeń nie powiodła się.

        Aby odzyskać zabezpieczenia, administrator musi się zalogować, zarchiwizować dziennik zabezpieczeń (opcjonalnie), wyczyścić dziennik zabezpieczeń, a następnie zresetować tę opcję (opcjonalnie i w razie potrzeby).

      • Klient sieci firmy Microsoft dla systemów MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Osoby, które nie są administratorami, które próbują zalogować się do domeny, otrzymają następujący komunikat o błędzie:

        Konto jest skonfigurowane tak, aby uniemożliwić korzystanie z tego komputera. Spróbuj użyć innego komputera.

      • Windows 2000: Na komputerach z systemem Windows 2000 osoby, które nie są administratorami, nie będą mogły logować się do serwerów dostępu zdalnego i otrzymają komunikat o błędzie podobny do następującego:

        Nieznany użytkownik lub złe hasło

      • Windows 2000: Na kontrolerach domeny systemu Windows 2000 usługa Wiadomości międzywitytowe (Ismserv.exe) zostanie zatrzymana i nie będzie można jej ponownie uruchomić. Funkcja DCDIAG zgłosi błąd jako "serwer ISMserv usług testowania nie powiodło się", a identyfikator zdarzenia 1083 zostanie zarejestrowany w dzienniku zdarzeń.

      • Windows 2000: Na kontrolerach domeny systemu Windows 2000 replikacja usługi Active Directory nie powiedzie się, a jeśli dziennik zdarzeń zabezpieczeń jest pełny, zostanie wyświetlony komunikat "Odmowa dostępu".

      • Microsoft Exchange 2000: Serwery z programem Exchange 2000 nie będą mogły zainstalować bazy danych magazynu informacji, a zdarzenie 2102 zostanie zarejestrowane w dzienniku zdarzeń.

      • Outlook, Outlook Web Access: Osoby, które nie są administratorami, nie będą mogły uzyskiwać dostępu do poczty za pośrednictwem programu Microsoft Outlook ani za pośrednictwem programu Microsoft Outlook Web Access. Zostanie wyświetlony błąd 503.

2. Kontroler domeny: wymagania dotyczące podpisywania serwera LDAP

   1. Tle
      
      Ustawienie zabezpieczeń Kontroler domeny: Wymagania dotyczące podpisywania serwera LDAP określa, czy serwer protokołu LDAP (Lightweight Directory Access Protocol) wymaga klientów LDAP do negocjowania podpisywania danych. Możliwe wartości dla tego ustawienia zasad są następujące:

      • Brak: podpisywanie danych nie jest wymagane do powiązania z serwerem. Jeśli klient żąda podpisania danych, serwer obsługuje tę funkcję.

      • Wymaganie podpisania: Opcja podpisywania danych LDAP musi być negocjowana, chyba że jest używana opcja Transport Layer Security/Secure Socket Layer (TLS/SSL).

      • nie zdefiniowano: to ustawienie nie jest włączone ani wyłączone.

   2. Ryzykowne konfiguracje
      
      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Włączanie opcji Wymagaj logowania w środowiskach, w których klienci nie obsługują podpisywania LDAP lub gdy po stronie klienta podpisywanie LDAP nie jest włączone w kliencie

      • Stosowanie szablonu zabezpieczeń Hisecdc.inf systemu Windows 2000 lub Windows Server 2003 w środowiskach, w których klienci nie obsługują podpisywania LDAP lub gdy po stronie klienta podpisywanie LDAP nie jest włączone

      • Stosowanie szablonu zabezpieczeń Hisecws.inf systemu Windows 2000 lub Windows Server 2003 w środowiskach, w których klienci nie obsługują podpisywania LDAP lub gdy podpisywanie LDAP po stronie klienta nie jest włączone

   3. Powody włączenia tego ustawienia
      
      Niepodpisany ruch sieciowy jest podatny na ataki typu "man-in-the-middle", w których intruz przechwytuje pakiety między klientem a serwerem, modyfikuje pakiety, a następnie przesyła je dalej na serwer. Gdy to zachowanie występuje na serwerze LDAP, osoba atakująca może spowodować, że serwer będzie podejmował decyzje oparte na fałszywych zapytaniach z klienta LDAP. Możesz zmniejszyć to ryzyko w sieci firmowej, wdrażając silne fizyczne środki bezpieczeństwa w celu ochrony infrastruktury sieciowej. Tryb nagłówka uwierzytelniania PROTOKOŁU INTERNETOWEGO (IPSec) może pomóc w zapobieganiu atakom typu "man-in-the-middle". Tryb nagłówka uwierzytelniania wykonuje wzajemne uwierzytelnianie i integralność pakietów dla ruchu IP.

   4. Powody wyłączenia tego ustawienia

      • Klienci, którzy nie obsługują podpisywania LDAP, nie będą mogli przeprowadzać zapytań LDAP na kontrolerach domeny i w wykazach globalnych, jeśli uwierzytelnianie NTLM zostanie wynegocjowane i nie zostaną zainstalowane odpowiednie dodatki Service Pack na kontrolerach domeny systemu Windows 2000.

      • Śledzenie sieci ruchu LDAP między klientami i serwerami będzie szyfrowane. Utrudnia to zbadanie konwersacji LDAP.

      • Serwery oparte na systemie Windows 2000 muszą mieć dodatek Service Pack 3 (SP3) dla systemu Windows 2000 lub instalowane podczas administrowania nimi za pomocą programów obsługujących podpisywanie LDAP uruchamianych na komputerach klienckich z systemem Windows 2000 z dodatkiem SP4, Windows XP lub Windows Server 2003.  

   5. Nazwa symboliczna:
      
      LDAPServerIntegrity

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

   7. Przykłady problemów ze zgodnością

      • Proste powiązania nie powiodą się i zostanie wyświetlony następujący komunikat o błędzie:

        Ldap_simple_bind_s() nie powiodło się: wymagane silne uwierzytelnianie.

      • Windows 2000 z dodatkiem Service Pack 4, Windows XP, Windows Server 2003: W przypadku klientów z systemem Windows 2000 z dodatkiem SP4, Windows XP lub Windows Server 2003 niektóre narzędzia administracyjne usługi Active Directory nie będą działać poprawnie na kontrolerach domeny, na których są uruchomione wersje systemu Windows 2000 starsze niż z dodatkiem SP3 podczas negocjacji w sprawie uwierzytelniania NTLM.
        
         

      • Windows 2000 z dodatkiem Service Pack 4, Windows XP, Windows Server 2003: W przypadku klientów z systemem Windows 2000 z dodatkiem SP4, Windows XP lub Windows Server 2003 niektóre narzędzia administracyjne usługi Active Directory kierujące kontrolery domen korzystające z wersji systemu Windows 2000 starszych niż z dodatkiem SP3 nie będą działać poprawnie, jeśli używają adresów IP (na przykład "dsa.msc /server=x.x.x.x", gdzie
        x.x.x.x jest adresem IP).
        
        
         

      • Windows 2000 z dodatkiem Service Pack 4, Windows XP, Windows Server 2003: W przypadku klientów z systemem Windows 2000 z dodatkiem SP4, Windows XP lub Windows Server 2003 niektóre narzędzia administracyjne usługi Active Directory kierujące kontrolery domen, które korzystają z wersji systemu Windows 2000 starszych niż z dodatkiem SP3, nie będą działać poprawnie.
        
         

3. Członek domeny: wymagaj silnego (Windows 2000 lub nowszego) klucza sesji

   1. Tło

      • Członek domeny: ustawienie klucza sesji Wymagaj silnego (Windows 2000 lub nowszego) określa, czy można ustanowić bezpieczny kanał za pomocą kontrolera domeny, który nie może zaszyfrować bezpiecznego ruchu kanału przy użyciu silnego, 128-bitowego klucza sesji. Włączenie tego ustawienia uniemożliwia ustanowienie bezpiecznego kanału z dowolnym kontrolerem domeny, który nie może zaszyfrować danych bezpiecznego kanału za pomocą silnego klucza. Wyłączenie tego ustawienia umożliwia 64-bitowe klawisze sesji.

      • Zanim będzie można włączyć to ustawienie na stacji roboczej członka lub na serwerze, wszystkie kontrolery domeny w domenie, do której należy członek, muszą mieć możliwość szyfrowania danych bezpiecznego kanału przy użyciu silnego klucza 128-bitowego. Oznacza to, że na wszystkich takich kontrolerach domeny musi być zainstalowany system Windows 2000 lub nowszy.

   2. Ryzykowna konfiguracja
      
      Włączanie członka domeny: Wymaganie silnego (Windows 2000 lub nowszego) ustawienia klucza sesji jest szkodliwym ustawieniem konfiguracji.

   3. Powody włączenia tego ustawienia

      • Klucze sesji służące do ustanawiania bezpiecznego kanału komunikacji między komputerami członków i kontrolerami domeny są w systemie Windows 2000 znacznie silniejsze niż we wcześniejszych wersjach systemów operacyjnych firmy Microsoft.

      • Jeśli jest to możliwe, warto skorzystać z tych silniejszych kluczy sesji, aby chronić bezpieczną komunikację kanałową przed podsłuchiwaniem i przejmowaniem sesji ataków sieciowych. Podsłuchiwanie to rodzaj złośliwego ataku polegający na tym, że dane sieciowe są odczytywane lub zmieniane podczas przesyłania. Dane można modyfikować w celu ukrycia lub zmiany nadawcy albo przekierowania.

      Ważne Komputer z systemem Windows Server 2008 R2 lub Windows 7 obsługuje tylko silne klucze, gdy są używane bezpieczne kanały. To ograniczenie zapobiega zaufaniu między dowolną domeną opartą na systemie Windows NT 4.0 a dowolną domeną opartą na systemie Windows Server 2008 R2. Ponadto to ograniczenie blokuje członkostwo w domenie opartej na systemie Windows NT 4.0 na komputerach z systemem Windows 7 lub Windows Server 2008 R2 i na odwrót.

   4. Powody wyłączenia tego ustawienia
      
      Domena zawiera komputery członkowskie z systemami operacyjnymi innymi niż Windows 2000, Windows XP lub Windows Server 2003.

   5. Nazwa symboliczna:
      
      StrongKey

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

   7. Przykłady problemów
      
      ze zgodnością Windows NT 4.0: Na komputerach z systemem Windows NT 4.0 resetowanie bezpiecznych kanałów relacji zaufania między domenami Windows NT 4.0 i Windows 2000 z funkcją NLTEST kończy się niepowodzeniem. Zostanie wyświetlony komunikat o błędzie "Odmowa dostępu":

      Relacja zaufania między domeną podstawową a zaufaną domeną nie powiodła się.
      
      Windows 7 i Server 2008 R2: W systemach Windows 7 i nowszych wersjach oraz w systemie Windows Server 2008 R2 i nowszych wersjach to ustawienie nie jest już uwzględniane, a silny klucz jest zawsze używany. Z tego powodu relacje zaufania z domenami systemu Windows NT 4.0 nie działają dłużej.

4. Członek domeny: Cyfrowe szyfrowanie lub podpisywanie danych bezpiecznego kanału (zawsze)

   1. Tło

      • Włączanie członka domeny: Cyfrowe szyfrowanie lub podpisywanie bezpiecznych danych kanału (zawsze) uniemożliwia utworzenie bezpiecznego kanału z dowolnym kontrolerem domeny, który nie może podpisać ani zaszyfrować wszystkich danych bezpiecznego kanału. Aby chronić ruch uwierzytelniania przed atakami typu "man-in-the-middle", powtarzaniem ataków i innymi rodzajami ataków sieciowych, komputery z systemem Windows tworzą kanał komunikacji nazywany bezpiecznym kanałem za pośrednictwem usługi logowania sieciowego w celu uwierzytelniania kont komputerowych. Bezpieczne kanały są również używane, gdy użytkownik w jednej domenie łączy się z zasobem sieciowym w domenie zdalnej. To uwierzytelnianie wielodomenowe (uwierzytelnianie przekazujące) umożliwia komputerowi z systemem Windows, który dołączył do domeny, dostęp do bazy danych konta użytkownika w swojej domenie i we wszystkich zaufanych domenach.

      • Aby włączyć element członkowski domeny: Ustawienie Cyfrowo szyfruj lub podpisuj bezpieczne dane kanału (zawsze) na komputerze członka, wszystkie kontrolery domeny w domenie, do której należy dany członek, muszą mieć możliwość podpisywania lub szyfrowania wszystkich danych bezpiecznego kanału. Oznacza to, że na wszystkich takich kontrolerach domeny musi być zainstalowany system Windows NT 4.0 z dodatkiem Service Pack 6a (SP6a) lub nowszy.

      • Włączenie członka domeny: Ustawienie Cyfrowe szyfrowanie lub podpisywanie bezpiecznych danych kanału (zawsze) powoduje automatyczne włączenie ustawienia Członek domeny: Szyfrowanie cyfrowe lub podpisywanie danych bezpiecznego kanału (jeśli to możliwe).

   2. Ryzykowna konfiguracja
      
      Włączanie członka domeny: Ustawienie cyfrowego szyfrowania lub podpisywania danych bezpiecznego kanału (zawsze) w domenach, w których nie wszyscy kontrolerzy domeny mogą podpisywać lub szyfrować dane bezpiecznego kanału, jest szkodliwym ustawieniem konfiguracji.

   3. Powody włączenia tego ustawienia
      
      Niepodpisany ruch sieciowy jest podatny na ataki typu "man-in-the-middle", gdzie intruz przechwytuje pakiety między serwerem a klientem, a następnie modyfikuje je przed przesyłaniem ich dalej do klienta. Gdy to zachowanie występuje na serwerze protokołu LDAP (Lightweight Directory Access Protocol), intruz może powodować podejmowanie przez klienta decyzji opartych na fałszywych rekordach z katalogu LDAP. Możesz zmniejszyć ryzyko takiego ataku na sieć firmową, wdrażając silne fizyczne środki bezpieczeństwa w celu ochrony infrastruktury sieciowej. Ponadto zaimplementowanie trybu nagłówka uwierzytelniania PROTOKOŁU INTERNETOWEGO (IPSec) może pomóc w zapobieganiu atakom typu "man-in-the-middle". Ten tryb wykonuje wzajemne uwierzytelnianie i integralność pakietów dla ruchu IP.

   4. Powody wyłączenia tego ustawienia

      • Komputery w domenach lokalnych lub zewnętrznych obsługują zaszyfrowane bezpieczne kanały.

      • Nie wszystkie kontrolery domeny w tej domenie mają odpowiednie poziomy poprawek dodatku Service Pack do obsługi zaszyfrowanych bezpiecznych kanałów.

   5. Nazwa symboliczna:
      
      StrongKey

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

   7. Przykłady problemów ze zgodnością

      • Windows NT 4.0: Komputery z systemem Windows 2000 nie będą mogły dołączać do domen systemu Windows NT 4.0 i zostanie wyświetlony następujący komunikat o błędzie:

        Konto nie jest autoryzowane do logowania się z tej stacji.

        Aby uzyskać więcej informacji, kliknij następujący numer artykułu, aby wyświetlić ten artykuł w bazie wiedzy Microsoft Knowledge Base:

        281648 Komunikat o błędzie: Konto nie jest autoryzowane do logowania się z tej stacji
         

      • Windows NT 4.0: Domeny systemu Windows NT 4.0 nie będą w stanie ustanowić zaufania wyższego poziomu w domenie systemu Windows 2000 i zostanie wyświetlony następujący komunikat o błędzie:

        Konto nie jest autoryzowane do logowania się z tej stacji.

        Istniejące relacje zaufania wyższego poziomu mogą również nie uwierzytelniać użytkowników z zaufanej domeny. Niektórzy użytkownicy mogą mieć problemy z zalogowaniem się do domeny i może zostać wyświetlony komunikat o błędzie z informacją, że klient nie może znaleźć domeny.

      • Windows XP: Klienci systemu Windows XP przyłączeni do domen systemu Windows NT 4.0 nie będą mogli uwierzytelniać prób logowania i może zostać wyświetlony następujący komunikat o błędzie lub w dzienniku zdarzeń mogą zostać zarejestrowane następujące zdarzenia:

        System Windows nie może nawiązać połączenia z domeną, ponieważ kontroler domeny jest niedostępny lub w inny sposób niedostępny albo nie znaleziono konta komputera

      • Microsoft Network: Klienci microsoft network otrzymają jeden z następujących komunikatów o błędach:

        Błąd logowania: nieznana nazwa użytkownika lub złe hasło.

        W określonej sesji logowania nie ma klucza sesji użytkownika.

5. Klient sieci firmy Microsoft: cyfrowo podpisuj komunikację (zawsze)

   1. Tle
      
      Blok komunikatów serwera (SMB) to protokół udostępniania zasobów obsługiwany przez wiele systemów operacyjnych firmy Microsoft. Jest to podstawa podstawowego systemu wprowadzania/wyjścia sieci (NetBIOS) i wielu innych protokołów. Podpisywanie SMB uwierzytelnia zarówno użytkownika, jak i serwer hostujący dane. Jeśli którakolwiek ze stron nie przeprowadzi procesu uwierzytelniania, transmisja danych nie nastąpi.
      
      Włączanie podpisywania SMB rozpoczyna się podczas negocjacji protokołu SMB. Zasady podpisywania SMB określają, czy komputer zawsze podpisuje cyfrowo komunikację klienta.
      
      Protokół uwierzytelniania SMB systemu Windows 2000 obsługuje wzajemne uwierzytelnianie. Wzajemne uwierzytelnianie zamyka atak "człowiek w środku". Protokół uwierzytelniania SMB systemu Windows 2000 obsługuje również uwierzytelnianie wiadomości. Uwierzytelnianie wiadomości pomaga zapobiegać atakom aktywnych wiadomości. Aby zapewnić ci to uwierzytelnianie, podpisywanie SMB powoduje umieszczenie podpisu cyfrowego w każdej SMB. Każdy klient i serwer zweryfikują podpis cyfrowy.
      
      Aby użyć podpisywania SMB, musisz włączyć podpisywanie SMB lub wymagać podpisywania SMB zarówno w kliencie SMB, jak i na serwerze SMB. Jeśli na serwerze włączono podpisywanie SMB, klienci, dla których włączono również podpisywanie SMB, używają protokołu podpisywania pakietów we wszystkich kolejnych sesjach. Jeśli podpisywanie SMB jest wymagane na serwerze, klient nie może ustanowić sesji, chyba że klient jest włączony lub wymagany do podpisywania SMB.
      
      
      Włączenie logowania cyfrowego w sieciach o wysokim poziomie zabezpieczeń pomaga zapobiegać personifikacji klientów i serwerów. Ten rodzaj personifikacji jest znany jako porwanie sesji. Osoba atakująca mająca dostęp do tej samej sieci co klient lub serwer używa narzędzi do przejmowania sesji w celu przerwania, zakończenia lub kradzieży bieżącej sesji. Osoba atakująca może przechwycić i zmodyfikować niepodpisane pakiety SMB, zmodyfikować ruch, a następnie przesłać go dalej, aby serwer mógł wykonywać niechciane akcje. Osoba atakująca może też pozować jako serwer lub jako klient po uwierzytelnieniu, a następnie uzyskać nieautoryzowany dostęp do danych.
      
      Protokół SMB używany do udostępniania plików i udostępniania na komputerach z systemem Windows 2000 Server, Windows 2000 Professional, Windows XP Professional lub Windows Server 2003 obsługuje wzajemne uwierzytelnianie. Wzajemne uwierzytelnianie zamyka ataki polegające na przejmowaniu sesji i obsługuje uwierzytelnianie wiadomości. W związku z tym zapobiega atakom człowieka w środku. Podpisywanie SMB zapewnia to uwierzytelnianie przez umieszczenie podpisu cyfrowego w każdej SMB. Następnie klient i serwer zweryfikują podpis.
      
      Notatki

      • Alternatywnym środkiem zaradczym jest włączenie podpisów cyfrowych za pomocą protokołu IPSec, aby chronić cały ruch sieciowy. Istnieją sprzętowe akceleratory do szyfrowania IPSec i podpisywania, za pomocą których można zminimalizować wpływ procesora na wydajność procesora. Nie ma takich akceleratorów, które są dostępne do podpisywania SMB.
        
        Aby uzyskać więcej informacji, zobacz rozdział Digitally sign server communications (Komunikacja na serwerze podpisywania cyfrowego ) w witrynie internetowej Microsoft MSDN.
        
        Skonfiguruj podpisywanie za pomocą zasady grupy Edytora obiektów, ponieważ zmiana wartości lokalnego rejestru nie ma wpływu na nadrzędne zasady domeny.

      • W systemach Windows 95, Windows 98 i Windows 98 Second Edition klient usług katalogowych używa podpisów SMB podczas uwierzytelniania na serwerach systemu Windows Server 2003 przy użyciu uwierzytelniania NTLM. Jednak ci klienci nie używają podpisywania SMB podczas uwierzytelniania na tych serwerach przy użyciu uwierzytelniania NTLMv2. Ponadto serwery systemu Windows 2000 nie odpowiadają na żądania podpisywania SMB od tych klientów. Aby uzyskać więcej informacji, zobacz element 10: "Zabezpieczenia sieci: poziom uwierzytelniania menedżera Lan".

   2. Ryzykowna konfiguracja
      
      Jest to szkodliwe ustawienie konfiguracji: Opuszczanie klienta sieciowego firmy Microsoft: ustawienie Podpisywanie cyfrowe (zawsze) i klienta sieci firmy Microsoft: Ustawienie podpisywania cyfrowego komunikacji (jeśli serwer zgadza się) na wartość "Nie zdefiniowane" lub wyłączone. Te ustawienia umożliwiają przekierowywaniu wysyłanie haseł w formacie zwykłego tekstu do serwerów innych niż Microsoft SMB, które nie obsługują szyfrowania hasła podczas uwierzytelniania.

   3. Powody włączenia tego ustawienia
      
      Włączanie klienta sieciowego firmy Microsoft: Do podpisywania cyfrowego komunikacji (zawsze) klienci muszą podpisywać ruch SMB podczas kontaktowania się z serwerami, które nie wymagają podpisywania SMB. To sprawia, że klienci są mniej podatni na ataki polegające na przejmowaniu sesji.

   4. Powody wyłączenia tego ustawienia

      • Włączanie klienta sieci firmy Microsoft: Logowanie cyfrowe (zawsze) uniemożliwia klientom komunikowanie się z serwerami docelowymi, które nie obsługują podpisywania SMB.

      • Skonfigurowanie komputerów w celu ignorowania całej niepodpisanej komunikacji SMB uniemożliwia nawiązanie połączenia z wcześniejszymi programami i systemami operacyjnymi.

   5. Nazwa symboliczna:
      
      WymagaMBSignRdr

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

   7. Przykłady problemów ze zgodnością

      • Windows NT 4.0: Nie będzie można zresetować bezpiecznego kanału zaufania między domeną systemu Windows Server 2003 a domeną systemu Windows NT 4.0 przy użyciu funkcji TEST.NL lub NETDOM, a zostanie wyświetlony komunikat o błędzie "Odmowa dostępu".

      • Windows XP: Kopiowanie plików z klientów systemu Windows XP do serwerów opartych na systemie Windows 2000 i na serwery z systemem Windows Server 2003 może zająć więcej czasu.

      • Nie będzie można zamapować dysku sieciowego z poziomu klienta z włączonym tym ustawieniem i zostanie wyświetlony następujący komunikat o błędzie:

        Konto nie jest autoryzowane do logowania się z tej stacji.

   8. Wymagania dotyczące ponownego
      
      uruchamiania Uruchom ponownie komputer lub uruchom ponownie usługę Stacji roboczej. W tym celu wpisz następujące polecenia w wierszu polecenia. Po wpisaniu każdego polecenia naciśnij klawisz Enter.

      stacja robocza
      zatrzymania sieci net start workstation

6. Serwer sieciowy firmy Microsoft: cyfrowo podpisuj komunikację (zawsze)

   1. Tło

      • Server Messenger Block (SMB) to protokół udostępniania zasobów obsługiwany przez wiele systemów operacyjnych firmy Microsoft. Jest to podstawa podstawowego systemu wprowadzania/wyjścia sieci (NetBIOS) i wielu innych protokołów. Podpisywanie SMB uwierzytelnia zarówno użytkownika, jak i serwer hostujący dane. Jeśli którakolwiek ze stron nie przeprowadzi procesu uwierzytelniania, transmisja danych nie nastąpi.
        
        Włączanie podpisywania SMB rozpoczyna się podczas negocjacji protokołu SMB. Zasady podpisywania SMB określają, czy komputer zawsze podpisuje cyfrowo komunikację klienta.
        
        Protokół uwierzytelniania SMB systemu Windows 2000 obsługuje wzajemne uwierzytelnianie. Wzajemne uwierzytelnianie zamyka atak "człowiek w środku". Protokół uwierzytelniania SMB systemu Windows 2000 obsługuje również uwierzytelnianie wiadomości. Uwierzytelnianie wiadomości pomaga zapobiegać atakom aktywnych wiadomości. Aby zapewnić ci to uwierzytelnianie, podpisywanie SMB powoduje umieszczenie podpisu cyfrowego w każdej SMB. Każdy klient i serwer zweryfikują podpis cyfrowy.
        
        Aby użyć podpisywania SMB, musisz włączyć podpisywanie SMB lub wymagać podpisywania SMB zarówno w kliencie SMB, jak i na serwerze SMB. Jeśli na serwerze włączono podpisywanie SMB, klienci, dla których włączono również podpisywanie SMB, używają protokołu podpisywania pakietów we wszystkich kolejnych sesjach. Jeśli podpisywanie SMB jest wymagane na serwerze, klient nie może ustanowić sesji, chyba że klient jest włączony lub wymagany do podpisywania SMB.
        
        
        Włączenie logowania cyfrowego w sieciach o wysokim poziomie zabezpieczeń pomaga zapobiegać personifikacji klientów i serwerów. Ten rodzaj personifikacji jest znany jako porwanie sesji. Osoba atakująca mająca dostęp do tej samej sieci co klient lub serwer używa narzędzi do przejmowania sesji w celu przerwania, zakończenia lub kradzieży bieżącej sesji. Osoba atakująca może przechwycić i zmodyfikować niepodpisane pakiety Menedżera przepustowości podsieci (SBM), zmodyfikować ruch, a następnie przesłać go dalej, aby serwer mógł wykonywać niepożądane akcje. Osoba atakująca może też pozować jako serwer lub jako klient po uwierzytelnieniu, a następnie uzyskać nieautoryzowany dostęp do danych.
        
        Protokół SMB używany do udostępniania plików i udostępniania na komputerach z systemem Windows 2000 Server, Windows 2000 Professional, Windows XP Professional lub Windows Server 2003 obsługuje wzajemne uwierzytelnianie. Wzajemne uwierzytelnianie zamyka ataki polegające na przejmowaniu sesji i obsługuje uwierzytelnianie wiadomości. W związku z tym zapobiega atakom człowieka w środku. Podpisywanie SMB zapewnia to uwierzytelnianie przez umieszczenie podpisu cyfrowego w każdej SMB. Następnie klient i serwer zweryfikują podpis.

      • Alternatywnym środkiem zaradczym jest włączenie podpisów cyfrowych za pomocą protokołu IPSec, aby chronić cały ruch sieciowy. Istnieją sprzętowe akceleratory do szyfrowania IPSec i podpisywania, za pomocą których można zminimalizować wpływ procesora na wydajność procesora. Nie ma takich akceleratorów, które są dostępne do podpisywania SMB.

      • W systemach Windows 95, Windows 98 i Windows 98 Second Edition klient usług katalogowych używa podpisów SMB podczas uwierzytelniania na serwerach systemu Windows Server 2003 przy użyciu uwierzytelniania NTLM. Jednak ci klienci nie używają podpisywania SMB podczas uwierzytelniania na tych serwerach przy użyciu uwierzytelniania NTLMv2. Ponadto serwery systemu Windows 2000 nie odpowiadają na żądania podpisywania SMB od tych klientów. Aby uzyskać więcej informacji, zobacz element 10: "Zabezpieczenia sieci: poziom uwierzytelniania menedżera Lan".

   2. Ryzykowna konfiguracja
      
      Poniżej przedstawiono szkodliwe ustawienie konfiguracji: Włączanie serwera sieciowego firmy Microsoft: Ustawienie cyfrowego podpisywania komunikacji (zawsze) na serwerach i kontrolerach domeny, do których uzyskują dostęp niezgodne komputery z systemem Windows i komputery klienckie oparte na systemie operacyjnym innych firm w domenach lokalnych lub zewnętrznych.

   3. Powody włączenia tego ustawienia

      • Wszystkie komputery klienckie, które włączają to ustawienie bezpośrednio w rejestrze lub za pośrednictwem ustawienia zasady grupy obsługują podpisywanie SMB. Innymi słowy, na wszystkich komputerach klienckich z włączonym tym ustawieniem jest uruchamiany system Windows 95 z zainstalowanym klientem DS, systemem Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional lub Windows Server 2003.

      • Jeśli serwer sieci firmy Microsoft: Komunikacja podpisywania cyfrowego (zawsze) jest wyłączona, podpisywanie SMB jest całkowicie wyłączone. Całkowite wyłączenie wszystkich podpisów SMB sprawia, że komputery są bardziej narażone na ataki polegające na przejmowaniu sesji.

   4. Powody wyłączenia tego ustawienia

      • Włączenie tego ustawienia może spowodować wolniejsze kopiowanie plików i wydajność sieci na komputerach klienckich.

      • Włączenie tego ustawienia uniemożliwi klientom, którzy nie mogą negocjować podpisywania SMB, komunikację z serwerami i kontrolerami domeny. Powoduje to niepowodzenie operacji, takich jak sprzężenia domeny, uwierzytelnianie użytkowników i komputerów lub dostęp do sieci przez programy.

   5. Nazwa symboliczna:
      
      Wymaga serweraMBSignServer

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

   7. Przykłady problemów ze zgodnością

      • Windows 95: Klienci systemu Windows 95, którzy nie mają zainstalowanego klienta usług katalogowych (DS), nie mogą zalogować się i zostanie wyświetlony następujący komunikat o błędzie:

        Wprowadzone hasło domeny nie jest poprawne lub dostęp do serwera logowania został odrzucony.

      • Windows NT 4.0: Komputery klienckie, na których są uruchomione wersje systemu Windows NT 4.0 starsze niż z dodatkiem Service Pack 3 (SP3), nie będą uwierzytelniać się przy logowaniu i zostanie wyświetlony następujący komunikat o błędzie:

        System nie mógł cię zalogować. Upewnij się, że nazwa użytkownika i domena są poprawne, a następnie ponownie wpisz hasło.

        Niektóre serwery SMB innych firm obsługują wymianę nieszyfrowanych haseł podczas uwierzytelniania. (Te wymiany są również nazywane wymianami w formacie zwykłego tekstu). W systemie Windows NT 4.0 z dodatkiem SP3 i nowszych wersjach przekierowanie SMB nie wysyła niezaszyfrowanego hasła podczas uwierzytelniania do serwera SMB, chyba że dodasz określony wpis rejestru.
        Aby włączyć nieszyfrowane hasła dla klienta SMB w systemie Windows NT 4.0 z dodatkiem SP 3 i nowszych systemach, zmodyfikuj rejestr w następujący sposób: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
        
        Nazwa wartości: EnablePlainTextPassword
        
        Typ danych: REG_DWORD
        
        Dane: 1
        
         

      • Windows Server 2003: Domyślnie ustawienia zabezpieczeń na kontrolerach domeny uruchamianych w systemie Windows Server 2003 są skonfigurowane tak, aby uniemożliwić przechwycenie lub zmodyfikowanie komunikacji kontrolera domeny przez złośliwych użytkowników. Aby użytkownicy pomyślnie komunikowali się z kontrolerem domeny z systemem Windows Server 2003, komputery klienckie muszą używać podpisywania i szyfrowania SMB lub podpisywania bezpiecznego kanału. Domyślnie klienci korzystający z systemu Windows NT 4.0 z dodatkiem Service Pack 2 (SP2) lub starszym oraz klienci z systemem Windows 95 nie mają włączonego podpisywania pakietów SMB. W związku z tym ci klienci mogą nie być w stanie uwierzytelnić się na kontrolerze domeny opartym na systemie Windows Server 2003.

      • Ustawienia zasad systemów Windows 2000 i Windows Server 2003: W zależności od konkretnych potrzeb instalacji i konfiguracji zalecamy ustawienie następujących ustawień zasad w najniższej jednostce niezbędnego zakresu w hierarchii przyciągania Programu Microsoft Management Console zasady grupy Editor:

        • Konfiguracja komputera\ustawienia Zabezpieczenia Windows\Opcje zabezpieczeń

        • Wysyłanie nieszyfrowanego hasła w celu nawiązania połączenia z serwerami SMB innych firm (to ustawienie dotyczy systemu Windows 2000)

        • Klient sieci firmy Microsoft: Wysyłanie nieszyfrowanego hasła do serwerów SMB innych firm (to ustawienie dotyczy systemu Windows Server 2003)

        
        Uwaga W przypadku niektórych serwerów CIFS innych firm, takich jak starsze wersje samby, nie można używać zaszyfrowanych haseł.

      • Następujący klienci są niezgodni z serwerem sieciowym firmy Microsoft: Ustawienie Cyfrowego podpisywania komunikacji (zawsze):

        • Klienci Apple Computer, Inc., Mac OS X

        • Klienci sieciowy microsoft MS-DOS (na przykład Microsoft LAN Manager)

        • Klienci z systemem Microsoft Windows dla grup roboczych

        • Klienci systemu Microsoft Windows 95 bez zainstalowanego klienta DS

        • Komputery z systemem Microsoft Windows NT 4.0 bez dodatku SP3 lub nowszego

        • Novell Netware 6 klientów CIFS

        • Klienci SAMBA SMB, którzy nie obsługują podpisywania SMB

   8. Wymagania dotyczące ponownego
      
      uruchamiania Uruchom ponownie komputer lub uruchom ponownie usługę Serwer. W tym celu wpisz następujące polecenia w wierszu polecenia. Po wpisaniu każdego polecenia naciśnij klawisz Enter.

      net stop server
      net start server

7. Dostęp do sieci: zezwalaj na anonimowe tłumaczenie SID/Name

   1. Tle
      
      Ustawienie zabezpieczeń Dostęp do sieci: Zezwalaj na anonimowe tłumaczenie SID/Nazwa określa, czy użytkownik anonimowy może żądać atrybutów numeru identyfikacyjnego zabezpieczeń (SID) dla innego użytkownika.

   2. Ryzykowna konfiguracja
      
      Włączanie dostępu do sieci: Ustawienie zezwalania na anonimowe tłumaczenie SID/Name jest szkodliwym ustawieniem konfiguracji.

   3. Powody włączenia tego ustawienia
      
      Jeśli ustawienie Dostęp do sieci: Zezwalaj na anonimowe tłumaczenie SID/Nazwa jest wyłączone, wcześniejsze systemy operacyjne lub aplikacje mogą nie być w stanie komunikować się z domenami systemu Windows Server 2003. Na przykład następujące systemy operacyjne, usługi lub aplikacje mogą nie działać:

      • Serwery usług dostępu zdalnego w systemie Windows NT 4.0

      • Microsoft SQL Server, które są uruchomione na komputerach z systemem Windows NT 3.x lub komputerach z systemem Windows NT 4.0

      • Usługa dostępu zdalnego działająca na komputerach z systemem Windows 2000, które znajdują się w domenach systemu Windows NT 3.x lub w domenach systemu Windows NT 4.0

      • SQL Server uruchomione na komputerach z systemem Windows 2000, które znajdują się w domenach systemu Windows NT 3.x lub w domenach systemu Windows NT 4.0

      • Użytkownicy w domenie zasobów systemu Windows NT 4.0, którzy chcą udzielić uprawnień dostępu do plików, folderów udostępnionych i obiektów rejestru do kont użytkowników z domen kont zawierających kontrolery domeny systemu Windows Server 2003

   4. Powody wyłączenia tego ustawienia
      
      Jeśli to ustawienie jest włączone, złośliwy użytkownik może uzyskać rzeczywistą nazwę wbudowanego konta administratora, nawet jeśli zmieniono nazwę konta. Ta osoba może następnie użyć nazwy konta do zainicjowania ataku polegającego na odgadywaniu hasła.

   5. Nazwa symboliczna: Nie dotyczy

   6. Ścieżka rejestru: Brak. Ścieżka jest określona w kodzie interfejsu użytkownika.

   7. Przykłady problemów
      
      ze zgodnością Windows NT 4.0: Komputery w domenach zasobów systemu Windows NT 4.0 będą wyświetlać komunikat o błędzie "Nieznane konto" w Edytorze ACL, jeśli zasoby, w tym foldery udostępnione, pliki udostępnione i obiekty rejestru, są zabezpieczone podmiotami zabezpieczeń znajdującymi się w domenach kont zawierających kontrolery domeny systemu Windows Server 2003.

8. Dostęp do sieci: nie zezwalaj na anonimowe wyliczenie kont SAM

   1. Tło

      • Dostęp do sieci: Ustawienie Nie zezwalaj na anonimowe wyliczanie kont SAM określa, które dodatkowe uprawnienia zostaną przyznane dla anonimowych połączeń z komputerem. System Windows umożliwia użytkownikom anonimowym wykonywanie pewnych działań, takich jak wyliczanie nazw kont menedżera kont zabezpieczeń serwera i udziałów sieciowych oraz stacji roboczych i serwera. Na przykład administrator może udzielić dostępu użytkownikom w zaufanej domenie, którzy nie zachowują wzajemnego zaufania. Po utworzeniu sesji użytkownik anonimowy może mieć taki sam dostęp, jaki jest udzielany grupie Wszyscy na podstawie ustawienia dostępu sieciowego: Zezwalaj wszystkim na stosowanie uprawnień do ustawień użytkowników anonimowych lub listy kontroli dostępu (DACL) obiektu.
        
        Zazwyczaj połączenia anonimowe są wymagane przez wcześniejsze wersje klientów (klientów na poziomie podrzędnym) podczas konfigurowania sesji SMB. W takich przypadkach śledzenie sieci wskazuje, że identyfikator procesu SMB (PID) jest przekierowaniem klienta, takim jak 0xFEFF w systemie Windows 2000 lub 0xCAFE w systemie Windows NT. RPC może również próbować nawiązywać połączenia anonimowe.

      • Ważne To ustawienie nie ma wpływu na kontrolery domeny. Na kontrolerach domeny to zachowanie jest kontrolowane przez funkcję "NT AUTHORITY\ANONYMOUS LOGON" w programie Access zgodnym z systemem Windows 2000.

      • W systemie Windows 2000 podobne ustawienie o nazwie Dodatkowe ograniczenia dotyczące połączeń anonimowych zarządza wartością rejestru RestrictAnonymous . Lokalizacja tej wartości jest następująca

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

   2. Ryzykowne konfiguracje
      
      Włączanie dostępu do sieci: Ustawienie Nie zezwalaj na anonimowe wyliczenie kont SAM jest szkodliwym ustawieniem konfiguracji z perspektywy zgodności. Wyłączenie go jest szkodliwym ustawieniem konfiguracji z punktu widzenia zabezpieczeń.

   3. Powody włączenia tego ustawienia
      
      Nieautoryzowany użytkownik może anonimowo wyświetlić nazwy kont, a następnie użyć tych informacji do odgadnięcia haseł lub przeprowadzenia ataków na funkcje społecznościowe. Inżynieria społeczna to żargon, który oznacza nakłanianie ludzi do ujawnienia swoich haseł lub jakiejś formy informacji zabezpieczających.

   4. Powody wyłączenia tego ustawienia
      
      Jeśli to ustawienie jest włączone, nie można ustanowić relacji zaufania z domenami systemu Windows NT 4.0. To ustawienie powoduje również problemy z klientami wyższego poziomu (takimi jak klienci systemu Windows NT 3.51 i klienci systemu Windows 95), którzy próbują korzystać z zasobów na serwerze.

   5. Nazwa symboliczna:
      
      
      RestrictAnonymousSAM

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

   7. Przykłady problemów ze zgodnością

   • Usługa SMS Network Discovery nie będzie mogła uzyskać informacji o systemie operacyjnym i napisze "Unknown" we właściwości OperatingSystemNameandVersion.

   • Windows 95, Windows 98: Klienci systemu Windows 95 i klienci systemu Windows 98 nie będą mogli zmieniać swoich haseł.

   • Windows NT 4.0: Komputery członkowskie z systemem Windows NT 4.0 nie będą mogły być uwierzytelnione.

   • Windows 95, Windows 98: Komputery z systemem Windows 95 i Windows 98 nie będą mogły być uwierzytelnione przez kontrolery domeny firmy Microsoft.

   • Windows 95, Windows 98: Użytkownicy komputerów z systemem Windows 95 i Windows 98 nie będą mogli zmieniać haseł do swoich kont użytkowników.

9. Dostęp do sieci: nie zezwalaj na anonimowe wyliczenie kont SAM i udziałów

   1. Tło

      • Dostęp do sieci: Ustawienie Nie zezwalaj na anonimowe wyliczenie kont i udziałów SAM (nazywane również ustawieniem RestrictAnonymous) określa, czy anonimowe wyliczenie kont i udziałów menedżera kont zabezpieczeń (SAM) jest dozwolone. System Windows umożliwia użytkownikom anonimowym wykonywanie określonych działań, takich jak wyliczanie nazw kont domeny (użytkowników, komputerów i grup) oraz udziałów sieciowych. Jest to wygodne, na przykład gdy administrator chce udzielić dostępu użytkownikom w zaufanej domenie, którzy nie zachowują wzajemnego zaufania. Jeśli nie chcesz zezwalać na anonimowe wyliczenie kont SAM i udziałów, włącz to ustawienie.

      • W systemie Windows 2000 podobne ustawienie o nazwie Dodatkowe ograniczenia dotyczące połączeń anonimowych zarządza wartością rejestru RestrictAnonymous . Lokalizacja tej wartości jest następująca:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Ryzykowna konfiguracja
      
      Włączanie dostępu do sieci: Ustawienie Nie zezwalaj na anonimowe wyliczenie kont SAM i udziałów jest szkodliwym ustawieniem konfiguracji.

   3. Powody włączenia tego ustawienia

      • Włączanie dostępu sieciowego: Ustawienie Nie zezwalaj na anonimowe wyliczenie kont SAM i udziałów uniemożliwia wyliczenie kont SAM i udziałów przez użytkowników i komputery korzystające z kont anonimowych.

   4. Powody wyłączenia tego ustawienia

      • Jeśli to ustawienie jest włączone, nieautoryzowany użytkownik może anonimowo wyświetlić nazwy kont, a następnie użyć tych informacji do odgadnięcia haseł lub przeprowadzenia ataków na funkcje społecznościowe. Inżynieria społeczna to żargon, który oznacza nakłanianie ludzi do ujawnienia hasła lub jakiejś formy informacji zabezpieczających.

      • Jeśli to ustawienie jest włączone, nie można ustanowić relacji zaufania z domenami systemu Windows NT 4.0. To ustawienie spowoduje również problemy z klientami wyższego poziomu, takimi jak klienci systemu Windows NT 3.51 i Windows 95, którzy próbują korzystać z zasobów na serwerze.

      • Nie będzie można udzielić dostępu użytkownikom domen zasobów, ponieważ administratorzy w domenie ufającej nie będą mogli wyliczanie list kont w innej domenie. Użytkownicy, którzy anonimowo uzyskują dostęp do serwerów plików i drukarek, nie będą mogli wyświetlać na tych serwerach udostępnionych zasobów sieciowych. Użytkownicy muszą się uwierzytelnić, aby mogli wyświetlać listy udostępnionych folderów i drukarek.

   5. Nazwa symboliczna:
      
      Restrictanonymous

   6. Ścieżka rejestru:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

   7. Przykłady problemów ze zgodnością

      • Windows NT 4.0: Użytkownicy nie będą mogli zmieniać swoich haseł ze stacji roboczych systemu Windows NT 4.0 po włączeniu funkcji RestrictAnonymous na kontrolerach domeny w domenie użytkowników.

      • Windows NT 4.0: Dodawanie użytkowników lub grup globalnych z zaufanych domen systemu Windows 2000 do grup lokalnych systemu Windows NT 4.0 w Menedżerze użytkowników nie powiedzie się i zostanie wyświetlony następujący komunikat o błędzie:

        Obecnie nie ma żadnych serwerów logowania do obsługi żądania logowania.

      • Windows NT 4.0: Komputery z systemem Windows NT 4.0 nie będą mogły dołączać do domen podczas instalacji ani przy użyciu interfejsu użytkownika dołączania do domeny.

      • Windows NT 4.0: Ustanowienie zaufania wyższego poziomu w domenach zasobów systemu Windows NT 4.0 zakończy się niepowodzeniem. Po włączeniu funkcji RestrictAnonymous w zaufanej domenie zostanie wyświetlony następujący komunikat o błędzie:

        Nie można znaleźć kontrolera domeny dla tej domeny.

      • Windows NT 4.0: Użytkownicy, którzy logują się do komputerów z serwerem terminali systemu Windows NT 4.0, będą mapować na domyślny katalog domowy zamiast na katalog domowy zdefiniowany w Menedżerze użytkowników dla domen.

      • Windows NT 4.0: Kontrolery domeny kopii zapasowej systemu Windows NT 4.0 (BDC) nie będą mogły uruchomić usługi logowania sieciowego, uzyskać listy przeglądarek kopii zapasowych ani zsynchronizować bazy danych SAM z systemu Windows 2000 lub z kontrolerów domeny systemu Windows Server 2003 w tej samej domenie.

      • Windows 2000: Komputery członkowskie z systemem Windows 2000 w domenach systemu Windows NT 4.0 nie będą mogły wyświetlać drukarek w domenach zewnętrznych, jeśli ustawienie Brak dostępu bez jawnie anonimowych uprawnień jest włączone w lokalnych zasadach zabezpieczeń na komputerze klienckim.

      • Windows 2000: Użytkownicy domeny systemu Windows 2000 nie będą mogli dodawać drukarek sieciowych z usługi Active Directory; jednak będą mogli dodawać drukarki po ich wybraniu w widoku drzewa.

      • Windows 2000: Na komputerach z systemem Windows 2000 Edytor ACL nie będzie mógł dodawać użytkowników ani grup globalnych z zaufanych domen systemu Windows NT 4.0.

      • ADMT w wersji 2: Migracja haseł dla kont użytkowników migrowanych między lasami za pomocą narzędzia do migracji usługi Active Directory (ADMT) w wersji 2 nie powiedzie się.
        
        Aby uzyskać więcej informacji, kliknij następujący numer artykułu, aby wyświetlić ten artykuł w bazie wiedzy Microsoft Knowledge Base:

        322981 Rozwiązywanie problemów z migracją haseł między lasami za pomocą ADMTv2

      • Klienci programu Outlook: globalna lista adresowa będzie pusta dla klientów programu Microsoft Exchange Outlook.

      • SMS: Program Microsoft Systems Management Server (SMS) Network Discovery nie będzie mógł uzyskać informacji o systemie operacyjnym. W związku z tym będzie pisać "Nieznany" we właściwości OperatingSystemNameandVersion właściwości SMS DDR rekordu danych odnajdowania (DDR).

      • WIADOMOŚCI SMS: W przypadku przeglądania użytkowników i grup za pomocą Kreatora użytkowników usługi SMS nie będą wyświetlane żadne osoby ani grupy. Ponadto klienci zaawansowani nie mogą komunikować się z punktem zarządzania. W punkcie zarządzania jest wymagany dostęp anonimowy.

      • WIADOMOŚCI SMS: Jeśli używasz funkcji odnajdowania sieci w programie SMS 2.0 i zdalnej instalacji klienta z włączoną opcją odnajdowania sieci topologii, klienta i klienckich systemów operacyjnych, komputery mogą być wykrywane, ale mogą nie być zainstalowane.

10. Zabezpieczenia sieci: poziom uwierzytelniania w aplikacji Lan Manager

    1. Tle
       
       Uwierzytelnianie menedżera SIECI LAN (LM) jest protokołem używanym do uwierzytelniania klientów systemu Windows na potrzeby operacji sieciowych, w tym przyłączeń do domeny, uzyskiwania dostępu do zasobów sieciowych oraz uwierzytelniania użytkowników lub komputerów. Poziom uwierzytelniania LM określa, który protokół uwierzytelniania wyzwania/odpowiedzi jest negocjowany między klientem a komputerem serwera. W szczególności poziom uwierzytelniania LM określa protokoły uwierzytelniania, które klient będzie próbował negocjować lub które zaakceptuje serwer. Wartość ustawiona dla parametru LmCompatibilityLevel określa, który protokół uwierzytelniania wyzwania/odpowiedzi jest używany do logowania w sieci. Ta wartość wpływa na poziom protokołu uwierzytelniania, z którego korzystają klienci, poziom negocjowanych zabezpieczeń sesji oraz poziom uwierzytelniania akceptowanego przez serwery.
       
       Możliwe ustawienia obejmują następujące ustawienia.

       Wartość	Ustawienie	Opis
       0	Wysyłanie odpowiedzi NTLM & LM	Klienci używają uwierzytelniania LM i NTLM i nigdy nie używają zabezpieczeń sesji NTLMv2. Kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLMv2.
       1	Wyślij LM & NTLM — użyj zabezpieczeń sesji NTLMv2 w przypadku negocjacji	Klienci korzystają z uwierzytelniania LM i NTLM i używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLMv2.
       2	Wysyłanie tylko odpowiedzi NTLM	Klienci używają tylko uwierzytelniania NTLM i używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLMv2.
       3	Wysyłanie tylko odpowiedzi NTLMv2	Klienci używają tylko uwierzytelniania NTLMv2 i używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLMv2.
       4	Wyślij tylko odpowiedź NTLMv2/odrzuć LM	Klienci używają tylko uwierzytelniania NTLMv2 i używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny odmawiają LM i akceptują tylko uwierzytelnianie NTLM i NTLMv2.
       5	Wyślij tylko odpowiedź NTLMv2/odrzuć LM & NTLM	Klienci używają tylko uwierzytelniania NTLMv2 i używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny odmawiają uwierzytelniania LM i NTLM i akceptują tylko uwierzytelnianie NTLMv2.

       Uwaga W systemach Windows 95, Windows 98 i Windows 98 Second Edition klient usług katalogowych używa podpisów SMB podczas uwierzytelniania na serwerach systemu Windows Server 2003 przy użyciu uwierzytelniania NTLM. Jednak ci klienci nie używają podpisywania SMB podczas uwierzytelniania na tych serwerach przy użyciu uwierzytelniania NTLMv2. Ponadto serwery systemu Windows 2000 nie odpowiadają na żądania podpisywania SMB od tych klientów.
       
       Sprawdź poziom uwierzytelniania LM: Musisz zmienić zasady na serwerze, aby zezwolić na NTLM, lub musisz skonfigurować klienta do obsługi NTLMv2.
       
       Jeśli ta zasada jest ustawiona na (5) Wyślij tylko odpowiedź NTLMv2\odrzuć LM & NTLM na komputerze docelowym, z którym chcesz nawiązać połączenie, musisz obniżyć ustawienie na tym komputerze lub ustawić zabezpieczenia na takie samo ustawienie jak na komputerze źródłowym, z którego nawiązujesz połączenie.
       
       Znajdź właściwą lokalizację, w której możesz zmienić poziom uwierzytelniania menedżera sieci LAN, aby ustawić klienta i serwer na tym samym poziomie. Po znalezieniu zasad, które ustawiają poziom uwierzytelniania menedżera sieci LAN, jeśli chcesz nawiązać połączenie z komputerami z wcześniejszymi wersjami systemu Windows i z nich, zmniejsz wartość do co najmniej (1) Wyślij usługę LM & NTLM — w razie negocjacji użyj zabezpieczeń sesji NTLM w wersji 2. Jednym z efektów niezgodnych ustawień jest to, że jeśli serwer wymaga NTLMv2 (wartość 5), ale klient jest skonfigurowany do używania tylko LM i NTLMv1 (wartość 0), użytkownik próbujący uwierzytelnić doświadcza błędu logowania z nieprawidłowym hasłem, co zwiększa liczbę nieprawidłowych haseł. Jeśli blokada konta jest skonfigurowana, użytkownik może zostać zablokowany.
       
       Na przykład może być konieczne wyszukanie kontrolera domeny lub może być konieczne sprawdzenie zasad kontrolera domeny.
       
       Poszukaj kontrolera domeny
       
       Uwaga Może być konieczne powtórzenie poniższej procedury na wszystkich kontrolerach domeny.

       1. Kliknij przycisk Start, wskaż pozycję Programy, a następnie kliknij pozycję Narzędzia administracyjne.

       2. W obszarze Ustawienia zabezpieczeń lokalnych rozwiń pozycję Zasady lokalne.

       3. Kliknij pozycję Opcje zabezpieczeń.

       4. Kliknij dwukrotnie pozycję Zabezpieczenia sieciowe: poziom uwierzytelniania menedżera sieci LAN, a następnie kliknij wartość na liście.

       
       Jeśli ustawienie efektywne i ustawienie lokalne są takie same, zasady zostały zmienione na tym poziomie. Jeśli ustawienia są inne, należy sprawdzić zasady kontrolera domeny, aby ustalić, czy w tym miejscu jest zdefiniowane ustawienie zabezpieczeń sieciowych: poziom uwierzytelniania menedżera sieci LAN. Jeśli go tam nie zdefiniowano, sprawdź zasady kontrolera domeny.
       
       Sprawdzanie zasad kontrolera domeny

       1. Kliknij przycisk Start, wskaż pozycję Programy, a następnie kliknij pozycję Narzędzia administracyjne.

       2. W sekcji Zasady zabezpieczeń kontrolera domeny rozwiń pozycję Ustawienia zabezpieczeń, a następnie rozwiń pozycję Zasady lokalne.

       3. Kliknij pozycję Opcje zabezpieczeń.

       4. Kliknij dwukrotnie pozycję Zabezpieczenia sieciowe: poziom uwierzytelniania menedżera sieci LAN, a następnie kliknij wartość na liście.

       
       Uwaga

       • Może być również konieczne sprawdzenie zasad połączonych na poziomie witryny, na poziomie domeny lub na poziomie jednostki organizacyjnej (OU), aby określić, gdzie należy skonfigurować poziom uwierzytelniania menedżera SIECI LAN.

       • Jeśli zaimplementujesz ustawienie zasady grupy jako domyślne zasady domeny, te zasady zostaną zastosowane do wszystkich komputerów w domenie.

       • Jeśli zaimplementujesz ustawienie zasady grupy jako domyślne zasady kontrolera domeny, zasady te będą stosowane tylko do serwerów WY kontrolera domeny.

       • Warto ustawić poziom uwierzytelniania menedżera SIECI LAN w najniższej jednostce niezbędnego zakresu w hierarchii aplikacji zasad.

       System Windows Server 2003 ma nowe ustawienie domyślne umożliwiające używanie tylko NTLMv2. Domyślnie kontrolery domeny oparte na systemach Windows Server 2003 i Windows 2000 Server z dodatkiem SP3 włączyły zasady "Serwer sieciowy Firmy Microsoft: komunikacja podpisywania cyfrowego (zawsze)". To ustawienie wymaga, aby serwer SMB wykonywał podpisywanie pakietów SMB. Zmiany w systemie Windows Server 2003 zostały wprowadzone, ponieważ kontrolery domeny, serwery plików, serwery infrastruktury sieciowej i serwery sieci Web w dowolnej organizacji wymagają różnych ustawień, aby zmaksymalizować swoje zabezpieczenia.
       
       Jeśli chcesz zaimplementować uwierzytelnianie NTLMv2 w swojej sieci, musisz upewnić się, że na wszystkich komputerach w domenie jest ustawiony ten poziom uwierzytelniania. Jeśli zastosujesz rozszerzenia klientów usługi Active Directory dla systemów Windows 95, Windows 98 i Windows NT 4.0, rozszerzenia klienta będą korzystać z ulepszonych funkcji uwierzytelniania dostępnych w NTLMv2. W związku z tym, że system Windows 2000 zasady grupy Objects nie ma wpływu na komputery klienckie z żadnym z następujących systemów operacyjnych, może być konieczne ręczne skonfigurowanie tych klientów:

       • Microsoft Windows NT 4.0

       • Microsoft Windows Millennium Edition

       • Microsoft Windows 98

       • Microsoft Windows 95

       Uwaga Jeśli włączysz zabezpieczenia sieciowe: Nie przechowuj wartości skrótu menedżera SIECI LAN w następnych zasadach zmiany hasła ani nie ustawiaj klucza rejestru NoLMHash , klienci z systemami Windows 95 i Windows 98, którzy nie mają zainstalowanego klienta usług katalogowych, nie mogą logować się do domeny po zmianie hasła.
       
       Wiele serwerów CIFS innych firm, takich jak Novell Netware 6, nie wie o NTLMv2 i używa tylko NTLM. W związku z tym poziomy większe niż 2 nie pozwalają na łączność. Istnieją również klienci SMB innych firm, którzy nie korzystają z zabezpieczeń sesji rozszerzonej. W takich przypadkach wartość LmCompatiblityLevel serwera zasobów nie jest brana pod uwagę. Następnie serwer spakuje to starsze żądanie i wysyła je do kontrolera domeny użytkownika. Następnie ustawienia kontrolera domeny decydują, jakie skróty są używane do zweryfikowania żądania i czy spełniają one wymagania dotyczące zabezpieczeń kontrolera domeny.
       
        

       299656 Jak uniemożliwić systemowi Windows przechowywanie skrótu hasła menedżera SIECI LAN w usłudze Active Directory i lokalnych bazach danych SAM
        

       2701704Zdarzenie inspekcji wyświetla pakiet uwierzytelniania jako NTLMv1 zamiast NTLMv2 Aby uzyskać więcej informacji na temat poziomów uwierzytelniania LM, kliknij następujący numer artykułu, aby wyświetlić ten artykuł w bazie wiedzy Microsoft Knowledge Base:

       239869 Jak włączyć uwierzytelnianie NTLM 2
        

    2. Ryzykowne konfiguracje
       
       Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

       • Ustawienia nierestrictive, które wysyłają hasła w cleartext i które odmawiają negocjacji NTLMv2

       • Restrykcyjne ustawienia uniemożliwiające niezgodnym klientom lub kontrolerom domeny negocjowanie wspólnego protokołu uwierzytelniania

       • Wymaganie uwierzytelniania NTLMv2 na komputerach członków i kontrolerach domeny, na których są uruchomione wersje systemu Windows NT 4.0 starsze niż dodatek Service Pack 4 (SP4)

       • Wymaganie uwierzytelniania NTLMv2 w klientach systemu Windows 95 lub w klientach systemu Windows 98, którzy nie mają zainstalowanego klienta usług katalogowych Windows.

       • Jeśli klikniesz pole wyboru Wymagaj zabezpieczeń sesji NTLMv2 w przystawki Microsoft Management Console zasady grupy Editor na komputerze z systemem Windows Server 2003 lub Windows 2000 z dodatkiem Service Pack 3 i obniżysz poziom uwierzytelniania menedżera SIECI LAN do 0, wystąpi konflikt dwóch ustawień i w pliku Secpol.msc lub pliku GPEdit.msc może zostać wyświetlony następujący komunikat o błędzie:

         System Windows nie może otworzyć bazy danych zasad lokalnych. Podczas próby otwarcia bazy danych wystąpił nieznany błąd.

         Aby uzyskać więcej informacji o narzędziu konfiguracji i analizy zabezpieczeń, zobacz pliki Pomocy systemu Windows 2000 lub Windows Server 2003.

    3. Powody, dla których należy zmodyfikować to ustawienie

       • Chcesz zwiększyć najniższy typowy protokół uwierzytelniania obsługiwany przez klientów i kontrolery domeny w organizacji.

       • Jeśli bezpieczne uwierzytelnianie jest wymaganiem biznesowym, chcesz nie zezwalać na negocjowanie protokołów LM i NTLM.

    4. Powody wyłączenia tego ustawienia
       
       Wymagania uwierzytelniania klienta lub serwera zostały zwiększone do punktu, w którym uwierzytelnianie za pośrednictwem wspólnego protokołu nie może wystąpić.

    5. Nazwa symboliczna:
       
       Lmcompatibilitylevel

    6. Ścieżka rejestru:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. Przykłady problemów ze zgodnością

       • Windows Server 2003: Domyślnie jest włączone ustawienie Wysyłaj odpowiedzi NTLM w systemie Windows Server 2003 NTLMv2. Dlatego system Windows Server 2003 otrzymuje komunikat o błędzie "Odmowa dostępu" po pierwszej instalacji podczas próby nawiązania połączenia z klastrem opartym na systemie Windows NT 4.0 lub z serwerami opartymi na technologii LanManager w wersji 2.1, takimi jak lanserver systemu operacyjnego/2. Ten problem występuje również w przypadku próby nawiązania połączenia z serwera z systemem Windows Server 2003 za pomocą klienta starszej wersji.

       • Instalowanie pakietu zbiorczego aktualizacji zabezpieczeń systemu Windows 2000 1 (SRP1). SRP1 wymusza NTLM w wersji 2 (NTLMv2). Ten pakiet zbiorczy aktualizacji został wydany po wydaniu dodatku Service Pack 2 (SP2) dla systemu Windows 2000.
          

       • Windows 7 i Windows Server 2008 R2: Wiele serwerów CIFS innych firm, takich jak novell Netware 6 lub serwery Samby oparte na systemie Linux, nie zna NTLMv2 i używa tylko NTLM. Dlatego poziomy większe niż "2" nie zezwalają na łączność. W tej wersji systemu operacyjnego ustawienie domyślne dla parametru LmCompatibilityLevel zostało zmienione na "3". Dlatego podczas uaktualniania systemu Windows te pliki innych firm mogą przestać działać.

       • Klientom programu Microsoft Outlook może zostać wyświetlony monit o podanie poświadczeń, nawet jeśli są już zalogowani do domeny. Gdy użytkownicy podają swoje poświadczenia, otrzymują następujący komunikat o błędzie: Windows 7 i Windows Server 2008 R2

         Podane poświadczenia logowania były niepoprawne. Upewnij się, że nazwa użytkownika i domena są poprawne, a następnie ponownie wpisz hasło.

         Po uruchomieniu programu Outlook może zostać wyświetlony monit o podanie poświadczeń, nawet jeśli dla ustawienia Zabezpieczenia sieci logowania jest ustawiona wartość Przekazywanie lub Uwierzytelnianie hasłem. Po wpisaniu prawidłowych poświadczeń może zostać wyświetlony następujący komunikat o błędzie:

         Podane poświadczenia logowania były nieprawidłowe.

         Śledzenie monitora sieci może pokazać, że w wykazie globalnym wystąpił błąd zdalnego wywołania procedur (RPC) ze stanem 0x5. Stan 0x5 oznacza "Odmowa dostępu".

       • Windows 2000: Przechwytywanie monitora sieci może pokazywać następujące błędy w sesji bloku komunikatów serwera TCP/IP (NetBT) (NetBT):

         Błąd SMB R Search Directory Dos, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Nieprawidłowy identyfikator użytkownika

       • Windows 2000: Jeśli domena systemu Windows 2000 z NTLMv2 poziomu 2 lub nowszym jest zaufana przez domenę systemu Windows NT 4.0, komputery członkowskie systemu Windows 2000 w domenie zasobu mogą występować błędy uwierzytelniania.

       • Windows 2000 i Windows XP: Domyślnie systemy Windows 2000 i Windows XP ustawiają opcję lokalnych zasad zabezpieczeń na poziomie uwierzytelniania menedżera LAN na 0. Ustawienie 0 oznacza "Wysyłaj odpowiedzi LM i NTLM".
         
         Uwaga Klastry oparte na systemie Windows NT 4.0 muszą używać usługi LM do administrowania.

       • Windows 2000: Klastrowanie w systemie Windows 2000 nie uwierzytelnia węzła dołączającego, jeśli oba węzły są częścią domeny z dodatkiem Service Pack 6a (SP6a) systemu Windows NT 4.0.

       • Narzędzie blokowania IIS (HiSecWeb) ustawia wartość LMCompatibilityLevel na 5, a wartość RestrictAnonymous na 2.

       • Usługi dla komputerów Macintosh
         
         Moduł uwierzytelniania użytkowników (UAM): Usługa Microsoft UAM (User Authentication Module) udostępnia metodę szyfrowania haseł używanych do logowania się na serwerach usługi Windows AFP (AppleTalk Filing Protocol). Moduł uwierzytelniania użytkowników firmy Apple (UAM) zapewnia tylko minimalne szyfrowanie lub nie zapewnia żadnego szyfrowania. W związku z tym hasło można łatwo przechwycić w sieci LAN lub Internecie. Mimo że usługa UAM nie jest wymagana, zapewnia zaszyfrowane uwierzytelnianie dla serwerów systemu Windows 2000, na których są uruchamiane usługi dla komputerów Macintosh. Ta wersja zawiera obsługę 128-bitowego uwierzytelniania szyfrowanego NTLMv2 i wersji zgodnej z systemem MacOS X 10.1.
         
         Domyślnie serwer Windows Server 2003 Services for Macintosh zezwala tylko na uwierzytelnianie firmy Microsoft.
          

       • Windows Server 2008, Windows Server 2003, Windows XP i Windows 2000: Jeśli skonfigurujesz wartość LMCompatibilityLevel na 0 lub 1, a następnie skonfigurujesz wartość NoLMHash na 1, aplikacje i składniki mogą zostać pozbawione dostępu przez NTLM. Ten problem występuje, ponieważ komputer jest skonfigurowany do włączania usługi LM, ale nie do używania haseł przechowywanych w usłudze LM.
         
         W przypadku skonfigurowania wartości NoLMHash na wartość 1 należy skonfigurować wartość LMCompatibilityLevel na wartość 2 lub nowszą.

11. Zabezpieczenia sieci: wymagania dotyczące podpisywania klientów LDAP

    1. Tle
       
       Ustawienie Zabezpieczenia sieci: wymagania dotyczące podpisywania klientów LDAP określa poziom podpisywania danych, który jest wymagany w imieniu klientów, którzy wysyłają żądania BIND protokołu Lightweight Directory Access Protocol (LDAP) w następujący sposób:

       • Brak: Żądanie LDAP BIND jest wydawane z opcjami określonymi przez wywołującego.

       • Negocjowanie podpisywania: Jeśli protokół SSL/TLS (Secure Sockets Layer/Transport Layer Security) nie został uruchomiony, żądanie LDAP BIND jest inicjowane z opcją podpisywania danych LDAP ustawioną oprócz opcji określonych przez wywołującego. Jeśli protokół SSL/TLS został uruchomiony, żądanie LDAP BIND jest inicjowane z opcjami określonymi przez wywołującego.

       • Wymagaj podpisywania: jest to to samo, co negocjowanie podpisywania. Jeśli jednak pośrednia odpowiedź serwera LDAP saslBindInProgress nie wskazuje, że podpis ruchu LDAP jest wymagany, obiekt wywołujący otrzymuje informację, że żądanie polecenia LDAP BIND nie powiodło się.

    2. Ryzykowna konfiguracja
       
       Włączanie ustawienia Zabezpieczenia sieci: Wymagania dotyczące podpisywania klienta LDAP to szkodliwe ustawienie konfiguracji. Jeśli ustawisz serwer tak, aby wymagał podpisów LDAP, musisz również skonfigurować podpisywanie LDAP na kliencie. Nie skonfigurowanie klienta do używania podpisów LDAP uniemożliwi komunikację z serwerem. Powoduje to niepowodzenie uwierzytelniania użytkowników, ustawień zasady grupy, skryptów logowania i innych funkcji.

    3. Powody, dla których należy zmodyfikować to ustawienie
       
       Niepodpisany ruch sieciowy jest podatny na ataki typu "man-in-the-middle", w których intruz przechwytuje pakiety między klientem a serwerami, modyfikuje je, a następnie przekazuje na serwer. W takim przypadku na serwerze LDAP osoba atakująca może spowodować, że serwer odpowie na podstawie fałszywych zapytań z klienta LDAP. Możesz zmniejszyć to ryzyko w sieci firmowej, wdrażając silne fizyczne środki bezpieczeństwa w celu ochrony infrastruktury sieciowej. Ponadto możesz pomóc w zapobieganiu wszelkiego rodzaju atakom typu "człowiek w środku", wymagając podpisów cyfrowych we wszystkich pakietach sieciowych za pomocą nagłówków uwierzytelniania IPSec.

    4. Nazwa symboliczna:
       
       LDAPClientIntegrity

    5. Ścieżka rejestru:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

12. Dziennik zdarzeń: maksymalny rozmiar dziennika zabezpieczeń

    1. Tle
       
       Dziennik zdarzeń: Ustawienie maksymalnego rozmiaru dziennika zabezpieczeń określa maksymalny rozmiar dziennika zdarzeń zabezpieczeń. Ten dziennik ma maksymalny rozmiar 4 GB. Aby zlokalizować to ustawienie, rozwiń pozycję
       Ustawienia systemu Windows, a następnie rozwiń pozycję Ustawienia zabezpieczeń.

    2. Ryzykowne konfiguracje
       
       Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

       • Ograniczanie rozmiaru dziennika zabezpieczeń i metody przechowywania dziennika zabezpieczeń, gdy jest włączone ustawienie Inspekcja: Zamknij system natychmiast, jeśli nie można zarejestrować inspekcji zabezpieczeń. Aby uzyskać więcej szczegółowych informacji, zobacz sekcję "Inspekcja: Zamknij system natychmiast, jeśli nie można zarejestrować inspekcji zabezpieczeń".

       • Ograniczanie rozmiaru dziennika zabezpieczeń w celu zastąpienia pożądanych zdarzeń zabezpieczeń.

    3. Powody, dla których warto zwiększyć to ustawienie
       
       Wymagania biznesowe i zabezpieczeń mogą wymagać zwiększenia rozmiaru dziennika zabezpieczeń w celu obsługi dodatkowych szczegółów dziennika zabezpieczeń lub zachowania dzienników zabezpieczeń przez dłuższy czas.

    4. Powody, dla których warto zmniejszyć to ustawienie
       
       Podgląd zdarzeń dzienniki to pliki zamapowane na pamięć. Maksymalny rozmiar dziennika zdarzeń jest ograniczony ilością pamięci fizycznej na komputerze lokalnym i pamięci wirtualnej dostępnej w procesie dziennika zdarzeń. Zwiększenie rozmiaru dziennika poza ilość pamięci wirtualnej, która jest dostępna dla Podgląd zdarzeń nie zwiększa liczby wpisów dziennika, które są obsługiwane.

    5. Przykłady problemów
       
       ze zgodnością Windows 2000: Komputery z wersjami systemu Windows 2000 starszymi niż z dodatkiem Service Pack 4 (SP4) mogą przestać rejestrować zdarzenia w dzienniku zdarzeń przed osiągnięciem rozmiaru określonego w ustawieniu Maksymalny rozmiar dziennika w Podgląd zdarzeń, jeśli jest włączona opcja Nie zastąp zdarzeń (wyczyść dziennik ręcznie).
       
       
        

13. Dziennik zdarzeń: zachowanie dziennika zabezpieczeń

    1. Tle
       
       Dziennik zdarzeń: Zachowanie ustawienia zabezpieczeń dziennika zabezpieczeń określa metodę zawijania dla dziennika zabezpieczeń. Aby zlokalizować to ustawienie, rozwiń pozycję Ustawienia systemu Windows, a następnie rozwiń pozycję Ustawienia zabezpieczeń.

    2. Ryzykowne konfiguracje
       
       Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

       • Nie można zachować wszystkich zarejestrowanych zdarzeń zabezpieczeń przed ich zastąpieniem

       • Konfigurowanie ustawienia Maksymalny rozmiar dziennika zabezpieczeń za małe, aby zdarzenia zabezpieczeń były zastępowane

       • Ograniczanie rozmiaru dziennika zabezpieczeń i metody przechowywania podczas inspekcji: zamknij system natychmiast, jeśli nie można zarejestrować ustawienia zabezpieczeń inspekcji zabezpieczeń

    3. Powody włączenia tego ustawienia
       
       Włącz to ustawienie tylko wtedy, gdy wybierzesz metodę przechowywania Zastąpij zdarzenia według dni . Jeśli używasz systemu korelacji zdarzeń, który sprawdza zdarzenia, upewnij się, że liczba dni jest co najmniej trzykrotna w danej częstotliwości ankiety. Zrób to, aby zezwolić na nieudane cykle ankiety.

14. Dostęp do sieci: zezwalaj wszystkim na stosowanie uprawnień do użytkowników anonimowych

    1. Tle
       
       Domyślnie dla ustawienia Dostęp sieciowego: Zezwalaj wszystkim na stosowanie uprawnień do użytkowników anonimowych jest ustawiona wartość Nie zdefiniowano w systemie Windows Server 2003. Domyślnie system Windows Server 2003 nie zawiera tokenu Dostęp anonimowy w grupie Wszyscy.

    2. Przykład problemów
       
       ze zgodnością Następująca wartość w polu

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 przerywa tworzenie zaufania między systemami Windows Server 2003 i Windows NT 4.0, gdy domeną systemu Windows Server 2003 jest domena konta, a domeną systemu Windows NT 4.0 jest domena zasobu. Oznacza to, że domena konta jest zaufana w systemie Windows NT 4.0, a domena zasobu jest zaufana po stronie systemu Windows Server 2003. To zachowanie występuje, ponieważ proces uruchamiania zaufania po początkowym połączeniu anonimowym to ACL z tokenem Wszyscy, który zawiera anonimowy identyfikator SID w systemie Windows NT 4.0.

    3. Powody, dla których należy zmodyfikować to ustawienie
       
       Wartość musi być ustawiona na 0x1 lub ustawiona przy użyciu obiektu zasad grupy w użytkowniku OU kontrolera domeny: Dostęp sieciowy: Zezwalaj wszystkim na stosowanie uprawnień do użytkowników anonimowych — włączono, aby możliwe było tworzenie zaufania.
       
       Uwaga Większość innych ustawień zabezpieczeń idzie w górę, a nie w dół do 0x0 w stanie najbardziej zabezpieczonym. Bezpieczniejszym rozwiązaniem byłoby zmiana rejestru na emulatorze podstawowego kontrolera domeny zamiast na wszystkich kontrolerach domeny. Jeśli rola emulatora podstawowego kontrolera domeny zostanie z jakiegoś powodu przeniesiona, rejestr musi zostać zaktualizowany na nowym serwerze.
       
       Po ustawieniu tej wartości wymagane jest ponowne uruchomienie komputera.

    4. Ścieżka rejestru

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

15. Uwierzytelnianie NTLMv2

    1. Zabezpieczenia
       
       sesji Zabezpieczenia sesji określają minimalne standardy zabezpieczeń dla sesji klienta i serwera. W dodatku Microsoft Management Console zasady grupy Editor warto sprawdzić następujące ustawienia zasad zabezpieczeń:

       • Ustawienia komputera\Ustawienia systemu Windows\Ustawienia zabezpieczeń\Zasady lokalne\Opcje zabezpieczeń

       • Zabezpieczenia sieci: minimalne zabezpieczenia sesji dla serwerów SSP opartych na NTLM (w tym bezpiecznych serwerów RPC)

       • Zabezpieczenia sieci: minimalne zabezpieczenia sesji dla klientów SSP opartych na NTLM (w tym bezpiecznych klientów RPC)

       Opcje dla tych ustawień są następujące:

       • Wymaganie integralności wiadomości

       • Wymaganie poufności wiadomości

       • Wymaganie zabezpieczeń sesji NTLM w wersji 2

       • Wymaganie szyfrowania 128-bitowego

       Ustawieniem domyślnym sprzed systemu Windows 7 jest Brak wymagań. Począwszy od systemu Windows 7 domyślnie zmieniono na Wymagaj szyfrowania 128-bitowego w celu zwiększenia bezpieczeństwa. Z tym ustawieniem domyślnym starsze urządzenia, które nie obsługują szyfrowania 128-bitowego, nie będą mogły nawiązać połączenia.
       
       Te zasady określają minimalne standardy zabezpieczeń dla sesji komunikacji między aplikacjami na serwerze klienta.
       
       Należy pamiętać, że mimo że opisano je jako prawidłowe ustawienia, flagi wymagające integralności i poufności wiadomości nie są używane po ustaleniu zabezpieczeń sesji NTLM.
       
       W przeszłości system Windows NT obsługiwał następujące dwa warianty uwierzytelniania za pomocą wyzwań/odpowiedzi dla logowania do sieci:

       • Wyzwanie/odpowiedź LM

       • NTLM wersja 1 wyzwanie/odpowiedź

       LM umożliwia współdziałanie z zainstalowaną bazą klientów i serwerów. Usługa NTLM zapewnia ulepszone zabezpieczenia połączeń między klientami i serwerami.
       
       Odpowiadające im klucze rejestru są następujące:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

    2. Ryzykowne konfiguracje
       
       To ustawienie określa sposób obsługi sesji sieciowych zabezpieczonych przy użyciu usługi NTLM. Dotyczy to na przykład sesji opartych na RPC uwierzytelnionych przy użyciu funkcji NTLM. Istnieją następujące zagrożenia:

       • Używanie starszych metod uwierzytelniania niż NTLMv2 ułatwia atakowanie komunikacji ze względu na prostsze metody skrótów.

       • Używanie kluczy szyfrowania mniejszych niż 128-bitowe umożliwia napastnikom przerwanie komunikacji przy użyciu ataków siłowych.

Synchronizacja czasu

Synchronizacja czasu nie powiodła się. Czas jest wyłączony o ponad 30 minut na komputerze, którego dotyczy problem. Upewnij się, że zegar komputera klienckiego jest zsynchronizowany z zegarem kontrolera domeny.

Obejście problemu z podpisywaniem SMB

Zalecamy zainstalowanie dodatku Service Pack 6a (SP6a) na komputerach klienckich z systemem Windows NT 4.0 współdziałania w domenie opartej na systemie Windows Server 2003. Klienci z systemem Windows 98 Second Edition, klienci z systemem Windows 98 i klienci z systemem Windows 95 muszą uruchamiać klienta usług katalogowych w celu wykonywania operacji NTLMv2. Jeśli klienci z systemem Windows NT 4.0 nie mają zainstalowanego systemu Windows NT 4.0 z dodatkiem SP6 lub jeśli klienci z systemem Windows 95, klienci z systemem Windows 98 i klienci z systemem Windows 98SE nie mają zainstalowanego klienta usług katalogowych, wyłącz logowanie SMB w ustawieniu zasad domyślnego kontrolera domeny w OU kontrolera domeny, a następnie połącz te zasady ze wszystkimi użytkownikami, którzy hostują kontrolery domeny.

Klient usług katalogowych dla systemów Windows 98 Second Edition, Windows 98 i Windows 95 wykona podpisywanie SMB za pomocą serwerów systemu Windows 2003 w ramach uwierzytelniania NTLM, ale nie w ramach uwierzytelniania NTLMv2. Ponadto serwery systemu Windows 2000 nie będą odpowiadać na żądania podpisywania SMB od tych klientów.

Mimo że nie jest to zalecane, możesz zapobiec wymaganiu podpisywania SMB na wszystkich kontrolerach domeny, które uruchamiają system Windows Server 2003 w domenie. Aby skonfigurować to ustawienie zabezpieczeń, wykonaj następujące czynności:

1. Otwórz domyślne zasady kontrolera domeny.

2. Otwórz folder Konfiguracja komputera\Ustawienia systemu Windows\Ustawienia zabezpieczeń\Zasady lokalne\Opcje zabezpieczeń.

3. Znajdź i kliknij serwer sieciowy firmy Microsoft: Ustawienie zasad cyfrowego podpisywania komunikacji (zawsze), a następnie kliknij pozycję Wyłączone.

Ważne Ta sekcja, metoda lub zadanie zawiera kroki umożliwiające modyfikowanie rejestru. Niepoprawne zmodyfikowanie rejestru może jednak spowodować poważne problemy. Dlatego należy uważnie wykonywać poniższe czynności. Aby uzyskać dodatkową ochronę, utwórz kopię zapasową rejestru przed jego modyfikacją. Następnie możesz przywrócić rejestr, jeśli wystąpi problem. Aby uzyskać więcej informacji na temat tworzenia kopii zapasowej rejestru i przywracania go, kliknij następujący numer artykułu, aby wyświetlić ten artykuł w bazie wiedzy Microsoft Knowledge Base:

322756 Jak wykonać kopię zapasową rejestru i przywrócić go w systemie Windows Alternatywnie wyłącz logowanie SMB na serwerze, modyfikując rejestr. W tym celu wykonaj następujące czynności:

1. Kliknij przycisk Start, kliknij polecenie Uruchom, wpisz polecenie regedit, a następnie kliknij przycisk OK.

2. Znajdź i kliknij następujący podklucz:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

3. Kliknij wpis enablesecuritysignature .

4. W menu Edycja kliknij polecenie Modyfikuj.

5. W polu Dane wartości wpisz wartość 0, a następnie kliknij przycisk OK.

6. Zamknij Edytor rejestru.

7. Uruchom ponownie komputer lub zatrzymaj, a następnie uruchom ponownie usługę Serwer. W tym celu wpisz następujące polecenia w wierszu polecenia, a następnie naciśnij klawisz Enter po wpisaniu każdego polecenia:
   net stop server
   net start server

Uwaga Odpowiedni klucz na komputerze klienckim znajduje się w następującym podkluczu rejestru:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters Poniżej wymieniono przetłumaczone numery kodów błędów na kody stanu i dosłownie wymienione wcześniej komunikaty o błędach:

Aby uzyskać więcej informacji, kliknij następujące numery artykułów, aby wyświetlić artykuły z bazy wiedzy Microsoft Knowledge Base:

324802 Jak skonfigurować zasady grupy w celu ustawiania zabezpieczeń usług systemowych w systemie Windows Server 2003

816585 Jak stosować wstępnie zdefiniowane szablony zabezpieczeń w systemie Windows Server 2003