Podsumowanie
W tym artykule omówiono sposób używania zapewniania ochrony mechanizmów uwierzytelniania (AMA) w interakcyjnych scenariuszach logowania.
Wprowadzenie
Funkcja AMA dodaje wyznaczone przez administratora, uniwersalne członkostwo w grupie do tokenu dostępu użytkownika, gdy poświadczenia użytkownika są uwierzytelniane podczas logowania przy użyciu metody logowania opartej na certyfikacie. Dzięki temu administratorzy zasobów sieciowych mogą kontrolować dostęp do zasobów, takich jak pliki, foldery i drukarki. Ten dostęp zależy od tego, czy użytkownik loguje się przy użyciu metody logowania opartej na certyfikacie i typu certyfikatu używanego do logowania.
W tym artykule
W tym artykule opisano dwa scenariusze problemów: logowanie/wylogowywanie i blokowanie/odblokowywanie. Działanie funkcji AMA w tych scenariuszach jest "zgodne z projektem" i można je podsumować w następujący sposób:
-
Ama ma na celu ochronę zasobów sieciowych.
-
Ama nie może zidentyfikować ani wymusić interakcyjnego typu logowania (karty inteligentnej lub nazwy użytkownika/hasła) na komputerze lokalnym użytkownika. Dzieje się tak dlatego, że zasoby dostępne po interakcyjnym logowaniu użytkownika nie mogą być niezawodnie chronione przy użyciu funkcji AMA.
Symptomy
Scenariusz problemu 1 (logowanie/wylogowanie)
Rozpatrzmy następujący scenariusz:
-
Administrator chce wymusić uwierzytelnianie przy użyciu karty inteligentnej (SC), gdy użytkownicy uzyskują dostęp do niektórych zasobów poufnych pod kontrolą zabezpieczeń. W tym celu administrator wdraża ama zgodnie z zapewnianą gwarancją uwierzytelniania dla usług AD DS w Windows Server 2008 R2 — przewodnik krok po kroku dla identyfikatora obiektu zasad wydawania używanego we wszystkich certyfikatach kart inteligentnych. Uwaga W tym artykule ta nowa zamapowana grupa jest "grupą zabezpieczeń uniwersalnych kart inteligentnych".
-
Zasady "Interakcyjne logowanie: Wymagaj karty inteligentnej" nie są włączone na stacjach roboczych. W związku z tym użytkownicy mogą logować się przy użyciu innych poświadczeń, takich jak nazwa użytkownika i hasło.
-
Dostęp do zasobów lokalnych i sieciowych wymaga grupy zabezpieczeń uniwersalnych karty inteligentnej.
W tym scenariuszu można oczekiwać, że tylko użytkownik, który loguje się przy użyciu kart inteligentnych, może uzyskać dostęp do zasobów lokalnych i sieciowych. Jednak ze względu na to, że stacja robocza umożliwia zoptymalizowane/buforowane logowanie, weryfikator buforowany jest używany podczas logowania do tworzenia tokenu dostępu NT dla pulpitu użytkownika. Dlatego zamiast bieżącego są używane grupy zabezpieczeń i roszczenia z poprzedniego logowania.
Przykłady scenariuszy
Uwaga W tym artykule członkostwo w grupach jest pobierane na potrzeby interakcyjnych sesji logowania przy użyciu "whoami/groups". To polecenie pobiera grupy i roszczenia z tokenu dostępu pulpitu.
-
Przykład 1Jeśli poprzednie logowanie zostało wykonane przy użyciu karty inteligentnej, token dostępu dla pulpitu zawiera grupę zabezpieczeń uniwersalnych karty inteligentnej udostępnioną przez ama. Występuje jeden z następujących wyników:
-
Użytkownik loguje się przy użyciu karty inteligentnej: użytkownik nadal może uzyskać dostęp do lokalnych zasobów poufnych zabezpieczeń. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych wymagających grupy zabezpieczeń uniwersalnych karty inteligentnej. Te próby zakończyły się powodzeniem.
-
Użytkownik loguje się przy użyciu nazwy użytkownika i hasła: użytkownik nadal może uzyskać dostęp do lokalnych zasobów poufnych zabezpieczeń. Ten wynik nie jest oczekiwany. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych wymagających grupy zabezpieczeń uniwersalnych karty inteligentnej. Te próby kończą się niepowodzeniem zgodnie z oczekiwaniami.
-
-
Przykład 2Jeśli poprzednie logowanie zostało wykonane przy użyciu hasła, token dostępu dla pulpitu nie zawiera grupy zabezpieczeń uniwersalnych karty inteligentnej udostępnionej przez ama. Występuje jeden z następujących wyników:
-
Użytkownik loguje się przy użyciu nazwy użytkownika i hasła: Użytkownik nie może uzyskać dostępu do lokalnych zasobów poufnych zabezpieczeń. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych wymagających grupy zabezpieczeń uniwersalnych karty inteligentnej. Te próby kończą się niepowodzeniem.
-
Użytkownik loguje się przy użyciu karty inteligentnej: Użytkownik nie może uzyskać dostępu do lokalnych zasobów poufnych zabezpieczeń. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych. Te próby zakończyły się powodzeniem. Ten wynik nie jest oczekiwany przez klientów. W związku z tym powoduje problemy z kontrolą dostępu.
-
Scenariusz problemu 2 (blokada/odblokowywanie)
Rozważmy następujący scenariusz:
-
Administrator chce wymusić uwierzytelnianie przy użyciu karty inteligentnej (SC), gdy użytkownicy uzyskują dostęp do niektórych zasobów poufnych pod kontrolą zabezpieczeń. W tym celu administrator wdraża ama zgodnie z uwierzytelnianiem Mechanism Assurance dla usług AD DS w Windows Server 2008 R2 Przewodnik krok po kroku dla identyfikatora obiektu zasad wydawania, który jest używany we wszystkich certyfikatach kart inteligentnych.
-
Zasady "Interakcyjne logowanie: Wymagaj karty inteligentnej" nie są włączone na stacjach roboczych. W związku z tym użytkownicy mogą logować się przy użyciu innych poświadczeń, takich jak nazwa użytkownika i hasło.
-
Dostęp do zasobów lokalnych i sieciowych wymaga grupy zabezpieczeń uniwersalnych karty inteligentnej.
W tym scenariuszu można oczekiwać, że tylko użytkownik, który loguje się przy użyciu kart inteligentnych, może uzyskać dostęp do zasobów lokalnych i sieciowych. Jednak token dostępu dla pulpitu użytkownika jest tworzony podczas logowania, nie ulega on zmianie.
Przykłady scenariuszy
-
Przykład 1Jeśli token dostępu dla pulpitu ma grupę zabezpieczeń uniwersalnych kart inteligentnych udostępnianą przez ama, występuje jeden z następujących wyników:
-
Użytkownik odblokowuje się przy użyciu karty inteligentnej: użytkownik nadal może uzyskać dostęp do lokalnych zasobów poufnych zabezpieczeń. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych wymagających grupy zabezpieczeń uniwersalnych karty inteligentnej. Te próby zakończyły się powodzeniem.
-
Użytkownik odblokowuje się przy użyciu nazwy użytkownika i hasła: użytkownik nadal może uzyskać dostęp do lokalnych zasobów poufnych zabezpieczeń. Ten wynik nie jest oczekiwany. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych wymagających grupy zabezpieczeń uniwersalnych karty inteligentnej. Te próby kończą się niepowodzeniem.
-
-
Przykład 2Jeśli token dostępu dla pulpitu nie ma grupy zabezpieczeń uniwersalnych kart inteligentnych udostępnionej przez ama, występuje jeden z następujących wyników:
-
Użytkownik odblokowuje się przy użyciu nazwy użytkownika i hasła: Użytkownik nie może uzyskać dostępu do lokalnych zasobów poufnych zabezpieczeń. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych wymagających grupy zabezpieczeń uniwersalnych karty inteligentnej. Te próby kończą się niepowodzeniem.
-
Użytkownik odblokowuje się przy użyciu karty inteligentnej: Użytkownik nie może uzyskać dostępu do lokalnych zasobów poufnych zabezpieczeń. Ten wynik nie jest oczekiwany. Użytkownik próbuje uzyskać dostęp do zasobów sieciowych. Te próby zakończyły się powodzeniem zgodnie z oczekiwaniami.
-
Więcej informacji
Ze względu na projekt ama i podsystemu zabezpieczeń opisany w sekcji "Symptomy" użytkownicy korzystają z następujących scenariuszy, w których ama nie może niezawodnie zidentyfikować typu logowania interakcyjnego.
Logowanie/wylogowynie
Jeśli optymalizacja szybkiego logowania jest aktywna, podsystem zabezpieczeń lokalnych (lsass) używa lokalnej pamięci podręcznej do generowania członkostwa grupy w tokenie logowania. W ten sposób komunikacja z kontrolerem domeny nie jest wymagana. W związku z tym czas logowania jest skrócony. Jest to bardzo pożądana funkcja.Jednak ta sytuacja powoduje następujący problem: Po logowaniu SC i wylogowaniu sc lokalnie buforowana grupa AMA jest niepoprawnie obecna w tokenie użytkownika po interakcyjnym logowaniu nazwy użytkownika/hasła.Notatki
-
Ta sytuacja dotyczy tylko interakcyjnych logowania.
-
Grupa AMA jest buforowana w taki sam sposób i przy użyciu tej samej logiki co inne grupy.
W takiej sytuacji, jeśli użytkownik spróbuje uzyskać dostęp do zasobów sieciowych, członkostwo w grupie w pamięci podręcznej po stronie zasobu nie zostanie użyte, a sesja logowania użytkownika po stronie zasobu nie będzie zawierać grupy AMA.Ten problem można rozwiązać, wyłączając funkcję optymalizacji szybkiego logowania ("Konfiguracja komputera > Szablony administracyjne > system > logowania > Zawsze czekaj na sieć przy uruchamianiu komputera i logowaniu"). Ważne To zachowanie jest istotne tylko w przypadku interakcyjnego logowania. Dostęp do zasobów sieciowych będzie działać zgodnie z oczekiwaniami, ponieważ nie ma potrzeby optymalizacji logowania. W związku z tym członkostwo w grupach w pamięci podręcznej nie jest używane. Skontaktowano się z kontrolerem domeny w celu utworzenia nowego biletu przy użyciu najnowszych informacji o członkostwie w grupach AMA.
Blokowanie/odblokowywanie
Rozważmy następujący scenariusz:
-
Użytkownik loguje się interakcyjnie przy użyciu karty inteligentnej, a następnie otwiera zasoby sieciowe chronione przez ama.Uwaga Zasoby sieciowe chronione ama mogą być dostępne tylko dla użytkowników, którzy mają grupę AMA w tokenie dostępu.
-
Użytkownik blokuje komputer bez zamykania wcześniej otwartego zasobu sieciowego chronionego ama.
-
Użytkownik odblokowuje komputer, używając nazwy użytkownika i hasła tego samego użytkownika, który wcześniej logował się przy użyciu karty inteligentnej).
W tym scenariuszu użytkownik nadal może uzyskać dostęp do zasobów chronionych ama po odblokowaniu komputera. Takie działanie jest celowe. Po odblokowaniu komputera system Windows nie tworzy ponownie wszystkich otwartych sesji, w których znajdowały się zasoby sieciowe. System Windows również nie sprawdza ponownie członkostwa w grupie. Dzieje się tak dlatego, że działania te spowodowałoby niedopuszczalne kary za wydajność.W tym scenariuszu nie ma żadnego rozwiązania. Jednym z rozwiązań jest utworzenie filtru dostawcy poświadczeń, który odfiltruje dostawcę nazwy użytkownika/hasła po wykonaniu kroków logowania i blokowania SC. Aby dowiedzieć się więcej o dostawcy poświadczeń, zobacz następujące zasoby:
Interfejs ICredentialProviderFilterPrzykłady dostawców poświadczeń systemu Windows VistaUwaga Nie możemy potwierdzić, czy takie podejście kiedykolwiek zostało pomyślnie zaimplementowane.
Więcej informacji o ama
Ama nie może zidentyfikować ani wymusić interakcyjnego typu logowania (karty inteligentnej lub nazwy użytkownika/hasła). Takie działanie jest celowe.Ama jest przeznaczona do scenariuszy, w których zasoby sieciowe wymagają karty inteligentnej. Nie jest przeznaczona do użytku lokalnego.Każda próba rozwiązania tego problemu przez wprowadzenie nowych funkcji, takich jak możliwość używania członkostwa w grupach dynamicznych lub obsługiwania grup AMA jako grupy dynamicznej, może powodować poważne problemy. Dlatego tokeny NT nie obsługują dynamicznych członkostwa w grupach. Jeśli system zezwolił na rzeczywiste obcięcie grup, użytkownicy mogą nie mieć możliwości interakcji z własnym pulpitem i aplikacjami. W związku z tym członkostwa w grupach są zablokowane w momencie tworzenia sesji i są utrzymywane przez całą sesję.Buforowane logowania również są problematyczne. Jeśli zoptymalizowane logowanie jest włączone, system lsass najpierw próbuje lokalnej pamięci podręcznej, zanim wywoła w obie strony sieć. Jeśli nazwa użytkownika i hasło są identyczne z tym, co system lsass widział dla poprzedniego logowania (dotyczy to większości logowania), lsass tworzy token, który ma takie same członkostwa w grupach, jakie użytkownik miał wcześniej. Jeśli zoptymalizowane logowanie jest wyłączone, konieczne będzie użycie łapki sieciowej. Dzięki temu członkowie grupy będą logować się zgodnie z oczekiwaniami.W przypadku logowania w pamięci podręcznej system lsass zachowuje jeden wpis na użytkownika. Ten wpis obejmuje poprzednie członkostwo w grupie użytkownika. Jest to chronione zarówno ostatnim hasłem, jak i poświadczeniami karty inteligentnej, które były wyświetlane w systemie lsass. Oba rozpakuj ten sam token i klucz poświadczeń. Gdyby użytkownicy próbowali zalogować się przy użyciu nieaktualnych kluczy poświadczeń, utraciliby dane DPAPI, zawartość chronioną przez system EFS itd. Dlatego logowania w pamięci podręcznej zawsze dają najnowsze członkostwa w grupach lokalnych, niezależnie od mechanizmu używanego do logowania.
