Problemy z klientami, usługami i programami mogą wystąpić, jeśli zmienisz ustawienia zabezpieczeń i przypisane prawa użytkowników

Podsumowanie

Ustawienia zabezpieczeń i przypisania praw użytkowników można zmieniać w zasadach lokalnych i zasadach grupy, aby zwiększyć bezpieczeństwo na kontrolerach domeny i komputerach członkowskich. Jednak wadą zwiększonego bezpieczeństwa jest wprowadzenie niezgodności z klientami, usługami i programami.

W tym artykule opisano niezgodności, które mogą wystąpić na komputerach klienckich z systemem Windows XP lub starszą wersją systemu Windows po zmianie określonych ustawień zabezpieczeń i przypisanych praw użytkownika w domenie systemu Windows Server 2003 lub starszej domenie systemu Windows Server.

Aby uzyskać informacje dotyczące zasady grupy dla systemów Windows 7, Windows Server 2008 R2 i Windows Server 2008, zobacz następujące artykuły:

• W przypadku systemu Windows 7 zobacz Zarządzanie zasadami grupy dla informatyków
• W przypadku systemów Windows 7 i Windows Server 2008 R2 zobacz Co nowego w zasady grupy

Uwaga: pozostała zawartość tego artykułu dotyczy systemów Windows XP, Windows Server 2003 i wcześniejszych wersji systemu Windows.

Windows XP

Aby zwiększyć świadomość dotyczącą nieprawidłowo skonfigurowanych ustawień zabezpieczeń, zmień ustawienia zabezpieczeń za pomocą narzędzia Edytor obiektów zasady grupy. Podczas korzystania z Edytora obiektów zasady grupy przypisywanie praw użytkownikom jest rozszerzone w następujących systemach operacyjnych:

• Windows XP Professional Service Pack 2 (SP2)
• Windows Server 2003 z dodatkiem Service Pack 1 (SP1)

Funkcją rozszerzoną jest okno dialogowe zawierające łącze do tego artykułu. To okno dialogowe jest wyświetlane po zmianie ustawienia zabezpieczeń lub przypisania praw użytkownika na takie, które zapewnia mniejszą zgodność i jest bardziej restrykcyjne. Bezpośrednia zmiana ustawienia zabezpieczeń lub przypisania praw użytkownika przy użyciu rejestru lub szablonów zabezpieczeń daje taki sam efekt jak zmiana ustawienia w Edytorze obiektów zasady grupy. Jednak okno dialogowe zawierające link do tego artykułu nie jest wyświetlane.

Ten artykuł zawiera przykłady klientów, programów i operacji, na które wpływają określone ustawienia zabezpieczeń lub przypisane prawa użytkownika. Przykłady nie są jednak miarodajne dla wszystkich systemów operacyjnych firmy Microsoft, wszystkich systemów operacyjnych innych firm ani wszystkich wersji programów, których to dotyczy. Ten artykuł nie zawiera wszystkich ustawień zabezpieczeń i przypisanych praw użytkowników.

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

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

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

• Wykonywane operacje, takie jak:

  • Uwierzytelnianie logowania komputera i użytkownika
  • Resetowanie haseł przez użytkowników, komputery i administratorów
  • Przeglądanie
  • Ustawianie uprawnień dla systemu plików, dla folderów udostępnionych, dla rejestru i dla zasobów usługi Active Directory za pomocą edytora ACL we wszystkich klienckich systemach operacyjnych we wszystkich domenach kont lub zasobów ze wszystkich klienckich systemów operacyjnych ze wszystkich domen kont i zasobów
  • Drukowanie z kont administracyjnych i nieadministracyjnych

Windows Server 2003 SP1

Ostrzeżenia w pliku Gpedit.msc

Aby uświadomić klientom, że edytują prawo użytkownika lub opcję zabezpieczeń, które mogły mieć negatywny wpływ na ich sieć, do gpedit.msc dodano dwa mechanizmy ostrzegania. Gdy administratorzy edytują prawo użytkownika, które może mieć negatywny wpływ na całe przedsiębiorstwo, zobaczą nową ikonę przypominającą znak ustąpienia podmiotu. Otrzymają oni także komunikat ostrzegawczy z linkiem do artykułu z bazy wiedzy Baza wiedzy Microsoft Knowledge Base 823659. Treść tej wiadomości jest następująca:

Modyfikowanie tego ustawienia może mieć wpływ na zgodność z klientami, usługami i aplikacjami. Aby uzyskać więcej informacji, zobacz <modyfikowanie> praw użytkownika lub opcji zabezpieczeń (Q823659) Jeśli przekierowano Cię do tego artykułu z bazy wiedzy Knowledge Base z linku w Gpedit.msc, upewnij się, że przeczytałeś i zrozumiałeś podane wyjaśnienie oraz możliwe skutki zmiany tego ustawienia. Poniżej wymieniono prawa użytkownika zawierające tekst ostrzeżenia:

• Uzyskaj dostęp do tego komputera z sieci
• Logowanie lokalne
• Pomijanie sprawdzania przechodzenia
• Włączanie zaufanego delegowania dla komputerów i użytkowników

Poniżej wymieniono opcje zabezpieczeń z ostrzeżeniem i komunikatem podręcznym:

• Członek domeny: szyfruj cyfrowo lub podpisuj dane bezpiecznego kanału (zawsze)
• Członek domeny: Wymagany silny klucz sesji (system Windows 2000 lub nowsza)
• Kontroler domeny: wymagania dotyczące podpisywania serwera LDAP
• Serwer sieci firmy Microsoft: podpisuj cyfrowo komunikację (zawsze)
• Dostęp do sieci: umożliwia anonimową translację identyfikatorów SID / nazw
• Dostęp do sieci: Nie zezwalaj na anonimowe wyliczanie kont SAM i udziałów
• Bezpieczeństwo sieci: Poziom uwierzytelniania LAN Manager
• Inspekcja: Natychmiast zamknij system, jeśli nie można zarejestrować inspekcji zabezpieczeń
• Dostęp do sieci: wymagania dotyczące podpisywania klienta LDAP

Więcej informacji

W poniższych sekcjach opisano niezgodności, które mogą wystąpić w przypadku zmiany określonych ustawień w domenach systemów Windows NT 4.0, Windows 2000 i Windows Server 2003.

Uprawnienia użytkownika

Poniższa lista zawiera opis praw użytkownika, ustawienia konfiguracji, które mogą powodować problemy, powody, dla których należy stosować te prawa użytkownika i dlaczego może być konieczne usunięcie prawa użytkownika, a także przykłady problemów ze zgodnością, które mogą wystąpić podczas konfigurowania prawa użytkownika.

1. Uzyskaj dostęp do tego komputera z sieci

   1. Tło

      Możliwość interakcji ze zdalnymi komputerami z systemem Windows wymaga prawa użytkownika Uzyskaj dostęp do tego komputera z sieci. Przykłady takich operacji sieciowych obejmują:

      • Replikacja usługi Active Directory między kontrolerami domeny we wspólnej domenie lub lesie
      • Żądania uwierzytelnienia od użytkowników i komputerów do kontrolerów domeny
      • 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ą prawo użytkownika Dostęp do tego komputera z sieci w wyniku jawnego lub pośredniego dodania do grupy zabezpieczeń, której to prawo użytkownika zostało przyznane, albo usunięcia z tej grupy. 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 może zostać dodane niejawnie przez system operacyjny do obliczeniowej grupy zabezpieczeń, takiej jak Użytkownicy domeny, Użytkownicy uwierzytelnieni lub Kontrolery domeny przedsiębiorstwa.

      Domyślnie konta użytkowników i konta komputerów otrzymują dostęp do tego komputera z prawa użytkownika sieciowego, gdy obliczone grupy, takie jak Wszyscy lub najlepiej Użytkownicy uwierzytelnieni, a w przypadku kontrolerów domeny przedsiębiorstwa grupa Kontrolery domeny przedsiębiorstwa, są zdefiniowane w domyślnym zasadach grupy kontrolerów domeny.

   2. Ryzykowne konfiguracje

      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Usuwanie grupy zabezpieczeń Kontrolery domeny przedsiębiorstwa przypisanej do tego prawa użytkownika
      • Usunięcie grupy Użytkownicy uwierzytelnieni lub grupy jawnej, która zapewnia użytkownikom, komputerom i kontom usług prawo do łączenia się z komputerami za pośrednictwem sieci
      • Usuwanie wszystkich użytkowników i komputerów z tego prawa użytkownika

   3. Powody, dla których należy przyznać temu prawu użytkownika

      • Przyznanie grupie Kontrolery domeny przedsiębiorstwa prawa Uzyskaj dostęp do tego komputera z sieci spełnia wymagania uwierzytelniania, które musi spełniać replikacja usługi Active Directory, aby replikacja mogła się odbywać 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 mogli uzyskiwać dostęp do poczty przy użyciu wczesnych wersji programu Microsoft Outlook Web Access (OWA).

   4. Powody odebrania temu prawu 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. To prawo użytkownika jest na przykład wymagane, aby użytkownik mógł łączyć się z udostępnionymi drukarkami i folderami. Jeśli to prawo użytkownika zostanie udzielone grupie Wszyscy i jeśli niektóre foldery udostępnione mają skonfigurowane zarówno uprawnienia udziału, jak i uprawnienia systemu NTFS, dzięki czemu ta sama grupa ma dostęp do odczytu, każdy może wyświetlać pliki w tych folderach udostępnionych. Jest to jednak mało prawdopodobne w przypadku świeżych instalacji systemu Windows Server 2003, ponieważ domyślny udział i uprawnienia NTFS w systemie Windows Server 2003 nie obejmują grupy Wszyscy. Dla systemów uaktualnionych z systemu Microsoft Windows NT 4.0 lub Windows 2000 ten poziom ryzyka może być wyższy, ponieważ domyślny udział i uprawnienia systemu plików dla tych systemów operacyjnych nie są tak restrykcyjne, jak domyślne uprawnienia w systemie Windows Server 2003.
      • Nie ma żadnego ważnego powodu, aby usunąć grupę kontrolerów domeny przedsiębiorstwa z tego prawa użytkownika.
      • Grupa Wszyscy jest na ogół usuwana na rzecz grupy Użytkownicy uwierzytelnieni. Jeśli grupa Wszyscy zostanie usunięta, należy przyznać to uprawnienie grupie Użytkownicy uwierzytelnieni.
      • W domenach systemu Windows NT 4.0 uaktualnionych do systemu Windows 2000 nie jest jawnie udzielane prawo Dostęp do tego komputera z sieci dla grup Wszyscy, Użytkownicy uwierzytelnieni ani Kontrolery domeny przedsiębiorstwa. Z tego powodu po usunięciu grupy Wszyscy z zasad domeny systemu Windows NT 4.0 replikacja usługi Active Directory zakończy się niepowodzeniem i wyświetleniem komunikatu o błędzie "Odmowa dostępu" po uaktualnieniu do systemu Windows 2000. Winnt32.exe w Windows Server 2003 pozwala uniknąć tej błędnej konfiguracji, przyznając grupie Enterprise Domain Controllers to user right when upgrade Windows NT 4.0 primary domain controllers (PDC). Udziel grupie kontrolerów domeny przedsiębiorstwa tego prawa użytkownika, jeśli nie występuje ono 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 powodu błędów "Odmowa dostępu" zgłoszonych przez narzędzia monitorujące, takie jak REPLMON i REPADMIN, lub zdarzeń 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 na komputerach klienckich w sieci zdalnej zakończy się niepowodzeniem, chyba że to prawo zostanie udzielone użytkownikowi lub grupie zabezpieczeń, do której należy użytkownik.

      • Wszystkie sieciowe systemy operacyjne firmy Microsoft: Uwierzytelnianie konta ze zdalnych klientów sieciowych zakończy się niepowodzeniem, chyba że kontu lub grupie zabezpieczeń, do której należy konto, udzielono tego prawa 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 wszelkim kontom logowanie się do domeny lub uzyskiwanie dostępu do zasobów sieciowych. Jeśli grupy obliczeniowe, takie jak kontrolery domeny przedsiębiorstwa, Wszyscy lub Użytkownicy uwierzytelnieni, zostaną usunięte, należy jawnie udzielić temu użytkownikowi praw dostępu do komputerów zdalnych za pośrednictwem sieci do kont lub grup zabezpieczeń, których członkiem jest konto. Ten scenariusz dotyczy wszystkich kont użytkowników, wszystkich kont komputerów i wszystkich kont usług.

      • Wszystkie sieciowe systemy operacyjne firmy Microsoft: Lokalne konto administratora używa "pustego" hasła. Łączność sieciowa z pustymi hasłami nie jest dozwolona w przypadku kont administratorów w środowisku domeny. W takiej konfiguracji możesz spodziewać się otrzymania komunikatu o błędzie "Odmowa dostępu".

2. Zezwalaj na logowanie lokalne

   1. Tło

      Użytkownicy logujący się do konsoli komputera z systemem Windows (za pomocą skrótu klawiaturowego CTRL+ALT+DELETE) i konta, którzy próbują uruchomić usługę, muszą mieć uprawnienia logowania lokalnego na komputerze hostującym. Przykładami operacji logowania lokalnego są administratorzy, którzy logują się do konsol komputerów członkowskich lub kontrolerów domeny w całym przedsiębiorstwie oraz użytkownicy domeny, którzy logują się do komputerów członkowskich, aby uzyskać dostęp do swoich pulpitów przy użyciu kont nieuprzywilejowanych. Użytkownicy korzystający z usługi pulpitu zdalnego lub usług terminalowych muszą mieć prawo użytkownika Zezwól na logowanie lokalne na komputerach docelowych z systemem Windows 2000 lub Windows XP, ponieważ te tryby logowania są uznawane za lokalne dla komputera hostującego. Użytkownicy logujący się do serwera z włączonym serwerem terminali, którzy nie mają tego prawa użytkownika, mogą nadal rozpoczynać zdalną sesję interaktywną w domenach systemu Windows Server 2003, jeśli mają prawo użytkownika Zezwalaj na logowanie za pośrednictwem usług terminalowych.

   2. Ryzykowne konfiguracje

      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Usunięcie administracyjnych grup zabezpieczeń, w tym operatorów kont, operatorów kopii zapasowych, operatorów drukowania lub operatorów serwera oraz wbudowanej grupy administratorów, z domyślnych zasad kontrolera domeny.
      • Usuwanie kont usług używanych przez składniki i programy na komputerach członkowskich i kontrolerach domeny w domenie z domyślnych zasad kontrolera domeny.
      • Usuwanie użytkowników lub grup zabezpieczeń logujących się do konsoli komputerów członkowskich w domenie.
      • Usuwanie kont usługi zdefiniowanych w lokalnej bazie danych menedżera kont zabezpieczeń (SAM) komputerów członków lub komputerów grupy roboczej.
      • Usuwanie niewbudowanych kont administracyjnych, które są uwierzytelniane za pośrednictwem usług terminalowych uruchomionych na kontrolerze domeny.
      • Dodanie wszystkich kont użytkowników w domenie jawnie lub niejawnie za pośrednictwem grupy Wszyscy do prawa odmów logowania lokalnego. Ta konfiguracja uniemożliwi użytkownikom logowanie się do jakiegokolwiek komputera członkowskiego lub kontrolera domeny w domenie.

   3. Powody, dla których należy przyznać temu prawu użytkownika

      • Użytkownicy muszą mieć prawo Zezwól na logowanie się lokalnie, aby uzyskać dostęp do konsoli lub pulpitu komputera grupy roboczej, komputera członkowskiego lub kontrolera domeny.
      • To prawo użytkownika musi być uprawnione do logowania się do sesji usług terminalowych uruchomionej na komputerze członkowskim z systemem Windows 2000 lub kontrolerze domeny.

   4. Powody odebrania temu prawu użytkownika

      • Nieograniczenie dostępu konsoli do legalnych kont użytkowników może spowodować, że nieautoryzowani użytkownicy pobiorą i uruchomią złośliwy kod w celu zmiany swoich uprawnień.
      • Usunięcie prawa użytkownika Zezwalaj na logowanie lokalne uniemożliwia nieautoryzowane logowania na konsolach komputerów, takich jak kontrolery domeny lub serwery aplikacji.
      • Usunięcie tego prawa logowania uniemożliwia kontom spoza domeny logowanie się na konsoli komputerów członkowskich w domenie.

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

      • Serwery terminali systemu Windows 2000: Prawo użytkownika Zezwalaj na logowanie lokalne jest wymagane, aby użytkownicy mogli logować się do serwerów terminali systemu Windows 2000.
      • Windows NT 4.0, Windows 2000, Windows XP lub Windows Server 2003: To konto użytkownika musi mieć przyznane prawo 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 wersje: Na komputerach z systemem Windows NT 4.0 lub nowszym, jeśli dodasz prawo użytkownika Zezwalaj na logowanie lokalne, ale niejawnie lub jawnie przyznasz również prawo Odmów logowania lokalnego, konta nie będą mogły logować się do konsoli kontrolerów domeny.

3. Pomijanie sprawdzania przechodzenia

   1. Tło

      Prawo użytkownika Pomijaj sprawdzanie przechodzenia umożliwia przeglądanie folderów w systemie plików NTFS lub w rejestrze bez sprawdzania specjalnych uprawnień dostępu dla folderu Przechodzenie. Prawo użytkownika Pomijaj sprawdzanie przechodzenia nie pozwala użytkownikowi na wyświetlanie zawartości folderu. Pozwala użytkownikowi na poruszanie się tylko po jego folderach.

   2. Ryzykowne konfiguracje

      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Usuwanie kont nieadministracyjnych, logujących się na komputerach usług terminalowych z systemem Windows 2000 lub usługach terminalowych 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óre domyślnie mają to prawo użytkownika. Systemy operacyjne Windows, a także wiele innych programów, są projektowane z założeniem, że każdy, kto może legalnie uzyskać dostęp do komputera, będzie miał prawo użytkownika do pomijania przechodzenia przez komputer. Dlatego usunięcie grupy Wszyscy z listy podmiotów zabezpieczeń z tym prawem użytkownika może prowadzić do niestabilności systemu operacyjnego lub awarii programu. Lepiej pozostawić to ustawienie jako domyślne.

   3. Powody, dla których należy przyznać temu prawu użytkownika

      Domyślnym ustawieniem prawa użytkownika Pomijaj sprawdzanie przechodzenia jest zezwolenie każdej osobie na pomijanie sprawdzania przechodzenia. W przypadku doświadczonych administratorów systemu Windows jest to normalne zachowanie, dlatego konfigurują oni listy kontroli dostępu do systemu plików (SACL). Jedynym scenariuszem, w którym konfiguracja domyślna może prowadzić do wpadki, jest sytuacja, w której administrator konfigurujący uprawnienia nie rozumie zachowania użytkownika i oczekuje, że użytkownicy, którzy nie mogą uzyskać dostępu do folderu nadrzędnego, nie będą mogli uzyskać dostępu do zawartości żadnych folderów podrzędnych.

   4. Powody odebrania temu prawu użytkownika

      Aby uniemożliwić dostęp do plików lub folderów w systemie plików, organizacje bardzo dbające o bezpieczeństwo mogą pokusić się o usunięcie grupy Wszyscy, a nawet grupy Użytkownicy, z listy grup, dla których jest dozwolone sprawdzanie użytkowników pomijania przechodzenia przez użytkowników.

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

      • Windows 2000, Windows Server 2003: Jeśli na komputerach z systemem Windows 2000 lub Windows Server 2003 prawo użytkownika sprawdzania pomijania przejścia zostanie usunięte lub będzie niewłaściwie skonfigurowane, 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 będą rejestrować zdarzenia 1000 i 1202. Nie będzie można zastosować zasad komputera i zasad użytkownika, gdy wymagane uprawnienia systemu plików zostaną usunięte z drzewa SYSVOL, jeśli prawo użytkownika pomijania sprawdzania przechodzenia zostanie usunięte lub zostanie źle skonfigurowane.

         

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

      • Windows 2000: Użytkownikom bez uprawnień administratora, którzy logują się do serwera terminali systemu Windows 2000, może zostać wyświetlony następujący komunikat o błędzie:

        Uwaga

        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 komputerów z systemem Windows NT 4.0, Windows 2000, Windows XP lub Windows Server 2003 mogą nie być w stanie uzyskać dostępu do folderów udostępnionych lub plików w folderach udostępnionych, a jeśli nie zostanie im przyznane prawo użytkownika Pomijanie sprawdzania przechodzenia przez użytkownika, mogą otrzymywać komunikaty o błędzie "Odmowa dostępu".

         

      • Windows NT 4.0: Na komputerach z systemem Windows NT 4.0 usunięcie prawa użytkownika Pomijanie sprawdzania przechodzenia spowoduje usuwanie strumieni plików z kopii plików. Usunięcie tego prawa użytkownika powoduje skopiowanie pliku z klienta systemu Windows lub komputera Macintosh do kontrolera domeny systemu Windows NT 4.0, na którym są uruchomione Usługi dla komputerów Macintosh, powoduje utratę docelowego strumienia plików, a plik jest 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 i wyświetleniem komunikatu o błędzie "Odmowa dostępu", jeśli grupie Użytkownicy uwierzytelnieni nie zostanie przyznane prawo użytkownika Pomijanie sprawdzania przechodzenia.

      • Outlook Web Access: Użytkownicy bez uprawnień administratora nie będą mogli zalogować się do programu Microsoft Outlook Web Access, a jeśli nie zostaną im przyznane prawo użytkownika Pomijaj sprawdzanie przechodzenia przez kanał, zostanie im wyświetlony komunikat o błędzie "Odmowa dostępu".

Ustawienia zabezpieczeń

Poniższa lista identyfikuje ustawienie zabezpieczeń, a lista zagnieżdżona zawiera opis ustawienia zabezpieczeń, ustawienia konfiguracji, które mogą powodować problemy, opis powodów stosowania ustawienia zabezpieczeń, a także powody, dla których może być konieczne usunięcie ustawienia zabezpieczeń. Lista zagnieżdżona zawiera następnie symboliczną nazwę ustawienia zabezpieczeń i ścieżkę rejestru ustawienia zabezpieczeń. Podano też przykłady problemów ze zgodnością, które mogą wystąpić podczas konfigurowania ustawienia zabezpieczeń.

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

   1. Tło

      • Ustawienie Inspekcja: Zamknij system natychmiast, jeśli nie można zarejestrować inspekcji zabezpieczeń, określa, czy system ma zostać zamknięty, jeśli nie można zarejestrować zdarzeń zabezpieczeń. To ustawienie jest wymagane do oceny C2 programu Trusted Computer Security Evaluation Criteria (TCSEC) oraz do oceny Common Criteria for Information Technology Security Evaluation Evaluation w celu zapobiegania zdarzeniom podlegającym inspekcji, jeśli system inspekcji nie może ich zarejestrować. Jeśli system inspekcji ulegnie awarii, 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ą być niedostępne do przejrzenia po wystąpieniu zdarzenia zabezpieczeń.

   2. Ryzykowna konfiguracja

      Poniższe ustawienie konfiguracji jest szkodliwe: Inspekcja: Zamknij system natychmiast, jeśli nie można rejestrować inspekcji zabezpieczeń, jest włączone, a rozmiar dziennika zdarzeń zabezpieczeń jest ograniczony przez opcję Nie zastępuj zdarzeń (wyczyść dziennik ręcznie), opcję Zastąp zdarzenia w razie potrzeby lub opcję Zastąp zdarzenia starsze niż liczba dni w podglądzie zdarzeń. W sekcji "Przykłady problemów ze zgodnością" znajdują się informacje o konkretnych zagrożeniach dla komputerów z oryginalną wersją systemu Windows 2000, Windows 2000 z dodatkiem Service Pack 1 (SP1), Windows 2000 SP2 lub Windows 2000 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ą być niedostępne do przejrzenia po wystąpieniu zdarzenia zabezpieczeń.

   4. Powody wyłączenia tego ustawienia

      • Włączanie funkcji Inspekcja: Natychmiast zamknij system, jeśli nie można zarejestrować inspekcji zabezpieczeń, zatrzymuje system, jeśli z jakiegokolwiek powodu nie można zarejestrować audytu zabezpieczeń. Z reguły nie można zarejestrować zdarzenia, gdy dziennik inspekcji zabezpieczeń jest pełny i gdy określoną metodą przechowywania jest opcja Nie zastępuj zdarzeń (ręcznie wyczyść dziennik) lub opcja Zastąp zdarzenia starsze niż liczba dni.
      • Obciążenie administracyjne związane z włączeniem ustawienia Inspekcja: Zamknij system natychmiast, jeśli nie można rejestrować inspekcji zabezpieczeń może być bardzo wysokie, zwłaszcza jeśli włączysz również opcję Nie zastępuj zdarzeń (wyczyść dziennik ręcznie) dla dziennika zabezpieczeń. To ustawienie zapewnia indywidualną odpowiedzialność za działania operatora. Administrator mógł na przykład zresetować uprawnienia wszystkich użytkowników, komputerów i wszystkich grup w jednostce organizacyjnej, w której włączono inspekcję za pomocą wbudowanego konta administratora lub innego udostępnionego konta, a następnie odmówić zresetowania tych uprawnień. Włączenie tego ustawienia zmniejsza jednak niezawodność systemu, ponieważ serwer może zostać zmuszony do zamknięcia systemu wskutek przeciążenia go zdarzeniami logowania i innymi zdarzeniami zabezpieczeń zapisywanymi w dzienniku zabezpieczeń. Ponadto zamknięcie nie jest bezpieczne, co może spowodować nieodwracalne uszkodzenia systemu operacyjnego, programów lub danych. O ile system plików NTFS gwarantuje zachowanie integralności systemu plików podczas awaryjnego zamykania systemu, o tyle nie może zagwarantować, że każdy plik danych dla każdego programu będzie nadal w użytecznej postaci 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 dodatkiem SP3 dla systemu Windows Server mogą przestać rejestrować zdarzenia przed osiągnięciem rozmiaru określonego w opcji Maksymalny rozmiar dziennika zabezpieczeń. Błąd ten został wyeliminowany w systemie Windows 2000 z dodatkiem Service Pack 4 (SP4). Zanim włączysz to ustawienie, upewnij się, że na kontrolerach domeny systemu Windows 2000 jest 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ą zostać samoistnie ponownie uruchomione, jeśli zostanie włączona opcja Inspekcja: Zamknij system natychmiast, jeśli nie można rejestrować inspekcji zabezpieczeń, dziennik zabezpieczeń jest pełny i nie można zastąpić istniejącego wpisu w dzienniku zdarzeń. Podczas ponownego uruchamiania komputera jest wyświetlany następujący komunikat o błędzie zatrzymania:

        Uwaga

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

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

      • Klient sieciowy Microsoft dla systemów MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Użytkownicy bez uprawnień administratora próbujący zalogować się do domeny otrzymają następujący komunikat o błędzie:

        Uwaga

        Twoje konto jest skonfigurowane w taki sposób, aby uniemożliwić Ci korzystanie z tego komputera. Spróbuj użyć innego komputera.

      • Windows 2000: Na komputerach z systemem Windows 2000 użytkownicy bez uprawnień administratora nie będą mogli logować się do serwerów dostępu zdalnego i otrzymają komunikat o błędzie podobny do następującego:

        Uwaga

        Nieznany użytkownik lub nieprawidłowe hasło

      • Windows 2000: Na kontrolerach domeny z systemem Windows 2000 usługa wiadomości międzylokacyjnych (Ismserv.exe) zostanie zatrzymana i nie można jej ponownie uruchomić. DCDIAG zgłosi błąd jako "usługi testowe ISMserv zakończyły się niepowodzeniem", a identyfikator zdarzenia 1083 zostanie zarejestrowany w dzienniku zdarzeń.

      • Windows 2000: Na kontrolerach domeny z systemem Windows 2000 replikacja usługi Active Directory zakończy się niepowodzeniem, 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 niebędące administratorami nie będą mogły uzyskiwać dostępu do swojej poczty za pośrednictwem programów Microsoft Outlook i Microsoft Outlook Web Access i zostanie im wyświetlony błąd 503.

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

   1. Tło

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

      • Brak: Podpisywanie danych nie jest wymagane do powiązania z serwerem. Jeśli klient zażąda podpisania danych, serwer to obsługuje.
      • Wymagaj podpisywania: należy negocjować opcję podpisywania danych LDAP, chyba że jest używany protokół Transport Layer Security/Secure Socket Layer (TLS/SSL).
      • niezdefiniowane: To ustawienie nie jest włączone ani wyłączone.

   2. Ryzykowne konfiguracje

      Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

      • Włączanie opcji Wymagaj podpisywania w środowiskach, w których klienci nie obsługują podpisywania LDAP lub w których podpisywanie LDAP po stronie klienta nie jest włączone na 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 w których podpisywanie LDAP po stronie klienta 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 w których podpisywanie LDAP po stronie klienta nie jest włączone

   3. Powody włączenia tego ustawienia

      Niepodpisany ruch sieciowy jest podatny na ataki "man-in-the-middle", w których intruz przechwytuje pakiety między klientem a serwerem, modyfikuje pakiety, a następnie przesyła je do serwera. Gdy takie zachowanie występuje na serwerze LDAP, osoba atakująca może spowodować, że serwer będzie podejmować decyzje oparte na fałszywych zapytaniach od klienta LDAP. To ryzyko można obniżyć, wdrażając silne zabezpieczenia fizyczne w celu ochrony infrastruktury sieciowej. Tryb nagłówka uwierzytelniania zabezpieczeń protokołu internetowego (IPSec) pomaga zapobiegać atakom "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 nieobsługujący podpisywania LDAP nie będą mogli wykonywać zapytań LDAP na kontrolerach domeny i w wykazach globalnych, jeśli wynegocjowane jest uwierzytelnianie NTLM, a na kontrolerach domeny z systemem Windows 2000 nie zainstalowano odpowiednich dodatków Service Pack.
      • Ślady ruchu LDAP między klientami i serwerami w sieci będą szyfrowane. Utrudnia to analizowanie konwersacji LDAP.
      • Serwery z systemem Windows 2000 muszą mieć zainstalowany system Windows 2000 z dodatkiem Service Pack 3 (SP3) lub zainstalowany, gdy są administrowane za pomocą programów obsługujących podpisywanie LDAP uruchamianych z komputerów 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 będą działać i zostanie wyświetlony następujący komunikat o błędzie:

        Uwaga

        Ldap_simple_bind_s() failed: Wymagane silne uwierzytelnianie.

      • Windows 2000 z dodatkiem Service Pack 4, Windows XP, Windows Server 2003: Na komputerach klienckich z systemem Windows 2000 z dodatkiem SP4, Windows XP lub Windows Server 2003 niektóre narzędzia administracji usługi Active Directory nie będą działać poprawnie na kontrolerach domen z systemami w wersji systemu Windows 2000 wcześniejszej niż SP3, gdy negocjowane jest uwierzytelnianie NTLM.

         

      • Windows 2000 z dodatkiem Service Pack 4, Windows XP, Windows Server 2003: Na komputerach klienckich z systemem Windows 2000 z dodatkiem SP4, Windows XP lub Windows Server 2003 niektóre narzędzia administracji usługi Active Directory przeznaczone dla kontrolerów domeny z systemami w wersji systemu Windows 2000 starszych niż 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 to adres IP).

         

      • Windows 2000 z dodatkiem Service Pack 4, Windows XP, Windows Server 2003: Na komputerach klienckich z systemem Windows 2000 z dodatkiem SP4, Windows XP lub Windows Server 2003 niektóre narzędzia administracji usługi Active Directory przeznaczone dla kontrolerów domen z systemami Windows 2000 starszymi niż SP3 nie będą działać poprawnie.

         

3. Członek domeny: Wymagany silny klucz sesji (system Windows 2000 lub nowszy)

   1. Tło

      • Ustawienie Członek domeny: Wymagaj silnego klucza sesji (system Windows 2000 lub nowszy) określa, czy można ustanowić bezpieczny kanał za pomocą kontrolera domeny, który nie może szyfrować ruchu bezpiecznego kanału za pomocą silnego, 128-bitowego klucza sesji. Włączenie tego ustawienia uniemożliwia ustanowienie bezpiecznego kanału za pomocą dowolnego kontrolera domeny, który nie może szyfrować danych bezpiecznego kanału przy użyciu silnego klucza. Wyłączenie tego ustawienia zezwala na używanie 64-bitowych kluczy sesji.
      • Aby można było włączyć to ustawienie na stacji roboczej lub na serwerze, wszystkie kontrolery domeny w domenie, do której należy element, muszą mieć możliwość szyfrowania danych bezpiecznego kanału za pomocą silnego klucza 128-bitowego. Oznacza to, że na wszystkich takich kontrolerach domeny musi być zainstalowany system Windows 2000 lub nowszy.

   2. Ryzykowna konfiguracja

      Włączenie opcji Członek domeny: Wymagaj silnego klucza sesji (system Windows 2000 lub nowszy) jest szkodliwym ustawieniem konfiguracji.

   3. Powody włączenia tego ustawienia

      • Klucze sesji używane do ustanawiania komunikacji bezpiecznego kanału między komputerami członkowskimi a kontrolerami domeny są znacznie silniejsze w systemie Windows 2000 niż we wcześniejszych wersjach systemów operacyjnych firmy Microsoft.
      • Gdy jest to możliwe, warto korzystać z tych silniejszych kluczy sesji, aby chronić komunikację w bezpiecznych kanałach przed podsłuchiwaniem i atakami sieciowymi przejmującymi sesję. Podsłuchiwanie to forma złośliwego ataku, w której dane sieciowe są odczytywane lub zmieniane podczas przesyłania. Dane można modyfikować, ukrywając lub zmieniając nadawcę albo przekierowując go.

      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 uniemożliwia utworzenie zaufania między jakąkolwiek domeną opartą na systemie Windows NT 4.0 a jakąkolwiek domeną opartą na systemie Windows Server 2008 R2. Ponadto to ograniczenie blokuje członkostwo w domenie opartej na systemie Windows NT 4.0 komputerów z systemem Windows 7 lub Windows Server 2008 R2 i odwrotnie.

   4. Powody wyłączenia tego ustawienia

      Domena obejmuje komputery członkowskie z systemami operacyjnymi innymi niż Windows 2000, Windows XP lub Windows Server 2003.

   5. Nazwa symboliczna:

      Silny klucz

   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 systemów Windows NT 4.0 i Windows 2000 za pomocą NLTEST kończy się niepowodzeniem. Zostanie wyświetlony komunikat o błędzie "Odmowa dostępu":
      Relacja zaufania między domeną podstawową a domeną zaufaną nie powiodła się.

      Windows 7 i Server 2008 R2: W przypadku systemu Windows 7 i nowszych wersji oraz systemu Windows Server 2008 R2 i nowszych to ustawienie nie jest już honorowane, a silny klucz jest używany zawsze. Z tego powodu zaufania z domenami systemu Windows NT 4.0 przestają działać.

4. Członek domeny: szyfruj cyfrowo lub podpisuj dane bezpiecznego kanału (zawsze)

   1. Tło

      • Włączanie członka domeny: szyfrowanie lub podpisywanie cyfrowo danych bezpiecznego kanału (zawsze) uniemożliwia ustanowienie bezpiecznego kanału za pomocą dowolnego kontrolera domeny, który nie może podpisać ani zaszyfrować wszystkich danych bezpiecznego kanału. Aby chronić ruch uwierzytelniania przed atakami "man-in-the-middle", atakami typu "powtórki" i innymi rodzajami ataków sieciowych, komputery z systemem Windows tworzą za pośrednictwem usługi Net Logon kanał komunikacyjny, znany jako bezpieczny kanał, służący do uwierzytelniania kont komputerów. 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 (tzw. uwierzytelnianie przekazujące) umożliwia komputerowi z systemem Windows, który przyłączył się do domeny, dostęp do bazy danych kont użytkowników w swojej domenie oraz we wszystkich zaufanych domenach.
      • Aby włączyć opcję Członek domeny: Szyfruj cyfrowo lub podpisuj dane bezpiecznego kanału (zawsze) na komputerze członkowskim, wszystkie kontrolery domeny w domenie, do której należy element, muszą mieć możliwość podpisywania lub szyfrowania wszystkich danych bezpiecznego kanału. Oznacza to, że na wszystkich takich kontrolerach domeny musi być uruchomiony system Windows NT 4.0 z dodatkiem Service Pack 6a (SP6a) lub nowszym.
      • Włączanie ustawienia Członek domeny: Szyfruj cyfrowo lub podpisuj dane bezpiecznego kanału (zawsze) automatycznie włącza ustawienie Członek domeny: Szyfruj cyfrowo lub podpisuj dane bezpiecznego kanału (jeśli to możliwe).

   2. Ryzykowna konfiguracja

      Włączanie elementu członkowskiego domeny: Ustawienie szyfruj cyfrowo lub podpisuj dane bezpiecznego kanału (zawsze) w domenach, w których nie wszystkie kontrolery 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 "man-in-the-middle", w których intruz przechwytuje pakiety między serwerem a klientem, a następnie modyfikuje je przed przekazaniem do klienta. Gdy takie zachowanie występuje na serwerze LDAP (Lightweight Directory Access Protocol), intruz może spowodować, że klient będzie podejmować decyzje oparte na fałszywych rekordach z katalogu LDAP. Ryzyko wystąpienia takiego ataku można zmniejszyć w sieci firmowej poprzez wdrożenie silnych zabezpieczeń fizycznych w celu ochrony infrastruktury sieciowej. Ponadto zaimplementowanie trybu nagłówka uwierzytelniania zabezpieczeń protokołu internetowego (IPSec) może ułatwić zapobieganie atakom "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 i zewnętrznych obsługują szyfrowane bezpieczne kanały.
      • Nie wszystkie kontrolery domeny w domenie mają odpowiednie poziomy rewizji dodatku Service Pack, aby obsługiwać szyfrowane bezpieczne kanały.

   5. Nazwa symboliczna:

      Silny klucz

   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 członkowskie 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:

        Uwaga

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

        Aby uzyskać więcej informacji, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Baza 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ą mogły ustanowić zaufania niższego poziomu z domeną systemu Windows 2000 i zostanie wyświetlony następujący komunikat o błędzie:

        Uwaga

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

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

      • Windows XP: Klienty systemu Windows XP przyłączone do domen systemu Windows NT 4.0 nie mogą uwierzytelniać prób logowania i mogą otrzymywać następujący komunikat o błędzie lub w dzienniku zdarzeń mogą zostać zarejestrowane następujące zdarzenia:

        Uwaga

        System Windows nie może połączyć się z domeną, ponieważ kontroler domeny nie działa lub jest niedostępny z innego powodu albo nie znaleziono konta komputera

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

        Uwaga

        Błąd logowania: nieznana nazwa użytkownika lub nieprawidłowe hasło.

        Uwaga

        Dla określonej sesji logowania nie istnieje klucz sesji użytkownika.

5. Klient sieci firmy Microsoft: podpisywanie cyfrowe komunikacji (zawsze)

   1. Tło

      Blok komunikatów serwera (SMB, Server Message Block) to protokół współużytkowania zasobów obsługiwany przez wiele systemów operacyjnych firmy Microsoft. Jest podstawą podstawowego systemu wejścia/wyjścia sieciowego (NetBIOS) i wielu innych protokołów. Podpisywanie protokołu SMB polega na uwierzytelnieniu zarówno użytkownika, jak i serwera hostującego dane. Jeśli którakolwiek ze stron nie przejdzie procesu uwierzytelniania, transmisja danych nie nastąpi.

      Włączanie podpisywania protokołu SMB rozpoczyna się podczas negocjacji protokołu SMB. Zasady podpisywania protokołu SMB określają, czy komputer zawsze podpisuje cyfrowo komunikację z klientami.

      Protokół uwierzytelniania SMB systemu Windows 2000 obsługuje uwierzytelnianie wzajemne. Uwierzytelnianie wzajemne zamyka atak typu "man-in-the-middle". Uwierzytelnianie wiadomości jest również obsługiwane przez protokół uwierzytelniania SMB systemu Windows 2000. Uwierzytelnianie wiadomości pomaga zapobiegać aktywnym atakom na wiadomości. Aby zapewnić to uwierzytelnianie, podpisywanie SMB umieszcza podpis cyfrowy w każdym protokole SMB. Podpis cyfrowy jest weryfikowany zarówno przez klienta, jak i serwer.

      Aby korzystać z podpisywania SMB, musisz włączyć podpisywanie SMB lub wymagać podpisywania SMB zarówno na kliencie SMB, jak i na serwerze SMB. Jeśli na serwerze włączono podpisywanie protokołu SMB, na komputerach klienckich, dla których włączono również podpisywanie SMB, będzie używany protokół podpisywania pakietów podczas wszystkich kolejnych sesji. Jeśli na serwerze jest wymagane podpisywanie protokołu SMB, klient nie może ustanowić sesji, chyba że klient jest włączony lub wymagany do podpisywania SMB.

      Włączenie podpisu cyfrowego w sieciach o wysokim poziomie zabezpieczeń pomaga zapobiegać personifikacji klientów i serwerów. Ten rodzaj personifikacji jest nazywany przejmowaniem sesji. Osoba atakująca, która ma dostęp do tej samej sieci co klient lub serwer, używa narzędzi do przejmowania kontroli nad sesją, aby przerwać, zakończyć lub ukraść trwającą sesję. Osoba atakująca może przechwycić i zmodyfikować niepodpisane pakiety SMB, zmodyfikować ruch, a następnie przesłać go dalej, aby serwer mógł wykonać niechciane akcje. Osoba atakująca może też podszywać się pod serwer lub klienta po legalnym uwierzytelnieniu, a następnie uzyskać nieautoryzowany dostęp do danych.

      Uwierzytelnianie wzajemne jest obsługiwane przez protokół SMB używany do udostępniania plików i drukarek na komputerach z systemem Windows 2000 Server, Windows 2000 Professional, Windows XP Professional lub Windows Server 2003. Uwierzytelnianie wzajemne zamyka ataki przejmowania kontroli nad sesją i obsługuje uwierzytelnianie wiadomości. W związku z tym zapobiega atakom "man-in-the-middle". Podpisywanie protokołu SMB zapewnia to uwierzytelnianie przez umieszczenie podpisu cyfrowego w każdym protokole SMB. Następnie klient i serwer weryfikują podpis.

      Notatki

      • Alternatywnym środkiem zaradczym jest włączenie podpisów cyfrowych za pomocą protokołu IPSec w celu ochrony całego ruchu sieciowego. Istnieją sprzętowe akceleratory do szyfrowania i podpisywania IPSec, których można użyć w celu zminimalizowania wpływu procesora na wydajność serwera. Nie ma takich akceleratorów, które są dostępne na potrzeby podpisywania protokołu SMB.

        Aby uzyskać więcej informacji, zobacz rozdział Podpisywanie cyfrowe komunikacji z serwerem w witrynie Microsoft MSDN w sieci Web.

        Skonfiguruj podpisywanie SMB za pomocą Edytora obiektów zasady grupy, ponieważ zmiana wartości rejestru lokalnego nie ma żadnego wpływu, jeśli istnieją zastępujące zasady domeny.

      • W systemach Windows 95, Windows 98 i Windows 98 Second Edition klient usług katalogowych używa podpisywania SMB podczas uwierzytelniania NTLM na serwerach systemu Windows Server 2003. Jednak ci klienci nie używają podpisywania SMB podczas uwierzytelniania na tych serwerach przy użyciu uwierzytelniania NTLMv2. Ponadto serwery z systemem Windows 2000 nie odpowiadają na żądania podpisania protokołu SMB od tych klientów. Aby uzyskać więcej informacji, zobacz punkt 10: "Bezpieczeństwo sieci: Poziom uwierzytelniania Lan Managera."

   2. Ryzykowna konfiguracja

      Poniżej wymieniono szkodliwe ustawienie konfiguracji: Pozostawienie ustawienia Podpisz cyfrowo komunikację (zawsze) klienta sieci firmy Microsoft, jak i klienta sieci firmy Microsoft: Podpisuj cyfrowo komunikację (jeśli serwer się zgadza) ustawionej na wartość "Niezdefiniowane" lub wyłączonej. Te ustawienia umożliwiają przekierowywaniu wysyłanie haseł w formacie zwykłego tekstu do serwerów SMB innych niż Microsoft, które nie obsługują szyfrowania haseł podczas uwierzytelniania.

   3. Powody włączenia tego ustawienia

      Włączanie klienta sieci firmy Microsoft: Podpisywanie cyfrowe komunikacji (zawsze) wymaga, aby klienci podpisywali 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: podpisywanie komunikacji cyfrowej (zawsze) uniemożliwia klientom komunikowanie się z serwerami docelowymi, które nie obsługują podpisywania SMB.
      • Skonfigurowanie komputerów w taki sposób, aby ignorowały całą niepodpisaną komunikację SMB, uniemożliwia łączenie się starszych programów i systemów operacyjnych.

   5. Nazwa symboliczna:

      RequireSMBSignRdr

   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 relacji zaufania między domeną systemu Windows Server 2003 i domeną systemu Windows NT 4.0 za pomocą narzędzia NLTEST lub NETDOM i będzie wyświetlany komunikat o błędzie "Odmowa dostępu".

      • Windows XP: Kopiowanie plików z klientów systemu Windows XP na serwery z systemami Windows 2000 i Windows Server 2003 może trwać dłużej.

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

        Uwaga

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

   8. Wymagania dotyczące ponownego uruchamiania

      Uruchom ponownie komputer lub ponownie uruchom usługę stacji roboczej. Aby to zrobić, wpisz następujące polecenia w wierszu polecenia. Po wpisaniu każdego polecenia naciśnij klawisz Enter.
      net stop workstation
      net start workstation

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

   1. Tło

      • Server Messenger Block (SMB) to protokół współużytkowania zasobów obsługiwany przez wiele systemów operacyjnych firmy Microsoft. Jest podstawą podstawowego systemu wejścia/wyjścia sieciowego (NetBIOS) i wielu innych protokołów. Podpisywanie protokołu SMB polega na uwierzytelnieniu zarówno użytkownika, jak i serwera hostującego dane. Jeśli którakolwiek ze stron nie przejdzie procesu uwierzytelniania, transmisja danych nie nastąpi.

        Włączanie podpisywania protokołu SMB rozpoczyna się podczas negocjacji protokołu SMB. Zasady podpisywania protokołu SMB określają, czy komputer zawsze podpisuje cyfrowo komunikację z klientami.

        Protokół uwierzytelniania SMB systemu Windows 2000 obsługuje uwierzytelnianie wzajemne. Uwierzytelnianie wzajemne zamyka atak typu "man-in-the-middle". Uwierzytelnianie wiadomości jest również obsługiwane przez protokół uwierzytelniania SMB systemu Windows 2000. Uwierzytelnianie wiadomości pomaga zapobiegać aktywnym atakom na wiadomości. Aby zapewnić to uwierzytelnianie, podpisywanie SMB umieszcza podpis cyfrowy w każdym protokole SMB. Podpis cyfrowy jest weryfikowany zarówno przez klienta, jak i serwer.

        Aby korzystać z podpisywania SMB, musisz włączyć podpisywanie SMB lub wymagać podpisywania SMB zarówno na kliencie SMB, jak i na serwerze SMB. Jeśli na serwerze włączono podpisywanie protokołu SMB, na komputerach klienckich, dla których włączono również podpisywanie SMB, będzie używany protokół podpisywania pakietów podczas wszystkich kolejnych sesji. Jeśli na serwerze jest wymagane podpisywanie protokołu SMB, klient nie może ustanowić sesji, chyba że klient jest włączony lub wymagany do podpisywania SMB.

        Włączenie podpisu cyfrowego w sieciach o wysokim poziomie zabezpieczeń pomaga zapobiegać personifikacji klientów i serwerów. Ten rodzaj personifikacji jest nazywany przejmowaniem sesji. Osoba atakująca, która ma dostęp do tej samej sieci co klient lub serwer, używa narzędzi do przejmowania kontroli nad sesją, aby przerwać, zakończyć lub ukraść trwającą sesję. 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ł wykonać niechciane akcje. Osoba atakująca może też podszywać się pod serwer lub klienta po legalnym uwierzytelnieniu, a następnie uzyskać nieautoryzowany dostęp do danych.

        Uwierzytelnianie wzajemne jest obsługiwane przez protokół SMB używany do udostępniania plików i drukarek na komputerach z systemem Windows 2000 Server, Windows 2000 Professional, Windows XP Professional lub Windows Server 2003. Uwierzytelnianie wzajemne zamyka ataki przejmowania kontroli nad sesją i obsługuje uwierzytelnianie wiadomości. W związku z tym zapobiega atakom "man-in-the-middle". Podpisywanie protokołu SMB zapewnia to uwierzytelnianie przez umieszczenie podpisu cyfrowego w każdym protokole SMB. Następnie klient i serwer weryfikują podpis.

      • Alternatywnym środkiem zaradczym jest włączenie podpisów cyfrowych za pomocą protokołu IPSec w celu ochrony całego ruchu sieciowego. Istnieją sprzętowe akceleratory do szyfrowania i podpisywania IPSec, których można użyć w celu zminimalizowania wpływu procesora na wydajność serwera. Nie ma takich akceleratorów, które są dostępne na potrzeby podpisywania protokołu SMB.

      • W systemach Windows 95, Windows 98 i Windows 98 Second Edition klient usług katalogowych używa podpisywania SMB podczas uwierzytelniania NTLM na serwerach systemu Windows Server 2003. Jednak ci klienci nie używają podpisywania SMB podczas uwierzytelniania na tych serwerach przy użyciu uwierzytelniania NTLMv2. Ponadto serwery z systemem Windows 2000 nie odpowiadają na żądania podpisania protokołu SMB od tych klientów. Aby uzyskać więcej informacji, zobacz punkt 10: "Bezpieczeństwo sieci: Poziom uwierzytelniania Lan Managera."

   2. Ryzykowna konfiguracja

      Poniższe ustawienie konfiguracji jest szkodliwe: Włączanie serwera sieci firmy Microsoft: Podpisuj cyfrowo komunikację (zawsze) na serwerach i kontrolerach domeny, do których dostęp uzyskują niezgodne komputery z systemem Windows i komputery klienckie z systemem 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 pomocą ustawienia zasady grupy, obsługują podpisywanie SMB. Innymi słowy, na wszystkich komputerach klienckich z tym ustawieniem jest uruchomiony system Windows 95 z zainstalowanym klientem usług katalogowych, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional lub Windows Server 2003.
      • Jeśli pozycja Serwer sieci firmy Microsoft: podpisuj cyfrowo komunikację (zawsze) jest wyłączona, podpisywanie protokołu SMB jest całkowicie wyłączone. Całkowite wyłączenie podpisywania protokołu SMB powoduje, że komputery są bardziej podatne na ataki polegające na przejmowaniu sesji.

   4. Powody wyłączenia tego ustawienia

      • Włączenie tego ustawienia może spowolnić kopiowanie plików i spowolnienie działania sieci na komputerach klienckich.
      • Włączenie tego ustawienia uniemożliwi klientom, którzy nie mogą negocjować podpisywania SMB, komunikowanie się z serwerami i kontrolerami domeny. Powoduje to niepowodzenie operacji takich jak przyłączanie do domeny, uwierzytelnianie użytkowników i komputerów lub uzyskiwanie dostępu programów do sieci.

   5. Nazwa symboliczna:

      RequireSMBSignServer

   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: Na komputerach klienckich z systemem Windows 95, które nie mają zainstalowanego klienta usług katalogowych (DS), nie powiedzie się uwierzytelnianie podczas logowania i zostanie wyświetlony następujący komunikat o błędzie:

        Uwaga

        Podane hasło domeny jest niepoprawne lub odmówiono dostępu do serwera logowania.

      • Windows NT 4.0: Komputery klienckie z systemami w wersji systemu Windows NT 4.0 starszymi niż Service Pack 3 (SP3) nie przejdą uwierzytelniania logowania i zostanie wyświetlony następujący komunikat o błędzie:

        Uwaga

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

        Niektóre serwery SMB firmy innej niż Microsoft obsługują tylko wymianę nieszyfrowanych haseł podczas uwierzytelniania. (Te wymiany nazywane są również wymianami "zwykłego tekstu"). W systemie Windows NT 4.0 z dodatkiem SP3 i nowszych wersjach przekierowywanie SMB nie wysyła niezaszyfrowanego hasła podczas uwierzytelniania do serwera SMB, o ile nie zostanie dodany określony wpis rejestru.
        Aby włączyć niezaszyfrowane hasła dla klienta SMB w systemie Windows NT 4.0 z dodatkiem SP3 lub nowszym, należy zmodyfikować 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ń kontrolerów domeny z systemem Windows Server 2003 są skonfigurowane w celu zapobiegania przechwytywaniu i manipulowaniu komunikacją kontrolera domeny przez złośliwych użytkowników. Aby użytkownicy mogli pomyślnie komunikować się z kontrolerem domeny z systemem Windows Server 2003, komputery klienckie muszą używać zarówno podpisywania i szyfrowania SMB, jak i podpisywania ruchu w bezpiecznym kanale. Domyślnie podpisywanie pakietów SMB nie jest włączone na komputerach klienckich z zainstalowanym systemem Windows NT 4.0 z dodatkiem Service Pack 2 (SP2) lub starszym oraz na komputerach klienckich z systemem Windows 95. Z tego powodu klienci ci mogą nie być w stanie uwierzytelnić się na kontrolerze domeny z systemem Windows Server 2003.

      • Ustawienia zasad systemów Windows 2000 i Windows Server 2003: W zależności od konkretnych potrzeb instalacyjnych i konfiguracji zalecamy ustawienie następujących ustawień zasad w najmniejszej jednostce niezbędnego zakresu w hierarchii przystawki Edytor zasady grupy programu Microsoft Management Console:

        • Konfiguracja komputera\Ustawienia zabezpieczenia Windows\Opcje zabezpieczeń
        • Wysyłanie nieszyfrowanego hasła do łączenia się z serwerami SMB innych firm (to ustawienie dotyczy systemu Windows 2000)
        • Klient sieci firmy Microsoft: Wysyłanie niezaszyfrowanego hasła do serwerów SMB innych firm (to ustawienie dotyczy systemu Windows Server 2003)

        Uwaga: Na niektórych serwerach CIFS innych firm, takich jak starsze wersje Samby, nie można używać zaszyfrowanych haseł.

      • Następujący klienci są niezgodni z serwerem sieci firmy Microsoft: Ustawienie Podpisz cyfrowo komunikację (zawsze):

        • Apple Computer, Inc., klienty systemu Mac OS X
        • Klienci sieciowi Microsoft MS-DOS (na przykład Microsoft LAN Manager)
        • Klienci systemu Microsoft Windows for Workgroups
        • Klienty systemu Microsoft Windows 95 bez zainstalowanego klienta DS Client
        • Komputery z systemem Microsoft Windows NT 4.0 bez zainstalowanego dodatku SP3 lub nowszego
        • Klienci CIFS oprogramowania Novell Netware 6
        • Klienci SAMBA SMB, którzy nie obsługują podpisywania SMB

   8. Wymagania dotyczące ponownego uruchamiania

      Uruchom ponownie komputer lub ponownie uruchom usługę serwera. Aby to zrobić, 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 sieciowy: zezwalaj na anonimową translację identyfikatorów SID/nazw

   1. Tło

      Ustawienie zabezpieczeń Dostęp sieciowy: Zezwalaj na anonimową translację identyfikatorów SID/nazw określa, czy użytkownik anonimowy może żądać atrybutów identyfikatora zabezpieczeń (SID) od innego użytkownika.

   2. Ryzykowna konfiguracja

      Włączanie ustawienia Dostęp sieciowy: Zezwalaj na anonimową translację identyfikatorów SID/nazw jest szkodliwym ustawieniem konfiguracji.

   3. Powody włączenia tego ustawienia

      Jeśli ustawienie Dostęp sieciowy: Zezwalaj na anonimową translację identyfikatorów SID/nazw jest wyłączone, wcześniejsze systemy operacyjne lub aplikacje mogą nie być w stanie komunikować się z domenami systemu Windows Server 2003. Mogą nie działać na przykład następujące systemy operacyjne, usługi lub aplikacje:

      • Serwery usługi dostępu zdalnego oparte na systemie Windows NT 4.0
      • SQL Server firmy Microsoft uruchomione na komputerach z systemem Windows NT 3.x lub Windows NT 4.0
      • Usługa dostępu zdalnego uruchomiona na komputerach z systemem Windows 2000, które znajdują się w domenach systemów Windows NT 3.x lub Windows NT 4.0
      • Program SQL Server uruchomiony na komputerach z systemem Windows 2000 znajdujących się w domenach Windows NT 3.x lub 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 kontom użytkowników z domen kont zawierających kontrolery domen systemu Windows Server 2003

   4. Powody wyłączenia tego ustawienia

      Jeśli to ustawienie jest włączone, złośliwy użytkownik może użyć dobrze znanego identyfikatora SID administratora do uzyskania rzeczywistej nazwy wbudowanego konta administratora, nawet jeśli nazwa konta została zmieniona. 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 wyświetlają komunikat o błędzie "Nieznane konto" w edytorze listy ACL, jeśli zasoby, w tym foldery udostępnione, pliki udostępnione i obiekty rejestru, są zabezpieczone za pomocą zabezpieczeń zabezpieczeń znajdujących się w domenach kont zawierających kontrolery domen systemu Windows Server 2003.

8. Dostęp sieciowy: Nie zezwalaj na anonimowe wyliczanie kont SAM

   1. Tło

      • Ustawienie Dostęp sieciowy: Nie zezwalaj na anonimowe wyliczanie kont SAM określa, jakie dodatkowe uprawnienia będą przyznawane w przypadku anonimowych połączeń z komputerem. System Windows zezwala użytkownikom anonimowym na wykonywanie pewnych czynności, takich jak wyliczanie nazw kont stacji roboczych i serwera w Menedżerze kont zabezpieczeń (SAM) oraz udziałów sieciowych. Na przykład administrator może użyć tego ustawienia, aby udzielić dostępu użytkownikom w zaufanej domenie, w której nie obowiązuje wzajemne zaufanie. Po nawiązaniu sesji użytkownik anonimowy może mieć taki sam dostęp, jaki jest przyznany grupie Wszyscy na podstawie ustawienia w ustawieniu w sekcji Dostęp sieciowy: Uprawnienia Zezwalaj wszystkim na stosowanie do użytkowników anonimowych lub poufnej listy kontroli dostępu (DACL) obiektu.

        Zazwyczaj połączenia anonimowe są żądane przez starsze wersje klientów (klientów niższego poziomu) podczas konfigurowania sesji SMB. W takich przypadkach śledzenie sieci pokazuje, że identyfikatorem procesu SMB (PID) jest przekierowanie klienta, takie jak 0xFEFF w systemie Windows 2000 lub 0xCAFE w systemie Windows NT. Usługa RPC może również próbować nawiązywać anonimowe połączenia.

      • Ważne To ustawienie nie ma wpływu na kontrolery domeny. Na kontrolerach domeny to zachowanie jest kontrolowane przez obecność "NT AUTHORITY\ANONYMOUS LOGON" w sekcji "Dostęp zgodny z systemem starszym niż Windows 2000".

      • W systemie Windows 2000 wartość rejestru RestrictAnonymous jest zarządzana przy użyciu podobnego ustawienia o nazwie Dodatkowe ograniczenia dla połączeń anonimowych. Lokalizacja tej wartości jest następująca
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Ryzykowne konfiguracje

      Włączanie dostępu sieciowego: Ustawienie Nie zezwalaj na anonimowe wyliczanie kont SAM jest szkodliwym ustawieniem konfiguracji z punktu widzenia zgodności. Wyłączenie tej opcji jest niekorzystnym ustawieniem konfiguracji z punktu widzenia zabezpieczeń.

   3. Powody włączenia tego ustawienia

      Nieautoryzowany użytkownik może anonimowo podać listę nazw kont, a następnie wykorzystać te informacje do odgadnięcia haseł lub przeprowadzenia ataków socjotechnicznych. Inżynieria społeczna to żargon oznaczający 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 ustanawiać relacji zaufania z domenami systemu Windows NT 4.0. To ustawienie powoduje również problemy z klientami niższego poziomu (takimi jak klienci systemów Windows NT 3.51 i 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ą

   • Odnajdowanie sieci SMS nie będzie mogło uzyskać informacji o systemie operacyjnym i zapisze "Nieznane" we właściwości OperatingSystemNameandVersion.
   • Windows 95, Windows 98: klienci z systemami Windows 95 i Windows 98 nie będą mogli zmieniać swoich haseł.
   • Windows NT 4.0: Uwierzytelnianie komputerów członkowskich opartych na systemie Windows NT 4.0 nie będzie możliwe.
   • Windows 95, Windows 98: Komputery z systemem Windows 95 i Windows 98 nie będą mogły być uwierzytelniane przez kontrolery domeny firmy Microsoft.
   • Windows 95, Windows 98: Użytkownicy komputerów z systemami 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 wyliczanie kont SAM i udziałów

   1. Tło

      • Ustawienie Dostęp sieciowy: Nie zezwalaj na anonimowe wyliczanie kont SAM i udziałów (znane również jako RestrictAnonymous) określa, czy jest dozwolone anonimowe wyliczanie kont i udziałów Menedżera kont zabezpieczeń (SAM). System Windows zezwala użytkownikom anonimowym na wykonywanie pewnych czynności, takich jak wyliczanie nazw kont domeny (użytkowników, komputerów i grup) oraz udziałów sieciowych. Jest to wygodne na przykład wtedy, gdy administrator chce udzielić dostępu użytkownikom w zaufanej domenie, w której nie istnieje wzajemne zaufanie. Jeśli nie chcesz zezwolić na anonimowe wyliczanie kont SAM i udziałów, włącz to ustawienie.
      • W systemie Windows 2000 wartość rejestru RestrictAnonymous jest zarządzana przy użyciu podobnego ustawienia o nazwie Dodatkowe ograniczenia dla połączeń anonimowych. Lokalizacja tej wartości jest następująca:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Ryzykowna konfiguracja

      Włączanie ustawienia Dostęp sieciowy: Nie zezwalaj na anonimowe wyliczanie 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 wyliczanie kont SAM i udziałów uniemożliwia wyliczanie 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 podać nazwy kont, a następnie użyć tych informacji do odgadnięcia haseł lub przeprowadzenia ataków socjotechnicznych. Inżynieria społeczna to żargon oznaczający nakłanianie ludzi do ujawnienia hasła lub jakiejś formy informacji zabezpieczających.
      • Jeśli to ustawienie jest włączone, nie będzie można ustanawiać relacji zaufania z domenami systemu Windows NT 4.0. To ustawienie spowoduje również problemy z klientami niższego poziomu, takimi jak komputery z systemami Windows NT 3.51 i Windows 95, które próbują korzystać z zasobów serwera.
      • Udzielenie dostępu użytkownikom domen zasobów będzie niemożliwe, ponieważ administratorzy w domenie ufającej nie będą mogli wyliczyć list kont w innej domenie. Użytkownicy, którzy uzyskują anonimowy dostęp do serwerów plików i wydruku, nie mogą wyświetlać listy udostępnionych zasobów sieciowych na tych serwerach. Aby móc wyświetlać listy folderów udostępnionych i drukarek, użytkownicy muszą się uwierzytelnić.

   5. Nazwa symboliczna:

      RestrictAnonymous (ograniczenie)

   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ł na stacjach roboczych z systemem Windows NT 4.0, jeśli na kontrolerach domeny w domenie użytkownika jest włączona opcja RestrictAnonymous.

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

        Uwaga

        Obecnie nie ma dostępnych serwerów logowania, które mogłyby obsłużyć żądanie logowania.

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

      • Windows NT 4.0: Ustanawianie zaufania niższego poziomu z domenami 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:

        Uwaga

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

      • Windows NT 4.0: Użytkownicy logujący się na komputerach z serwerem terminali z systemem Windows NT 4.0 zostaną zamapowani na domyślny katalog macierzysty, a nie na katalog macierzysty zdefiniowany w Menedżerze użytkowników dla domen.

      • Windows NT 4.0: Kopie zapasowe kontrolerów domeny systemu Windows NT 4.0 nie będą mogły uruchamiać usługi Net Logon, uzyskiwać listy zapasowych przeglądarek ani synchronizować bazy danych SAM z systemu Windows 2000 lub kontrolerów domeny systemu Windows Server 2003 w tej samej domenie.

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

      • Windows 2000: Użytkownicy domeny systemu Windows 2000 nie będą mogli dodawać drukarek sieciowych z usługi Active Directory. Jednak będą oni mogli dodawać drukarki po wybraniu ich z 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, które są migrowane między lasami za pomocą narzędzia do migracji usługi Active Directory (ADMT) w wersji 2, zakończy się niepowodzeniem.

        Aby uzyskać więcej informacji, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Baza wiedzy Microsoft Knowledge Base:
        322981 Jak rozwiązywać problemy z migracją haseł między lasami przy użyciu narzędzia ADMTv2

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

      • SMS: Funkcja odnajdowania sieci serwera Microsoft Systems Management Server (SMS) nie będzie mogła uzyskać informacji o systemie operacyjnym. W związku z tym zapisze "Unknown" we właściwości OperatingSystemNameandVersion właściwości SMS DDR rekordu danych odnajdowania (DDR).

      • SMS: W przypadku przeglądania użytkowników i grup za pomocą Kreatora administratora wiadomości SMS nie zostaną wyświetlone żadne użytkowników ani grupy. Dodatkowo, zaawansowani klienci nie mogą komunikować się z Punktem Zarządzania. Wymagany jest dostęp anonimowy w punkcie zarządzania.

      • SMS: W przypadku korzystania z funkcji odnajdowania sieci w programie SMS 2.0 i w zdalnej instalacji klienta z włączoną opcją odnajdowania sieci w topologii, klienckich systemach operacyjnych i klienckich komputery mogą być wykrywane, ale mogą nie być zainstalowane.

10. Bezpieczeństwo sieci: Poziom uwierzytelniania Lan Managera

    1. Tło

       Uwierzytelnianie programu LAN Manager (LM) to protokół używany do uwierzytelniania klientów systemu Windows na potrzeby operacji sieciowych, w tym przyłączania 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 wezwania/odpowiedzi jest negocjowany między komputerem klienckim a serwerem. W szczególności poziom uwierzytelniania LM określa, które protokoły uwierzytelniania klient będzie próbował negocjować lub które serwer zaakceptuje. Wartość ustawiona dla parametru LmCompatibilityLevel określa, który protokół uwierzytelniania wezwania/odpowiedzi jest używany do logowania w sieci. Ta wartość wpływa na poziom protokołu uwierzytelniania używanego przez klientów, poziom wynegocjowanych zabezpieczeń sesji oraz poziom uwierzytelniania akceptowanego przez serwery.

       Dostępne są następujące ustawienia.

       Value (Wartość)	Ustawienie	Opis
       0	Wysyłanie odpowiedzi LM & NTLM	Klienci korzystają z 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 oraz używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLMv2.
       2	Wyślij tylko odpowiedź NTLM	Klienci korzystają tylko z uwierzytelniania NTLM i używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLMv2.
       3	Wyślij tylko odpowiedź NTLMv2	Klienci korzystają tylko z 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 korzystają tylko z 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 korzystają tylko z uwierzytelniania NTLMv2 i używają zabezpieczeń sesji NTLMv2, jeśli serwer je obsługuje. Kontrolery domeny odrzucają uwierzytelnianie 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 podpisywania 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 z systemem Windows 2000 nie odpowiadają na żądania podpisania protokołu SMB od tych klientów.

       Sprawdź poziom uwierzytelniania LM: Należy zmienić zasady na serwerze, aby zezwolić na NTLM, lub skonfigurować komputer kliencki do obsługi protokołu NTLMv2.

       Jeśli na komputerze docelowym, z którym ma zostać nawiązane połączenie, zasady mają wartość (5) Wyślij tylko odpowiedź NTLMv2\Odmów LM & NTLM, należy obniżyć ustawienie na tym komputerze lub ustawić zabezpieczenia na takie samo ustawienie jak na komputerze źródłowym, z którego jest nawiązywane połączenie.

       Znajdź właściwą lokalizację, w której można zmienić poziom uwierzytelniania menedżera sieci LAN, aby ustawić ten sam poziom dla klienta i serwera. Jeśli chcesz łączyć się z i z komputerami z wcześniejszymi wersjami systemu Windows, po znalezieniu zasady, która ustawia poziom uwierzytelniania menedżera sieci LAN, zmniejsz wartość do co najmniej (1) Wyślij LM & NTLM — w przypadku negocjacji użyj zabezpieczeń sesji NTLM w wersji 2. Jednym ze skutków niezgodnych ustawień jest to, że jeśli serwer wymaga protokołu NTLMv2 (wartość 5), ale klient jest skonfigurowany do używania wyłącznie protokołu LM i NTLMv1 (wartość 0), to u użytkownika podejmującego próbę uwierzytelnienia wystąpi błąd logowania z nieprawidłowym hasłem, co spowoduje zwiększenie liczby błędów haseł. Jeśli skonfigurowano blokadę konta, użytkownik może ostatecznie zostać zablokowany.

       Na przykład może być konieczne przyjrzenie się kontrolerowi domeny lub przeanalizowanie zasad kontrolera domeny.

       Spójrz na kontroler domeny

       Uwaga: Może być konieczne powtórzenie poniższej procedury na wszystkich kontrolerach domeny.

       1. Kliknij przycisk Start, wskaż polecenie Programy, a następnie kliknij polecenie Narzędzia administracyjne.
       2. W sekcji Ustawienia zabezpieczeń lokalnych rozwiń pozycję Zasady lokalne.
       3. Kliknij pozycję Opcje zabezpieczeń.
       4. Kliknij dwukrotnie pozycję Zabezpieczenia sieci: Poziom uwierzytelniania menedżera sieci LAN, a następnie kliknij wartość na liście.

       Jeśli ustawienie efektywne i ustawienie lokalne są takie same, oznacza to, że zasady zostały zmienione na tym poziomie. Jeśli te ustawienia są inne, należy sprawdzić zasady kontrolera domeny, aby ustalić, czy zdefiniowano w nich ustawienie poziomu uwierzytelniania Zabezpieczenia sieci: menedżera sieci LAN. Jeśli nie jest tam zdefiniowany, sprawdź zasady kontrolera domeny.

       Sprawdzanie zasad kontrolera domeny

       1. Kliknij przycisk Start, wskaż polecenie Programy, a następnie kliknij polecenie Narzędzia administracyjne.
       2. W zasadach zabezpieczeń kontrolera domeny rozwiń pozycję Ustawienia zabezpieczeń, a następnie rozwiń pozycję Zasady lokalne.
       3. Kliknij pozycję Opcje zabezpieczeń.
       4. Kliknij dwukrotnie pozycję Zabezpieczenia sieci: Poziom uwierzytelniania menedżera sieci LAN, a następnie kliknij wartość na liście.

       Uwaga

       • Aby ustalić, gdzie należy skonfigurować poziom uwierzytelniania menedżera sieci LIN, może być konieczne sprawdzenie zasad połączonych na poziomie lokacji, domeny lub jednostki organizacyjnej (OU).
       • Jeśli jako domyślne zasady domeny zostanie zaimplementowane ustawienie zasady grupy, zasady zostaną zastosowane do wszystkich komputerów w domenie.
       • Jeśli zaimplementujesz ustawienie zasady grupy jako domyślne zasady kontrolera domeny, zasady będą stosowane tylko do serwerów w jednostce organizacyjnej kontrolera domeny.
       • Dobrym pomysłem jest ustawienie poziomu uwierzytelniania LAN Managera w najniższej jednostce niezbędnego zakresu w hierarchii aplikacji polityki.

       System Windows Server 2003 ma nowe ustawienie domyślne, aby używać tylko protokołu NTLMv2. Domyślnie kontrolery domen w systemach Windows Server 2003 i Windows 2000 Server z dodatkiem SP3 mają włączoną zasadę "Serwer sieci Microsoft: podpisuj cyfrowo komunikację (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 każdej organizacji wymagają innych ustawień w celu zmaksymalizowania ich bezpieczeństwa.

       Aby zaimplementować w sieci uwierzytelnianie NTLMv2, należy się upewnić, że wszystkie komputery w domenie są skonfigurowane do używania tego poziomu uwierzytelniania. W przypadku stosowania rozszerzeń klienta usługi Active Directory dla systemów Windows 95, Windows 98 i Windows NT 4.0 rozszerzenia klienta korzystają z ulepszonych funkcji uwierzytelniania dostępnych w NTLMv2. Ponieważ obiekty zasady grupy systemu Windows nie mają wpływu na komputery klienckie z następującymi systemami operacyjnymi, 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 opcję Zabezpieczenia sieci: Nie zapisuj wartości skrótu menedżera sieci LAN przy następnej zmianie hasła ani nie ustawiaj klucza rejestru NoLMHash , klienci z systemów Windows 95 i Windows 98, którzy nie mają zainstalowanego klienta usług katalogowych, nie będą mogli zalogować się do domeny po zmianie hasła.

       Wiele serwerów CIFS innych firm, takich jak Novell Netware 6, nie zna protokołu NTLMv2 i używa tylko protokołu NTLM. Dlatego poziomy większe niż 2 nie zezwalają na łączność. Istnieją również klienci SMB innych firm, którzy nie korzystają z rozszerzonych zabezpieczeń sesji. W takich przypadkach LmCompatiblityLevel serwera zasobów nie jest brany pod uwagę. Następnie serwer pakuje to starsze żądanie i wysyła je do kontrolera domeny użytkownika. Ustawienia na kontrolerze domeny decydują następnie o tym, jakie skróty są używane do weryfikacji żądania i czy spełniają one wymagania dotyczące zabezpieczeń kontrolera domeny.

        
       299656 Jak zapobiec przechowywaniu przez system Windows skrótu hasła menedżera sieci LAN w usłudze Active Directory i lokalnych bazach danych SAM
        
       2701704 Zdarzenie inspekcji pokazuje pakiet uwierzytelniania jako NTLMv1 zamiast NTLMv2 Aby uzyskać więcej informacji dotyczących poziomów uwierzytelniania LM, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Baza wiedzy Microsoft Knowledge Base:
       239869 Jak włączyć uwierzytelnianie NTLM 2
        

    2. Ryzykowne konfiguracje

       Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

       • Nierestrykcyjne ustawienia, które wysyłają hasła w postaci zwykłego tekstu i które odmawiają negocjacji NTLMv2

       • restrykcyjne ustawienia, które uniemożliwiają niezgodnym klientom lub kontrolerom domeny negocjowanie wspólnego protokołu uwierzytelniania

       • Wymaganie uwierzytelniania NTLMv2 na komputerach członkowskich i kontrolerach domen z systemem Windows NT 4.0 starszym niż z dodatkiem Service Pack 4 (SP4)

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

       • Jeżeli klikniesz pole wyboru Wymagaj zabezpieczeń sesji NTLMv2 w przystawce Edytor zasady grupy programu Microsoft Management Console 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 tych dwóch ustawień, a w pliku Secpol.msc lub GPEdit.msc może zostać wyświetlony następujący komunikat o błędzie:

         Uwaga

         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 Security Configuration and Analysis Tool, zobacz pliki Pomocy systemu Windows 2000 lub systemu Windows Server 2003.

    3. Powody modyfikacji tego ustawienia

       • Chcesz zwiększyć wartość najniższego wspólnego protokołu uwierzytelniania obsługiwanego przez klientów i kontrolery domeny w organizacji.
       • W przypadku, gdy bezpieczne uwierzytelnianie jest wymogiem biznesowym, chcesz zabronić negocjacji między LM a protokołami NTLM.

    4. Powody wyłączenia tego ustawienia

       Wymagania dotyczące uwierzytelniania klienta i/serwera lub obu tych elementów zostały zwiększone do tego stopnia, że nie można przeprowadzać uwierzytelniania za pośrednictwem wspólnego protokołu.

    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 ustawienie wysyłania odpowiedzi NTLM NTLMv2 w systemie Windows Server 2003 jest włączone. Dlatego podczas pierwszej instalacji systemu Windows Server 2003 wyświetla komunikat o błędzie "Odmowa dostępu" podczas próby połączenia z klastrem opartym na systemie Windows NT 4.0 lub z serwerami LanManager V2.1, takimi jak Lanserver OS/2. Ten problem występuje również podczas próby nawiązania połączenia z poziomu wcześniejszej wersji klienta z serwerem z systemem Windows Server 2003.

       • Zainstalowano pakiet zbiorczy aktualizacji zabezpieczeń systemu Windows 2000 1 (SRP1). SRP1 wymusza NTLM w wersji 2 (NTLMv2). Ten pakiet zbiorczy 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 producentów, takich jak Novell Netware 6 lub serwery Samba oparte na systemie Linux, nie zna NTLMv2 i używa tylko NTLM. Dlatego poziomy większe niż "2" nie zezwalają na łączność. Teraz w tej wersji systemu operacyjnego wartość domyślna parametru LmCompatibilityLevel została zmieniona na "3". Dlatego po uaktualnieniu systemu Windows te zewnętrzne programy filtrujące mogą przestać działać.

       • Klienci programu Microsoft Outlook mogą być monitowani 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

         Uwaga

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

         Podczas uruchamiania programu Outlook może zostać wyświetlony monit o podanie poświadczeń, nawet jeśli w ustawieniach zabezpieczeń sieciowych logowania wybrano opcję Przekazywanie lub Uwierzytelnianie hasłem. Po wpisaniu poprawnych poświadczeń może zostać wyświetlony następujący komunikat o błędzie:

         Uwaga

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

         Śledzenie Monitora sieci może ujawnić, że wykaz globalny wystawił błąd zdalnego wywołania procedury (RPC) ze stanem 0x5. Stan 0x5 oznacza "Odmowa dostępu".

       • Windows 2000: Przechwycenie monitora sieci może spowodować wyświetlenie następujących błędów w sesji bloku komunikatów serwera (SMB) NetBIOS przez TCP/IP (NetBT):

         Uwaga

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

       • Windows 2000: Jeśli domena systemu Windows 2000 z protokołem NTLMv2 poziomu 2 lub nowszego jest zaufana przez domenę systemu Windows NT 4.0, na komputerach członkowskich z systemem Windows 2000 w domenie zasobu mogą występować błędy uwierzytelniania.

       • Windows 2000 i Windows XP: W systemach Windows 2000 i Windows XP ustawienie opcji Zasad zabezpieczeń lokalnych w Menedżerze sieci LAN Manager jest domyślnie ustawione na 0. Ustawienie 0 oznacza "Wysyłaj odpowiedzi LM i NTLM".

         Uwaga: klastry oparte na systemie Windows NT 4.0 muszą administrować usługą LM.

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

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

       • Usługi dla komputerów Macintosh

         Moduł uwierzytelniania użytkowników (UAM): Moduł UAM (User Authentication Module) firmy Microsoft umożliwia szyfrowanie haseł używanych do logowania się do serwerów Windows AFP (AppleTalk Filing Protocol). Moduł Apple User Authentication Module (UAM) zapewnia tylko minimalne szyfrowanie lub nie ma go wcale. W związku z tym Twoje hasło może zostać łatwo przechwycone w sieci LAN lub w Internecie. Mimo że UAM nie jest wymagany, umożliwia szyfrowane uwierzytelnianie na serwerach z systemem Windows 2000, na których są uruchomione usługi dla komputerów Macintosh. Ta wersja zawiera obsługę uwierzytelniania za pomocą 128-bitowego szyfrowania NTLMv2 oraz wersję zgodną z systemem MacOS X 10.1.

         Domyślnie serwer usług systemu Windows Server 2003 dla komputerów Macintosh zezwala tylko na uwierzytelnianie Microsoft.
          

       • Windows Server 2008, Windows Server 2003, Windows XP i Windows 2000: Jeśli skonfigurujesz LMCompatibilityLevel na wartość 0 lub 1, a następnie skonfigurujesz wartość NoLMHash na 1, aplikacje i składniki mogą nie mieć dostępu za pośrednictwem protokołu NTLM. Ten problem występuje, ponieważ komputer jest skonfigurowany w taki sposób, aby włączał LM, ale nie używał haseł przechowywanych w LM.

         Jeśli skonfigurujesz wartość NoLMHash na 1, musisz skonfigurować LMCompatibilityLevel na wartość 2 lub wyższą.

11. Bezpieczeństwo sieci: wymagania dotyczące podpisywania klienta LDAP

    1. Tło

       Ustawienie Zabezpieczenia sieci: wymagania dotyczące podpisywania klientów LDAP określa poziom podpisywania danych żądanych w imieniu klientów wysyłających żądania BIND protokołu LDAP (Lightweight Directory Access Protocol):

       • Brak: Żądanie LDAP BIND jest wysyłane z opcjami określonymi przez wywołującego.
       • Negocjuj podpisywanie: Jeśli protokół SSL/TLS (Secure Sockets Layer/Transport Layer Security) nie został uruchomiony, żądanie LDAP BIND jest inicjowane z ustawioną opcją podpisywania danych LDAP oprócz opcji określonych przez wywołującego. Jeśli protokół SSL/TLS został uruchomiony, zostanie zainicjowane żądanie LDAP BIND z opcjami określonymi przez wywołującego.
       • Wymagaj podpisu: jest to to samo, co podpisywanie negocjacyjne. Jeśli jednak pośrednia odpowiedź saslBindInProgress serwera LDAP nie wskazuje, że podpisywanie ruchu LDAP jest wymagane, obiekt wywołujący jest informowany, że żądanie polecenia LDAP BIND nie powiodło się.

    2. Ryzykowna konfiguracja

       Włączanie ustawienia Zabezpieczenia sieci: Wymagania podpisywania klienta LDAP jest szkodliwym ustawieniem konfiguracji. Jeśli serwer jest ustawiony tak, aby wymagał podpisów LDAP, musisz również skonfigurować podpisywanie LDAP na kliencie. Nieskonfigurowanie klienta do używania sygnatur LDAP uniemożliwi komunikację z serwerem. Powoduje to niepowodzenie uwierzytelniania użytkownika, ustawień zasady grupy, skryptów logowania i innych funkcji.

    3. Powody modyfikacji tego ustawienia

       Niepodpisany ruch sieciowy jest podatny na ataki "man-in-the-middle", w których intruz przechwytuje pakiety między klientem a serwerami, modyfikuje je, a następnie przesyła do serwera. Gdy taka sytuacja wystąpi na serwerze LDAP, osoba atakująca może spowodować utworzenie odpowiedzi serwera na podstawie fałszywych zapytań od klienta LDAP. To ryzyko można obniżyć, wdrażając silne zabezpieczenia fizyczne w celu ochrony infrastruktury sieciowej. Ponadto można zapobiegać wszelkim rodzajom ataków "man-in-the-middle", wymagając podpisów cyfrowych na 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. Tło

       Ustawienie zabezpieczeń Dziennik zdarzeń: Maksymalny rozmiar dziennika zabezpieczeń określa maksymalny rozmiar dziennika zdarzeń zabezpieczeń. Ten dziennik ma maksymalny rozmiar 4 GB. Aby zlokalizować to ustawienie, rozwiń węzeł
       Ustawienia systemu Windows, a następnie rozwiń węzeł Ustawienia zabezpieczeń.

    2. Ryzykowne konfiguracje

       Poniżej przedstawiono szkodliwe ustawienia konfiguracji:

       • Ograniczanie rozmiaru dziennika zabezpieczeń i metody przechowywania dziennika zabezpieczeń, gdy włączone jest ustawienie Inspekcja: Zamknij system natychmiast, jeśli nie można rejestrować inspekcji zabezpieczeń. Aby uzyskać więcej informacji, zobacz sekcję "Inspekcja: natychmiast zamknij system, jeśli nie można zarejestrować inspekcji zabezpieczeń" tego artykułu.
       • Ograniczanie rozmiaru dziennika zabezpieczeń, co pozwoli na zastępowanie interesujących zdarzeń zabezpieczeń.

    3. Powody, dla których należy zwiększyć to ustawienie

       Wymagania biznesowe i wymagania dotyczące zabezpieczeń mogą nakazywać zwiększenie rozmiaru dziennika zabezpieczeń w celu obsługi dodatkowych szczegółów dziennika zabezpieczeń lub przechowywania dzienników zabezpieczeń przez dłuższy czas.

    4. Przyczyny zmniejszania tego ustawienia

       Dzienniki podglądu zdarzeń to pliki zamapowane w pamięci. Maksymalny rozmiar dziennika zdarzeń jest ograniczony ilością pamięci fizycznej na komputerze lokalnym i pamięcią wirtualną dostępną dla procesu dziennika zdarzeń. Zwiększenie rozmiaru dziennika ponad ilość pamięci wirtualnej dostępnej dla podglądu zdarzeń nie powoduje zwiększenia liczby przechowywanych wpisów dziennika.

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

       Windows 2000: Komputery z systemami Windows 2000 starszymi niż Service Pack 4 (SP4) mogą przestać rejestrować zdarzenia w dzienniku zdarzeń, zanim osiągną rozmiar określony w ustawieniu Maksymalny rozmiar dziennika w Podglądzie zdarzeń, jeżeli opcja Nie zastępuj zdarzeń (ręczne wyczyść dziennik) jest włączona.

        

13. Dziennik zdarzeń: Zachowaj dziennik zabezpieczeń

    1. Tło

       Ustawienie zabezpieczeń Dziennik zdarzeń: Zachowaj dziennik zabezpieczeń określa metodę zawijania 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:

       • Niezachowywanie wszystkich zarejestrowanych zdarzeń zabezpieczeń przed ich zastąpieniem
       • Konfigurowanie zbyt małego ustawienia maksymalnego rozmiaru dziennika zabezpieczeń, aby zdarzenia zabezpieczeń były zastępowane
       • Ograniczanie rozmiaru dziennika zabezpieczeń i metody przechowywania, gdy włączona jest opcja Inspekcja: Natychmiast zamknij system, jeśli nie można zarejestrować inspekcji zabezpieczeń

    3. Powody włączenia tego ustawienia

       To ustawienie należy włączyć tylko wtedy, gdy wybierzesz metodę zastępowania zdarzeń według dni . Jeśli korzystasz z systemu korelacji zdarzeń sondującego zdarzenia, upewnij się, że liczba dni jest co najmniej trzykrotnie większa niż częstotliwość sondowania. Wykonaj tę czynność, aby umożliwić cykle sondowania zakończone niepowodzeniem.

14. Dostęp do sieci: Uprawnienia Pozwól wszystkim stosować do użytkowników anonimowych

    1. Tło

       W systemie Windows Server 2003 ustawienie Dostęp sieciowy: Uprawnienia Niech wszyscy mają zastosowanie do użytkowników anonimowych jest domyślnie ustawione na wartość Niezdefiniowane. Domyślnie system Windows Server 2003 nie zawiera tokenu dostępu anonimowego w grupie Wszyscy.

    2. Przykład problemów ze zgodnością

       Następująca wartość
       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 przerywa tworzenie zaufania między Windows Server 2003 a Windows NT 4.0, kiedy domeną Windows Server 2003 jest domena konta, a domena systemu Windows NT 4.0 jest domeną zasobów. Oznacza to, że domena konta jest zaufana po stronie systemu Windows NT 4.0, a domena zasobu jest zaufana po stronie systemu Windows Server 2003. Takie zachowanie wynika z faktu, że w systemie Windows NT 4.0 proces uruchamiania zaufania po nawiązaniu początkowego połączenia anonimowego jest objęty listą kontroli dostępu za pomocą tokenu Wszyscy zawierającego anonimowy identyfikator SID.

    3. Powody modyfikacji tego ustawienia

       Wartość musi być ustawiona na 0x1 lub ustawiona przy użyciu obiektu zasad grupy w jednostce organizacyjnej kontrolera domeny, aby: Dostęp do sieci: Uprawnienia Zezwalaj wszystkim na stosowanie do użytkowników anonimowych — włączone, aby umożliwić tworzenie zaufania.

       Uwaga W przypadku większości innych ustawień zabezpieczeń wartość tych jest podwyższana zamiast spadać do 0x0 w przypadku ich najbardziej zabezpieczonego stanu. Bezpieczniejszym rozwiązaniem jest zmiana rejestru na emulatorze podstawowego kontrolera domeny zamiast na wszystkich kontrolerach domeny. Jeśli rola emulatora podstawowego kontrolera domeny zostanie przeniesiona z jakiegokolwiek powodu, rejestr musi zostać zaktualizowany na nowym serwerze.

       Po ustawieniu tej wartości wymagane jest ponowne uruchomienie.

    4. Ścieżka rejestru
       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

15. Uwierzytelnianie NTLMv2

    1. Zabezpieczenia sesji

       Zabezpieczenia sesji wyznaczają minimalne standardy zabezpieczeń sesji klienta i serwera. Warto sprawdzić następujące ustawienia zasad zabezpieczeń w przystawce Edytor zasady grupy programu Microsoft Management Console:

       • Ustawienia komputera\Ustawienia systemu Windows\Ustawienia zabezpieczeń\Zasady lokalne\Opcje zabezpieczeń
       • Zabezpieczenia sieci: Minimalne zabezpieczenia sesji dla serwerów opartych na NTLM SSP (w tym bezpieczne RPC)
       • Zabezpieczenia sieci: Minimalne zabezpieczenia sesji dla klientów opartych na protokole NTLM SSP (w tym bezpiecznych RPC)

       Dostępne są następujące opcje tych ustawień:

       • Wymaganie integralności wiadomości
       • Wymaganie poufności wiadomości
       • Wymaganie zabezpieczeń sesji NTLM w wersji 2
       • Wymaganie szyfrowania 128-bitowego

       Ustawieniem domyślnym przed systemem Windows 7 jest Brak wymagań. Począwszy od systemu Windows 7 ustawienie domyślne zostało zmienione na Wymagaj szyfrowania 128-bitowego w celu zwiększenia bezpieczeństwa. Przy tej opcji domyślnej 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 chociaż opisane jako prawidłowe ustawienia, flagi wymagające integralności i poufności wiadomości nie są używane podczas określania zabezpieczeń sesji NTLM.

       W przeszłości system Windows NT obsługiwał następujące dwa warianty uwierzytelniania wyzwań/odpowiedzi podczas logowania w sieci:

       • Wyzwanie/odpowiedź LM
       • NTLM w wersji 1 — wyzwanie/odpowiedź

       LM umożliwia współdziałanie z zainstalowaną bazą klientów i serwerów. Usługa NTLM zapewnia lepsze 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 steruje sposobem obsługi sesji sieciowych zabezpieczonych przy użyciu protokołu NTLM. Dotyczy to na przykład sesji opartych na protokole RPC uwierzytelnionych przy użyciu protokołu NTLM. Wiążą się z tym następujące zagrożenia:

       • Użycie starszych metod uwierzytelniania niż NTLMv2 ułatwia komunikację ze względu na stosowane prostsze metody tworzenia haszowania.
       • Używanie kluczy szyfrowania niższych niż 128-bitowe umożliwia atakującym przerwanie komunikacji za pomocą ataków siłowych.

Synchronizacja czasu

Synchronizacja czasu nie powiodła się. Na komputerze, którego dotyczy problem, czas jest przesunięty o ponad 30 minut. Upewnij się, że zegar klienta jest zsynchronizowany z zegarem kontrolera domeny.

Obejście problemu dotyczącego podpisywania protokołu SMB

Zalecamy zainstalowanie dodatku Service Pack 6a (SP6a) na komputerach klienckich z systemem Windows NT 4.0, które współdziałają w domenie opartej na systemie Windows Server 2003. Klienci korzystający z systemu Windows 98 Second Edition, Windows 98 i Windows 95 muszą mieć uruchomionego klienta usług katalogowych, aby wykonać protokół 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, Windows 98 i Windows 98SE nie mają zainstalowanego klienta usług katalogowych, wyłącz podpisywanie SMB w domyślnym ustawieniu zasad kontrolera domeny w jednostce organizacyjnej kontrolera domeny, a następnie połącz te zasady ze wszystkimi jednostkami organizacyjnymi hostującymi kontrolery domeny.

Klient usług katalogowych dla systemów Windows 98 Wydanie drugie, Windows 98 i Windows 95 będzie wykonywał podpisywanie protokołu SMB z serwerami z systemem Windows 2003 w ramach uwierzytelniania NTLM, ale nie uwierzytelniania NTLMv2. Ponadto serwery z systemem Windows 2000 nie będą odpowiadać na żądania podpisania protokołu SMB od tych klientów.

Chociaż nie jest to zalecane, można zapobiec wymaganiu podpisywania protokołu SMB na wszystkich kontrolerach domeny, na których w domenie działa system Windows Server 2003. 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. Zlokalizuj, a następnie kliknij ustawienie zasad Serwer sieci firmy Microsoft: podpisuj cyfrowo komunikację (zawsze), a następnie kliknij pozycję Wyłączone.

Ważne W tej sekcji, metodzie lub zadaniu podano informacje dotyczące modyfikowania rejestru. Niepoprawne zmodyfikowanie rejestru może jednak być przyczyną poważnych problemów. Dlatego należy uważnie wykonywać podane czynności. Aby zapewnić dodatkową ochronę, przed zmodyfikowaniem rejestru należy wykonać jego kopię zapasową. Dzięki temu będzie można przywrócić rejestr w przypadku wystąpienia problemu. Aby uzyskać więcej informacji dotyczących wykonywania kopii zapasowej i przywracania rejestru, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Baza wiedzy Microsoft Knowledge Base:

322756 Jak wykonać kopię zapasową rejestru i przywrócić go w systemie Windows Ewentualnie wyłącz podpisywanie protokołu 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. Zlokalizuj 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 0, a następnie kliknij przycisk OK.
6. Zamknij Edytor rejestru.
7. Uruchom ponownie komputer lub zatrzymaj, a następnie ponownie uruchom usługę serwera. Aby to zrobić, 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 wspomniane wcześniej dosłowne komunikaty o błędach:

Aby uzyskać więcej informacji, kliknij następujące numery artykułów w celu wyświetlenia tych artykułów z bazy wiedzy Baza wiedzy Microsoft Knowledge Base:

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

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