Udostępnij za pośrednictwem

Migrowanie z federacji do uwierzytelniania opartego na certyfikatach firmy Microsoft (CBA)

  • Artykuł

W tym artykule wyjaśniono, jak przeprowadzić migrację z uruchomionych serwerów federacyjnych, takich jak lokalne usługi Active Directory Federation Services (AD FS) do uwierzytelniania w chmurze przy użyciu uwierzytelniania opartego na certyfikatach firmy Microsoft (CBA).

Wprowadzanie etapowe

Administrator dzierżawy może całkowicie przenieść domenę federacyjną do usługi Microsoft Entra CBA bez przeprowadzania testów pilotażowych. W tym celu należy włączyć metodę uwierzytelniania CBA w identyfikatorze Entra firmy Microsoft i przekonwertować całą domenę na uwierzytelnianie zarządzane. Jeśli jednak klient chce przetestować niewielką grupę użytkowników uwierzytelnianych za pomocą Microsoft Entra CBA przed pełnym przełączeniem domeny na zarządzanie, może skorzystać z funkcji stopniowego wdrażania.

Stopniowe wdrożenie dla uwierzytelniania opartego na certyfikatach (CBA) pomaga klientom przejść z wykonywania CBA u federacyjnego dostawcy tożsamości do Microsoft Entra ID, selektywnie przenosząc mały zestaw użytkowników do korzystania z CBA w Microsoft Entra ID, bez przekierowywania do federacyjnego dostawcy tożsamości, z wybranymi grupami użytkowników, zanim nastąpi konwersja konfiguracji domeny w Microsoft Entra ID z federacyjnej na zarządzaną. Wdrożenie etapowe nie jest przeznaczone dla domeny w celu pozostania w stanie federacji przez długi czas ani dla dużej liczby użytkowników.

Obejrzyj ten szybki film wideo pokazujący migrację z uwierzytelniania opartego na certyfikatach usług AD FS do firmy Microsoft Entra CBA

Uwaga

Gdy wdrożenie etapowe jest włączone dla użytkownika, użytkownik jest uważany za zarządzanego użytkownika, a wszystkie uwierzytelnianie odbywa się w identyfikatorze Entra firmy Microsoft. W przypadku dzierżawcy federacyjnego, jeśli CBA jest włączone w ramach wprowadzania etapowego, uwierzytelnianie hasłem działa tylko wtedy, gdy funkcja PHS również jest włączona. W przeciwnym razie uwierzytelnianie haseł nie powiedzie się.

Włącz etapowe wdrażanie na potrzeby uwierzytelniania opartego na certyfikatach w twojej dzierżawie

Aby skonfigurować wdrożenie etapowe, wykonaj następujące kroki:

  1. Zaloguj się do centrum administracyjnego firmy Microsoft Entra co najmniej jako administrator użytkowników.
  2. Wyszukaj i wybierz pozycję Microsoft Entra Connect.
  3. Na stronie Microsoft Entra Connect w obszarze Etapowe wdrażanie uwierzytelniania w chmurze wybierz pozycję Włącz wdrożenie etapowe dla logowania zarządzanego użytkownika.
  4. Na stronie funkcji włącz wdrażanie etapowe wybierz pozycję W dla opcji uwierzytelnianie oparte na certyfikatach
  5. Wybierz pozycję Zarządzaj grupami i dodaj grupy, które mają być częścią uwierzytelniania w chmurze. Aby uniknąć przekroczenia limitu czasu, upewnij się, że początkowo grupy zabezpieczeń nie zawierają więcej niż 200 członków.

Uwaga

Firma Microsoft zaleca używanie oddzielnych grup do zarządzania wdrożeniem etapowym uwierzytelniania opartego na certyfikatach Firmy Entra oraz zasadami metody uwierzytelniania opartej na certyfikatach

Aby uzyskać więcej informacji, zobacz Wdrażanie etapowe.

Aktualizowanie atrybutu certificateUserIds za pomocą programu Microsoft Entra Connect

Administrator usług AD FS może używać Edytora reguł synchronizacji do tworzenia reguł synchronizujących wartości atrybutów z AD FS do obiektów użytkownika Microsoft Entra. Aby uzyskać więcej informacji, zobacz Reguły synchronizacji dla certificateUserIds.

Program Microsoft Entra Connect wymaga specjalnej roli o nazwie Hybrid Identity Administrator, która przyznaje niezbędne uprawnienia. Musisz mieć tę rolę, aby uzyskać uprawnienia do zapisu nowego atrybutu chmury.

Uwaga

Jeśli użytkownik używa zsynchronizowanych atrybutów, takich jak atrybut onPremisesUserPrincipalName w obiekcie użytkownika do powiązania nazwy użytkownika, każdy użytkownik, który ma dostęp administracyjny do serwera Microsoft Entra Connect, może zmienić zsynchronizowane mapowanie atrybutów i zmienić wartość zsynchronizowanego atrybutu. Użytkownik nie musi być administratorem chmury. Administrator usług AD FS powinien upewnić się, że dostęp administracyjny do serwera Microsoft Entra Connect powinien być ograniczony, a uprzywilejowane konta powinny być kontami tylko w chmurze.

Często zadawane pytania dotyczące migracji z usług AD FS do identyfikatora Entra firmy Microsoft

Czy można mieć uprzywilejowane konta z federacyjnym serwerem usług AD FS?

Chociaż jest to możliwe, firma Microsoft zaleca, aby uprzywilejowane konta to konta tylko w chmurze. Używanie kont w chmurze wyłącznie do dostępu uprzywilejowanego ogranicza ryzyko w identyfikatorze Microsoft Entra z naruszonego środowiska lokalnego. Aby uzyskać więcej informacji, zobacz Ochrona platformy Microsoft 365 przed atakami lokalnymi.

Jeśli organizacja jest hybrydą z usługami AD FS i Azure CBA, czy nadal są narażone na naruszenie zabezpieczeń usług AD FS?

Firma Microsoft zaleca uprzywilejowane konta tylko w chmurze. Ta praktyka ogranicza ekspozycję w Microsoft Entra ID z naruszonego środowiska lokalnego. Utrzymywanie uprzywilejowanych kont tylko w chmurze jest podstawą tego celu.

W przypadku zsynchronizowanych kont:

  • Jeśli znajdują się w domenie zarządzanej (nie federowanej), nie ma ryzyka ze strony federacyjnego dostawcy tożsamości.
  • Jeśli są one w domenie federacyjnej, ale podzbiór kont jest przenoszony do Microsoft Entra CBA przez Staged Rollout, podlegają one zagrożeniom związanym z federacyjnym dostawcą tożsamości, dopóki domena federacyjna nie zostanie w pełni przełączona na uwierzytelnianie w chmurze.

Czy organizacje powinny wyeliminować serwery federacyjne, takie jak usługi AD FS, aby zapobiec możliwości przestawiania z usług AD FS na platformę Azure?

W przypadku federacji osoba atakująca może podszywać się pod każdego, na przykład pod CIO, nawet jeśli nie może uzyskać roli, która istnieje tylko w chmurze, takiej jak konto administratora o wysokich uprawnieniach.

Gdy domena jest sfederowana w Microsoft Entra ID, pokłada się wysoki poziom zaufania we federacyjnym dostawcy tożsamości. Usługi AD FS są jednym z przykładów, ale pojęcie dotyczy dowolnego federacyjnego IdP. Wiele organizacji wdraża Federacyjnego dostawcę tożsamości (IdP) takiego jak AD FS wyłącznie w celu przeprowadzenia uwierzytelniania opartego na certyfikatach. Microsoft Entra CBA całkowicie eliminuje zależność od AD FS w tym przypadku. Dzięki firmie Microsoft Entra CBA klienci mogą przenosić swoje zasoby aplikacji do usługi Microsoft Entra ID, aby zmodernizować infrastrukturę zarządzania dostępem i tożsamościami oraz obniżyć koszty dzięki zwiększonemu bezpieczeństwu.

Z perspektywy bezpieczeństwa nie ma żadnych zmian w poświadczeniach, w tym w certyfikacie X.509, kartach CAC, kartach PIV itp., ani w używanej infrastrukturze kluczy publicznych (PKI). Właściciele infrastruktury kluczy publicznych zachowują pełną kontrolę nad wystawianiem i odwoływaniem certyfikatów oraz zasadami. Sprawdzanie odwołania i uwierzytelnianie odbywa się w Microsoft Entra ID zamiast u federowanego dostawcy tożsamości. Te kontrole umożliwiają uwierzytelnianie bez hasła, odporne na wyłudzanie informacji, bezpośrednio do Microsoft Entra ID dla wszystkich użytkowników.

Jak uwierzytelnianie działa z federacyjnymi usługami AD FS i uwierzytelnianiem w chmurze Firmy Microsoft w systemie Windows?

Firma Microsoft Entra CBA wymaga od użytkownika lub aplikacji podania UPN Microsoft Entra użytkownika, który się loguje.

W przykładzie przeglądarki użytkownik najczęściej wpisuje swój UPN Microsoft Entra. UPN Microsoft Entra jest używany do odnajdywania domeny i użytkownika. Użyty certyfikat musi być zgodny z tym użytkownikiem przy użyciu jednego ze skonfigurowanych powiązań nazwy użytkownika w zasadach.

W procesie logowania do systemu Windows dopasowanie zależy od tego, czy urządzenie jest połączone hybrydowo, czy połączone z usługą Microsoft Entra. Jednak w obu przypadkach, jeśli podano podpowiedź nazwy użytkownika, system Windows wysyła tę podpowiedź jako identyfikator UPN Microsoft Entra. Użyty certyfikat musi być zgodny z tym użytkownikiem przy użyciu jednego ze skonfigurowanych powiązań nazwy użytkownika w zasadach.

Następne kroki