Szczegółowe informacje techniczne dotyczące uwierzytelniania opartego na certyfikatach firmy Microsoft

W tym artykule wyjaśniono, jak działa uwierzytelnianie oparte na certyfikatach firmy Microsoft (CBA) i szczegółowe informacje techniczne dotyczące konfiguracji microsoft Entra CBA.

Jak działa uwierzytelnianie oparte na certyfikatach firmy Microsoft?

Na poniższej ilustracji opisano, co się stanie, gdy użytkownik próbuje zalogować się do aplikacji w dzierżawie, w której włączono usługę Microsoft Entra CBA.

Teraz przejdziemy przez każdy krok:

1. Użytkownik próbuje uzyskać dostęp do aplikacji, takiej jak portal MyApps.

2. Jeśli użytkownik nie jest jeszcze zalogowany, użytkownik jest przekierowywany do strony logowania użytkownika Microsoft Entra ID pod adresem https://login.microsoftonline.com/.

3. Użytkownik wprowadza swoją nazwę użytkownika na stronie logowania firmy Microsoft Entra, a następnie wybiera pozycję Dalej. Identyfikator Entra firmy Microsoft umożliwia odnajdywanie obszaru macierzystego przy użyciu nazwy dzierżawy, a nazwa użytkownika jest używana do wyszukiwania użytkownika w dzierżawie.

   

4. Microsoft Entra ID sprawdza, czy cba jest włączona dla dzierżawy. Jeśli usługa CBA jest włączona, użytkownik zobaczy link Do korzystania z certyfikatu lub karty inteligentnej na stronie hasła. Jeśli użytkownik nie widzi linku logowania, upewnij się, że usługa CBA jest włączona w dzierżawie. Aby uzyskać więcej informacji, zobacz Jak mogę enable Microsoft Entra CBA?.

   Uwaga

   Jeśli usługa CBA jest włączona w dzierżawie, wszyscy użytkownicy zobaczą link Użyj certyfikatu lub karty inteligentnej na stronie hasła. Jednak tylko użytkownicy w zakresie cba mogą pomyślnie uwierzytelniać się w aplikacji, która używa identyfikatora Microsoft Entra jako dostawcy tożsamości.

   

   Jeśli włączono inne metody uwierzytelniania, takie jak Telefon logowanie lub klucze zabezpieczeń, użytkownicy mogą zobaczyć inny ekran logowania.

   

5. Gdy użytkownik wybierze uwierzytelnianie oparte na certyfikatach, klient zostanie przekierowany do punktu końcowego uwierzytelniania certyfikatu, który jest https://certauth.login.microsoftonline.com przeznaczony dla publicznego identyfikatora Entra. W przypadku platformy Azure Government punkt końcowy uwierzytelniania certyfikatu to https://certauth.login.microsoftonline.us.

   Punkt końcowy wykonuje wzajemne uwierzytelnianie TLS i żąda certyfikatu klienta w ramach uzgadniania protokołu TLS. Wpis dla tego żądania zostanie wyświetlony w dzienniku logowania.

   Uwaga

   Administrator sieci powinien zezwolić na dostęp do strony logowania użytkownika i punktu końcowego *.certauth.login.microsoftonline.com uwierzytelniania certyfikatu dla środowiska chmury klienta. Wyłącz inspekcję protokołu TLS w punkcie końcowym uwierzytelniania certyfikatu, aby upewnić się, że żądanie certyfikatu klienta zakończy się powodzeniem w ramach uzgadniania protokołu TLS.

   Upewnij się, że wyłączenie inspekcji protokołu TLS działa również dla nowego adresu URL z wskazówkami wystawcy. Nie zakoduj adresu URL za pomocą identyfikatora tenantId, ponieważ może to ulec zmianie dla użytkowników B2B. Użyj wyrażenia regularnego, aby umożliwić działanie zarówno starego, jak i nowego adresu URL na potrzeby wyłączania inspekcji protokołu TLS. Na przykład w zależności od serwera proxy użyj polecenia *.certauth.login.microsoftonline.com lub *certauth.login.microsoftonline.com. W usłudze Azure Government użyj polecenia *.certauth.login.microsoftonline.us lub *certauth.login.microsoftonline.us.

   Jeśli dostęp nie jest dozwolony, uwierzytelnianie oparte na certyfikatach nie powiedzie się, jeśli włączysz funkcję wskazówek zaufanego urzędu certyfikacji.

6. Identyfikator Entra firmy Microsoft żąda certyfikatu klienta. Użytkownik wybiera certyfikat klienta i wybiera przycisk OK.

   Uwaga

   Wskazówki dotyczące zaufanego urzędu certyfikacji nie są obsługiwane, więc nie można dalej określać zakresu listy certyfikatów. W przyszłości przyjrzymy się dodaniu tej funkcji.

   

7. Microsoft Entra ID weryfikuje listę odwołania certyfikatów, aby upewnić się, że certyfikat nie został odwołany i jest prawidłowy. Identyfikator entra firmy Microsoft identyfikuje użytkownika przy użyciu powiązania nazwy użytkownika skonfigurowanego w dzierżawie w celu zamapowania wartości pola certyfikatu na wartość atrybutu użytkownika.

8. Jeśli unikatowy użytkownik zostanie znaleziony z zasadami dostępu warunkowego, które wymagają uwierzytelniania wieloskładnikowego, a reguła powiązania uwierzytelniania certyfikatu spełnia uwierzytelnianie wieloskładnikowe, identyfikator Firmy Microsoft loguje użytkownika natychmiast. Jeśli uwierzytelnianie wieloskładnikowe jest wymagane, ale certyfikat spełnia tylko jeden czynnik, logowanie bez hasła lub FIDO2 jest oferowane jako drugi czynnik, jeśli zostały już zarejestrowane.

9. Identyfikator Entra firmy Microsoft kończy proces logowania, wysyłając podstawowy token odświeżania z powrotem w celu wskazania pomyślnego logowania.

10. Jeśli logowanie użytkownika zakończy się pomyślnie, użytkownik będzie mógł uzyskać dostęp do aplikacji.

Uwierzytelnianie oparte na certyfikatach obsługuje uwierzytelnianie wieloskładnikowe

Usługa Microsoft Entra CBA może uwierzytelnianie wieloskładnikowe (MFA). Usługa Microsoft Entra CBA może być jednoskładnikowa (SF) lub wieloskładnikowa (MF) w zależności od konfiguracji dzierżawy. Włączenie cba sprawia, że użytkownik może ukończyć uwierzytelnianie wieloskładnikowe. Użytkownik może potrzebować większej liczby konfiguracji w celu ukończenia uwierzytelniania wieloskładnikowego i weryfikacji w celu zarejestrowania innych metod uwierzytelniania, gdy użytkownik znajduje się w zakresie cba.

Jeśli użytkownik z włączoną usługą CBA ma tylko certyfikat pojedynczego składnika (SF) i musi wykonać uwierzytelnianie wieloskładnikowe:

1. Użyj hasła i certyfikatu SF.
2. Wystawianie tymczasowego dostępu — przekazywanie.
3. Zasady uwierzytelniania Administracja istrator dodaje numer telefonu i zezwala na uwierzytelnianie wiadomości głosowych/tekstowych dla konta użytkownika.

Jeśli użytkownik z obsługą cba nie został jeszcze wystawiony certyfikat i musi ukończyć uwierzytelnianie wieloskładnikowe:

1. Wystawianie tymczasowego dostępu — przekazywanie.
2. Zasady uwierzytelniania Administracja istrator dodaje numer telefonu i zezwala na uwierzytelnianie wiadomości głosowych/tekstowych dla konta użytkownika.

Jeśli użytkownik z włączoną usługą CBA nie może użyć certyfikatu MF, takiego jak na urządzeniu przenośnym bez obsługi karty inteligentnej i musi ukończyć uwierzytelnianie wieloskładnikowe:

1. Wystawianie tymczasowego dostępu — przekazywanie.
2. Użytkownik musi zarejestrować inną metodę uwierzytelniania wieloskładnikowego (gdy użytkownik może użyć certyfikatu MF).
3. Użyj hasła i certyfikatu MF (gdy użytkownik może użyć certyfikatu MF).
4. Zasady uwierzytelniania Administracja istrator dodaje numer telefonu i zezwala na uwierzytelnianie wiadomości głosowych/tekstowych dla konta użytkownika.

Uwierzytelnianie wieloskładnikowe z uwierzytelnianiem opartym na certyfikatach jednoskładnikowych (wersja zapoznawcza)

Firma Microsoft Entra CBA może służyć jako drugi czynnik, aby spełnić wymagania uwierzytelniania wieloskładnikowego z certyfikatami jednoskładnikowymi. Niektóre z obsługiwanych kombinacji to:

1. CBA (pierwszy czynnik) i logowanie za pomocą telefonu bez hasła (logowanie bez hasła jako drugi czynnik)
2. CBA (pierwszy czynnik) i klucze zabezpieczeń FIDO2 (drugi czynnik)
3. Hasło (pierwszy czynnik) i CBA (drugi czynnik)

Użytkownicy muszą mieć inny sposób na uzyskanie uwierzytelniania wieloskładnikowego i zarejestrowanie logowania bez hasła lub fiDO2 z wyprzedzeniem w celu zalogowania się w usłudze Microsoft Entra CBA.

Ważne

Użytkownik jest uważany za zdolny do uwierzytelniania wieloskładnikowego, jeśli są one uwzględnione w ustawieniach metody CBA. Oznacza to, że użytkownik nie może użyć weryfikacji w ramach uwierzytelniania w celu zarejestrowania innych dostępnych metod. Upewnij się, że użytkownicy bez ważnego certyfikatu nie są uwzględniani w ustawieniach metody CBA. Aby uzyskać więcej informacji na temat sposobu działania uwierzytelniania, zobacz Microsoft Entra multifactor authentication (Uwierzytelnianie wieloskładnikowe firmy Microsoft).

Procedura konfigurowania logowania za pomocą telefonu bez hasła (PSI) przy użyciu cba

Aby logowanie bez hasła działało, użytkownicy powinni wyłączyć starsze powiadomienia za pośrednictwem aplikacji mobilnej.

1. Zaloguj się do centrum administracyjnego firmy Microsoft Entra jako co najmniej Administracja istrator zasad uwierzytelniania.

2. Wykonaj kroki opisane w artykule Włączanie uwierzytelniania za pomocą logowania bez hasła na telefon.

   Ważne

   W poprzedniej konfiguracji upewnij się, że wybrano opcję Bez hasła . Musisz zmienić tryb uwierzytelniania dla wszystkich grup dodanych dla interfejsu PSI na bez hasła. Jeśli wybierzesz opcję Dowolne, CBA i PSI nie działają.

3. Wybierz pozycję Ochrona>uwierzytelniania wieloskładnikowego Dodatkowe ustawienia uwierzytelniania>wieloskładnikowego opartego na chmurze.

   

4. W obszarze Opcje weryfikacji wyczyść pole Powiadomienie za pośrednictwem aplikacji mobilnej i wybierz pozycję Zapisz.

   

Przepływ uwierzytelniania wieloskładnikowego przy użyciu certyfikatów jednoskładnikowych i logowania bez hasła

Przyjrzyjmy się przykładowi użytkownika, który ma certyfikat jednoskładnikowy i jest skonfigurowany do logowania bez hasła.

1. Wprowadź nazwę główną użytkownika (UPN) i wybierz przycisk Dalej.

   

2. Wybierz pozycję Zaloguj się przy użyciu certyfikatu.

   

   Jeśli włączono inne metody uwierzytelniania, takie jak Telefon logowanie lub klucze zabezpieczeń FIDO2, użytkownicy mogą zobaczyć inny ekran logowania.

   

3. Wybierz prawidłowy certyfikat użytkownika w selektorze certyfikatów klienta i wybierz przycisk OK.

   

4. Ponieważ certyfikat jest skonfigurowany jako siła uwierzytelniania jednoskładnikowego, użytkownik potrzebuje drugiego czynnika, aby spełnić wymagania uwierzytelniania wieloskładnikowego. Użytkownik widzi dostępne drugie czynniki, które w tym przypadku to logowanie bez hasła. Wybierz pozycję Zatwierdź żądanie w mojej aplikacji Microsoft Authenticator.

   

5. Otrzymasz powiadomienie na telefonie. Wybierz pozycję Zatwierdź logowanie?.

6. Wprowadź numer widoczny na ekranie przeglądarki lub aplikacji w aplikacji Microsoft Authenticator.

   

7. Wybierz pozycję Tak , a użytkownik może uwierzytelnić się i zalogować.

Opis zasad powiązania uwierzytelniania

Zasady powiązania uwierzytelniania pomagają określić siłę uwierzytelniania jako jednoskładnikowy lub wieloskładnikowy. Administrator może zmienić wartość domyślną z pojedynczego czynnika na wieloskładnikową lub skonfigurować konfiguracje zasad niestandardowych przy użyciu pól identyfikatora OID podmiotu wystawcy lub zasad lub wystawcy i identyfikatora OID zasad w certyfikacie.

Mocne strony certyfikatu

Administrator może określić, czy certyfikaty są siłą jednoskładnikową, czy wieloskładnikową. Aby uzyskać więcej informacji, zobacz dokumentację, która mapuje poziomy UWIERZYTELNIANIA NIST na metody uwierzytelniania Entra firmy Microsoft, która opiera się na NIST 800-63B SP 800-63B, Wytyczne dotyczące tożsamości cyfrowej: Uwierzytelnianie i cykl życia Mgmt.

Uwierzytelnianie za pomocą certyfikatu wieloskładnikowego

Gdy użytkownik ma certyfikat wieloskładnikowy, może wykonywać uwierzytelnianie wieloskładnikowe tylko przy użyciu certyfikatów. Jednak Administracja istrator zasad uwierzytelniania powinien upewnić się, że certyfikaty są chronione przy użyciu numeru PIN lub biometrycznego, które mają być traktowane jako wieloskładnikowe.

Jak identyfikator Entra firmy Microsoft rozpoznaje wiele reguł powiązań zasad uwierzytelniania

Ponieważ można utworzyć wiele niestandardowych reguł zasad powiązania uwierzytelniania z różnymi polami certyfikatów, takimi jak używanie identyfikatora wystawcy i identyfikatora OID zasad lub tylko wystawcy. poniżej przedstawiono kroki używane do określania poziomu ochrony uwierzytelniania, gdy reguły niestandardowe nakładają się na siebie. Są one następujące:

1. Reguły identyfikatora OID wystawcy i zasad mają pierwszeństwo przed regułami identyfikatorów OID zasad. Reguły identyfikatora OID zasad mają pierwszeństwo przed regułami wystawcy certyfikatów.
2. Najpierw oceniane są reguły identyfikatorów OID wystawcy i zasad. Jeśli masz regułę niestandardową z urzędem certyfikacji wystawcy CA1 i identyfikatorem OID zasad 1.2.3.4.5 z uwierzytelnianiem wieloskładnikowym, tylko certyfikat A spełnia zarówno wartość wystawcy, jak i identyfikator OID zasad będą miały uwierzytelnianie wieloskładnikowe.
3. Następnie są oceniane reguły niestandardowe korzystające z identyfikatorów OID zasad. Jeśli masz certyfikat A z identyfikatorem OID zasad 1.2.3.4.5 i pochodne poświadczenie B na podstawie tego certyfikatu ma identyfikator OID zasad 1.2.3.4.5.6, a reguła niestandardowa jest zdefiniowana jako identyfikator OID zasad z wartością 1.2.3.4.5 z uwierzytelnianiem wieloskładnikowym, tylko certyfikat A spełnia uwierzytelnianie wieloskładnikowe, a poświadczenie B spełnia tylko uwierzytelnianie jednoskładnikowe. Jeśli użytkownik użył pochodnego poświadczenia podczas logowania i został skonfigurowany do uwierzytelniania wieloskładnikowego, użytkownik zostanie poproszony o drugi czynnik pomyślnego uwierzytelnienia.
4. Jeśli występuje konflikt między wieloma identyfikatorami operacyjnego zasad (na przykład gdy certyfikat ma dwa identyfikatory operacyjnego zasad, gdzie jeden jest powiązany z uwierzytelnianiem jednoskładnikowym, a drugi wiąże się z uwierzytelnianiem wieloskładnikowym), należy traktować certyfikat jako uwierzytelnianie jednoskładnikowe.
5. Następnie są oceniane reguły niestandardowe używające urzędu certyfikacji wystawcy.
6. Jeśli certyfikat ma zarówno identyfikator OID zasad, jak i zgodne reguły wystawcy, identyfikator OID zasad jest zawsze sprawdzany jako pierwszy, a jeśli żadna reguła zasad nie zostanie znaleziona, to powiązania wystawcy są sprawdzane. Identyfikator OID zasad ma wyższy priorytet powiązania silnego uwierzytelniania niż wystawca.
7. Jeśli jeden urząd certyfikacji wiąże się z uwierzytelnianiem wieloskładnikowym, wszystkie certyfikaty użytkowników wystawiane przez urząd certyfikacji kwalifikują się jako uwierzytelnianie wieloskładnikowe. Ta sama logika ma zastosowanie do uwierzytelniania jednoskładnikowego.
8. Jeśli jeden identyfikator OID zasad jest powiązany z uwierzytelnianiem wieloskładnikowym, wszystkie certyfikaty użytkowników, które zawierają ten identyfikator OID zasad jako jeden z identyfikatorów OID (certyfikat użytkownika może mieć wiele identyfikatorów OID zasad) kwalifikują się jako uwierzytelnianie wieloskładnikowe.
9. Jeden wystawca certyfikatu może mieć tylko jedno prawidłowe powiązanie silnego uwierzytelniania (czyli certyfikat nie może wiązać się zarówno z jednym czynnikiem, jak i uwierzytelnianiem wieloskładnikowym).

Ważne

Istnieje znany problem polegający na tym, że administrator dzierżawy entra konfiguruje regułę zasad uwierzytelniania CBA przy użyciu identyfikatora OID wystawcy i identyfikatora OID zasad ma wpływ na niektóre scenariusze rejestracji urządzeń, w tym:

• Rejestracja w usłudze Windows Hello dla firm
• Rejestracja klucza zabezpieczeń Fido2
• Logowanie bez hasła systemu Windows Telefon

Nie ma to wpływu na rejestrację urządzeń przy użyciu funkcji Dołączanie w miejscu pracy, identyfikatora Entra i hybrydowego identyfikatora urządzenia. Reguły zasad uwierzytelniania CBA przy użyciu identyfikatora OID wystawcy LUB zasad nie mają wpływu. Aby rozwiązać ten problem, administratorzy powinni:

• Edytuj reguły zasad uwierzytelniania oparte na certyfikatach obecnie przy użyciu opcji wystawcy i identyfikatora OID zasad, a następnie usuń wymaganie wystawcy lub identyfikatora OID i zapisz. LUB
• Usuń regułę zasad uwierzytelniania obecnie przy użyciu identyfikatora OID wystawcy i zasad oraz utwórz reguły przy użyciu tylko identyfikatora OID wystawcy lub zasad

Pracujemy nad rozwiązaniem problemu.

Opis zasad powiązania nazwy użytkownika

Zasady powiązania nazwy użytkownika pomagają zweryfikować certyfikat użytkownika. Domyślnie główna nazwa podmiotu (SAN) w certyfikacie jest mapowana na atrybut UserPrincipalName obiektu użytkownika w celu określenia użytkownika.

Osiąganie wyższych zabezpieczeń za pomocą powiązań certyfikatów

Istnieją siedem obsługiwanych metod powiązań certyfikatów. Ogólnie rzecz biorąc, typy mapowań są uważane za wysoką koligację, jeśli są oparte na identyfikatorach, których nie można użyć ponownie, takich jak identyfikatory klucza podmiotu lub klucz publiczny SHA1. Te identyfikatory zapewniają większą pewność, że tylko jeden certyfikat może służyć do uwierzytelniania odpowiedniego użytkownika.

Typy mapowań oparte na nazwach użytkowników i adresach e-mail są uważane za niską koligację. Identyfikator Entra firmy Microsoft implementuje trzy mapowania uważane za niskie koligację na podstawie identyfikatorów wielokrotnego użytku. Pozostałe są uznawane za powiązania o wysokiej koligacji. Aby uzyskać więcej informacji, zobacz certificateUserIds.

Pole mapowania certyfikatu	Przykłady wartości w identyfikatorach certificateUserId	Atrybuty obiektu użytkownika	Typ
NazwaGłówna	X509:<PN>bob@woodgrove.com	Userprincipalname onPremisesUserPrincipalName certificateUserIds	koligacja o niskiej koligacji
RFC822Name	X509:<RFC822>user@woodgrove.com	Userprincipalname onPremisesUserPrincipalName certificateUserIds	koligacja o niskiej koligacji
IssuerAndSubject (wersja zapoznawcza)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	koligacja o niskiej koligacji
Temat (wersja zapoznawcza)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	koligacja o niskiej koligacji
NARCIARSKIE	X509:<SKI>123456789abcdef	certificateUserIds	wysoka koligacja
SHA1PublicKey	X509:<SHA1-PUKEY>123456789abcdef	certificateUserIds	wysoka koligacja
IssuerAndSerialNumber (wersja zapoznawcza)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48 Aby uzyskać poprawną wartość numeru seryjnego, uruchom to polecenie i zapisz wartość wyświetlaną w polach CertificateUserIds: Składnia: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Przykład: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	wysoka koligacja

Definiowanie powiązania koligacji na poziomie dzierżawy i zastępowanie ich regułami niestandardowymi (wersja zapoznawcza)

Dzięki tej funkcji Administracja istrator zasad uwierzytelniania może skonfigurować, czy użytkownik może być uwierzytelniony przy użyciu mapowania powiązań nazwy użytkownika o niskiej koligacji lub wysokiej koligacji. Dla dzierżawy można ustawić wymagane powiązanie koligacji, które ma zastosowanie do wszystkich użytkowników. Możesz również zastąpić wartość domyślną dla całej dzierżawy, tworząc reguły niestandardowe na podstawie identyfikatora OID wystawcy i zasad lub identyfikatora OID zasad lub wystawcy.

Jak identyfikator Entra firmy Microsoft rozpoznaje wiele reguł powiązań zasad nazwy użytkownika

Użyj powiązania o najwyższym priorytcie (najniższej liczbie).

1. Wyszukaj obiekt użytkownika przy użyciu nazwy użytkownika lub głównej nazwy użytkownika.
2. Pobierz listę wszystkich powiązań nazw użytkowników skonfigurowanych przez administratora dzierżawy w konfiguracji metody uwierzytelniania CBA uporządkowanej według atrybutu "priority". Obecnie koncepcja priorytetu nie jest uwidoczniona w środowisku użytkownika portalu. Graf zwróci atrybut priorytetu dla każdego powiązania i są one używane w procesie oceny.
3. Jeśli dzierżawa ma włączone powiązanie o wysokiej koligacji lub jeśli wartość certyfikatu jest zgodna z regułą niestandardową, która wymaga powiązania wysokiej koligacji, usuń wszystkie powiązania o niskiej koligacji z listy.
4. Oceń każde powiązanie na liście do momentu pomyślnego uwierzytelnienia.
5. Jeśli pole certyfikatu X.509 skonfigurowanego powiązania znajduje się na przedstawionym certyfikacie, identyfikator Entra firmy Microsoft pasuje do wartości w polu certyfikatu do wartości atrybutu obiektu użytkownika.
   1. Jeśli zostanie znalezione dopasowanie, uwierzytelnianie użytkownika zakończy się pomyślnie.
   2. Jeśli dopasowanie nie zostanie znalezione, przejdź do następnego powiązania priorytetu.
6. Jeśli pole certyfikatu X.509 nie znajduje się w przedstawionym certyfikacie, przejdź do następnego powiązania priorytetu.
7. Zweryfikuj wszystkie skonfigurowane powiązania nazw użytkowników, dopóki jeden z nich nie powiedzie się, a uwierzytelnienie użytkownika zakończy się pomyślnie.
8. Jeśli dopasowanie nie zostanie znalezione w żadnym ze skonfigurowanych powiązań nazwy użytkownika, uwierzytelnianie użytkownika zakończy się niepowodzeniem.

Zabezpieczanie konfiguracji firmy Microsoft Entra przy użyciu wielu powiązań nazwy użytkownika

Każdy z atrybutów obiektu użytkownika entra firmy Microsoft (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) dostępnych do powiązania certyfikatów z kontami użytkowników firmy Microsoft Entra ma unikatowe ograniczenie, aby upewnić się, że certyfikat jest zgodny tylko z pojedynczym kontem użytkownika firmy Microsoft Entra. Jednak firma Microsoft Entra CBA obsługuje wiele metod powiązań w zasadach powiązania nazwy użytkownika, które umożliwiają administratorowi dostosowanie jednego certyfikatu do wielu konfiguracji kont użytkowników entra.

Ważne

Jeśli skonfigurujesz wiele powiązań, uwierzytelnianie microsoft Entra CBA jest bezpieczne tylko jako najniższe powiązanie koligacji, ponieważ cbA weryfikuje każde powiązanie w celu uwierzytelnienia użytkownika. Aby zapobiec scenariuszowi, w którym jeden certyfikat jest zgodny z wieloma kontami firmy Microsoft Entra, Administracja istrator zasad uwierzytelniania może:

• Skonfiguruj pojedynczą metodę powiązania w zasadach powiązania nazwy użytkownika.
• Jeśli dzierżawa ma skonfigurowaną wiele metod powiązań i nie chce zezwalać na mapowanie jednego certyfikatu na wiele kont, Administracja istrator zasad uwierzytelniania musi upewnić się, że wszystkie dozwolone metody skonfigurowane w mapie zasad na to samo konto Microsoft Entra. Wszystkie konta użytkowników powinny mieć wartości pasujące do wszystkich powiązań.
• Jeśli dzierżawa ma skonfigurowane wiele metod powiązań, Administracja istrator zasad uwierzytelniania powinien upewnić się, że nie ma więcej niż jednego powiązania z niską koligacją.

Załóżmy na przykład, że masz dwa powiązania nazwy użytkownika dla nazwy PrincipalName zamapowane na nazwy UPN i SubjectKeyIdentifier (SKI) na certificateUserIds. Jeśli chcesz, aby certyfikat był używany tylko dla jednego konta, Administracja istrator zasad uwierzytelniania musi upewnić się, że konto ma nazwę UPN, która znajduje się w certyfikacie, i zaimplementować mapowanie ski w atrybucie certificateUserId tego samego konta.

Obsługa wielu certyfikatów przy użyciu jednego konta użytkownika Entra (M:1)

Istnieją scenariusze, w których organizacja wystawia wiele certyfikatów dla jednej tożsamości. Najczęściej może to być pochodne poświadczenie dla urządzenia przenośnego lub może dotyczyć pomocniczej karty inteligentnej lub urządzenia obsługującego poświadczenia x509, takiego jak Yubikey.

Konta tylko w chmurze Dla kont tylko w chmurze można mapować wiele certyfikatów (do 5) do użycia, wypełniając pole certificateUserIds (informacje o autoryzacji w portalu użytkowników) z unikatowymi wartościami identyfikującymi każdy certyfikat. Jeśli organizacja używa powiązań o wysokiej koligacji, powiedz wystawca + numer seryjny, wartości w polach CertificateUserIds mogą wyglądać następująco:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

W tym przykładzie pierwsza wartość reprezentuje X509Certificate1, a druga wartość reprezentuje X509Certificate2. Użytkownik może przedstawić jeden z certyfikatów podczas logowania i tak długo, jak powiązanie nazwy użytkownika CBA jest ustawione, aby wskazać pole certificateUserIds, aby wyszukać określony typ powiązania (tj. Wystawca+Numer seryjny w tym przykładzie), a następnie użytkownik pomyślnie się zaloguje.

Konta zsynchronizowane hybrydowe Dla zsynchronizowanych kont można mapować wiele certyfikatów do użycia, wypełniając pole altSecurityIdentities w usłudze AD wartości identyfikujące każdy certyfikat. Jeśli organizacja korzysta z powiązań o wysokiej koligacji (tj. silnego uwierzytelniania), oznacza to, że wystawca i numer seryjny mogą wyglądać następująco:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

W tym przykładzie pierwsza wartość reprezentuje X509Certificate1, a druga wartość reprezentuje X509Certificate2. Te wartości należy następnie zsynchronizować z polem certificateUserIds w usłudze Azure AD.

Obsługa jednego certyfikatu z wieloma kontami użytkowników Entra (1:M)

Istnieją scenariusze, w których organizacja potrzebuje użytkownika do uwierzytelniania w wielu tożsamościach przy użyciu tego samego certyfikatu. Najczęściej dotyczy to kont administracyjnych. Może to być również dla kont deweloperów lub tymczasowych kont celnych. W tradycyjnej usłudze AD pole altSecurityIdentities służy do wypełniania wartości certyfikatu, a wskazówka jest używana podczas logowania, aby skierować usługę AD do żądanego konta w celu sprawdzenia logowania. W przypadku firmy Microsoft Entra CBA jest to inne i nie ma wskazówki. Zamiast tego odnajdywanie obszaru głównego identyfikuje żądane konto w celu sprawdzenia wartości certyfikatu. Inną kluczową różnicą jest to, że usługa Microsoft Entra CBA wymusza unikatowość w polu certificateUserIds. Oznacza to, że dwa konta nie mogą wypełnić tych samych wartości certyfikatu.

Ważne

Nie jest to bardzo bezpieczna konfiguracja, aby używać tych samych poświadczeń do uwierzytelniania na różnych kontach identyfikatorów Entra i zaleca się, aby nie zezwalać na jeden certyfikat dla wielu kont użytkowników entra.

Konta tylko w chmurze Dla kont tylko w chmurze należy utworzyć wiele powiązań nazw użytkowników i muszą mapować unikatowe wartości na każde konto użytkownika, które będzie używać certyfikatu. Każde konto zostanie uwierzytelnione przy użyciu innego powiązania nazwy użytkownika. Dotyczy to granic pojedynczego katalogu/dzierżawy (tj. administrator dzierżawy może mapować certyfikat do użycia w innym katalogu/dzierżawie, tak długo, jak wartości pozostają unikatowe na konto).

Wypełnij pole certificateUserIds (informacje o autoryzacji w portalu użytkowników) unikatową wartością identyfikującą żądany certyfikat. Jeśli organizacja używa powiązań o wysokiej koligacji (tj. silnego uwierzytelniania) oznacza, że wystawca + numer seryjny i ski mogą wyglądać następująco:

Powiązania nazwy użytkownika:

• Wystawca i numer seryjny —> identyfikatory CertificateUserId
• SKI —> CertificateUserIds

Wartości CertificateUserIds konta użytkownika:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Teraz, gdy którykolwiek użytkownik przedstawi ten sam certyfikat podczas logowania, użytkownik pomyślnie się zaloguje, ponieważ jego konto pasuje do unikatowej wartości tego certyfikatu. Jedno konto zostanie uwierzytelnione przy użyciu wystawcy+numerów seryjnych, a drugiego przy użyciu powiązania SKI.

Uwaga

Liczba kont, które mogą być używane w ten sposób, jest ograniczona przez liczbę powiązań nazwy użytkownika skonfigurowanych w dzierżawie. Jeśli organizacja używa tylko powiązań wysokiej koligacji, liczba obsługiwanych kont będzie ograniczona do 3. Jeśli organizacja korzysta również z powiązań o niskiej koligacji, liczba ta zwiększa się do 7 kont (1 Nazwa główna, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Wystawca+Podmiot, 1 Wystawca+Numer seryjny, 1 Temat).

Hybrydowe zsynchronizowane konta Dla zsynchronizowanych kont podejście będzie inne. Podczas gdy administrator dzierżawy może mapować unikatowe wartości na każde konto użytkownika, które będzie używać certyfikatu, powszechną praktyką wypełniania wszystkich wartości dla każdego konta w identyfikatorze Entra byłoby to trudne. Zamiast tego usługa Azure AD Połączenie powinna filtrować żądane wartości na konto, aby unikatowe wartości wypełnione na koncie w identyfikatorze Entra. Reguła unikatowości ma zastosowanie w granicach pojedynczego katalogu/dzierżawy (tj. administrator dzierżawy może mapować certyfikat do użycia w innym katalogu/dzierżawie, o ile wartości pozostają unikatowe dla każdego konta). Ponadto organizacja może mieć wiele lasów usługi AD współtworzenia użytkowników w jednej dzierżawie identyfikatora Entra. W takim przypadku usługa Azure AD Połączenie zastosuje filtr do każdego z tych lasów usługi AD z tym samym celem, aby wypełnić tylko żądaną unikatową wartość dla konta w chmurze.

Wypełnij pole altSecurityIdentities w usłudze AD wartościami identyfikującymi żądany certyfikat i uwzględnij żądaną wartość certyfikatu dla tego typu konta użytkownika (np. szczegóły, administrator, deweloper itp.). Wybierz atrybut klucza w usłudze AD, który wskaże synchronizację typu konta użytkownika, które użytkownik ocenia (np. msDS-cloudExtensionAttribute1). Wypełnij ten atrybut wartością typu użytkownika, taką jak szczegóły, administrator lub deweloper. Jeśli jest to konto podstawowe użytkownika, wartość może być pozostawiona pusta/null.

Konta mogą wyglądać następująco:

Las 1 — konto1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Las 1 — Konto2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Las 2 — ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Te wartości należy następnie zsynchronizować z polem certificateUserIds w identyfikatorze Entra.

Kroki synchronizacji z identyfikatoramiuserid certyfikatu

1. Konfigurowanie programu Azure AD Connect w celu dodania pola alternativeSecurityIds do metaverse
2. Dla każdego lasu usługi AD skonfiguruj nową niestandardową regułę ruchu przychodzącego o wysokim prioryencie (niska liczba poniżej 100). Dodaj przekształcenie wyrażenia za pomocą pola altSecurityIdentities jako źródła. Wyrażenie docelowe będzie używać wybranego i wypełnionego atrybutu klucza, a także mapowania na zdefiniowane przez Ciebie typy użytkowników.
3. Na przykład:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

W powyższym przykładzie altSecurityIdentities i atrybut klucza msDS-cloudExtensionAttribute1is są najpierw sprawdzane, aby sprawdzić, czy zostały wypełnione. Jeśli nie, jest sprawdzana wartość altSecurityIdentities, aby sprawdzić, czy została wypełniona. Jeśli jest ona pusta, ustawimy ją na wartość NULL. W przeciwnym razie konto mieści się w przypadku domyślnym, a w tym przykładzie filtrujemy tylko do mapowania Wystawca+Numer seryjny. Jeśli atrybut klucza jest wypełniany, sprawdzana jest wartość, aby sprawdzić, czy jest ona równa jednemu z naszych zdefiniowanych typów użytkowników. W tym przykładzie, jeśli ta wartość jest szczegółowa, filtrujemy wartość SHA1PublicKey z wartości altSecurityIdentities. Jeśli wartość jest deweloperem, filtrujemy wartość SubjectKeyIssuer z altSecurityIdentities. Może istnieć wiele wartości certyfikatów określonego typu. Na przykład wiele wartości PrincipalName lub wiele wartości SKI lub SHA1-PUKEY. Filtr pobierze wszystkie wartości i zsynchronizuje się z identyfikatorem Entra — nie tylko pierwszym, który znajdzie.

1. Drugi przykład pokazujący, jak wypchnąć pustą wartość, jeśli atrybut kontrolny jest pusty, znajduje się poniżej.

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Jeśli wartość w wartości altSecurityIdentities nie jest zgodna z żadnymi wartościami wyszukiwania w atrybucie kontrolki, zostanie przekazana wartość AuthoritativeNull. Gwarantuje to, że wcześniejsze lub kolejne reguły, które wypełniają wartość alternativeSecurityId, są ignorowane, a wynik jest pusty w identyfikatorze Entra.

1. Skonfiguruj nową niestandardową regułę ruchu wychodzącego o niskim prioryence (duża liczba powyżej 160 — dolna część listy).
2. Dodaj przekształcenie bezpośrednie z polem alternativeSecurityIds jako źródłem i polem certificateUserIds jako obiektem docelowym.
3. Uruchom cykl synchronizacji, aby ukończyć populację danych w identyfikatorze Entra.

Upewnij się, że usługa CBA w każdej dzierżawie jest skonfigurowana z powiązaniami nazw użytkowników wskazującymi pole certificateUserIds dla typów pól mapowanych z certyfikatu. Teraz każdy z tych użytkowników może przedstawić certyfikat podczas logowania, a po zweryfikowaniu unikatowej wartości z certyfikatu względem pola certificateUserIds, ten użytkownik zostanie pomyślnie zalogowany.

Opis procesu odwoływania certyfikatów

Proces odwoływania certyfikatów umożliwia administratorowi odwołanie wcześniej wystawionego certyfikatu do użycia na potrzeby przyszłego uwierzytelniania. Odwołanie certyfikatu nie spowoduje odwołania już wystawionych tokenów użytkownika. Postępuj zgodnie z instrukcjami, aby ręcznie odwołać tokeny w temacie Konfigurowanie odwołania.

Microsoft Entra ID pobiera i buforuje listę odwołania certyfikatów klientów (CRL) ze swojego urzędu certyfikacji, aby sprawdzić, czy certyfikaty są odwołane podczas uwierzytelniania użytkownika.

Administrator może skonfigurować punkt dystrybucji listy CRL podczas procesu instalacji zaufanych wystawców w dzierżawie firmy Microsoft Entra. Każdy zaufany wystawca powinien mieć listę CRL, do których można się odwoływać przy użyciu adresu URL dostępnego z Internetu.

Ważne

Maksymalny rozmiar listy CRL dla identyfikatora entra firmy Microsoft do pomyślnego pobrania interakcyjnego logowania i pamięci podręcznej wynosi 20 MB w publicznym identyfikatorze Entra i 45 MB w chmurach platformy Azure US Government, a czas wymagany do pobrania listy CRL nie może przekraczać 10 sekund. Jeśli identyfikator entra firmy Microsoft nie może pobrać listy CRL, uwierzytelnianie oparte na certyfikatach przy użyciu certyfikatów wystawionych przez odpowiedni urząd certyfikacji nie powiedzie się. Najlepszym rozwiązaniem jest utrzymywanie plików listy CRL w granicach rozmiaru, utrzymywanie okresów istnienia certyfikatów w rozsądnych limitach i czyszczenie wygasłych certyfikatów. Aby uzyskać więcej informacji, zobacz Czy istnieje limit rozmiaru listy CRL?.

Gdy użytkownik wykonuje logowanie interakcyjne przy użyciu certyfikatu, a lista CRL przekracza limit interakcyjny dla chmury, początkowe logowanie kończy się niepowodzeniem z powodu następującego błędu:

"Lista odwołania certyfikatów (CRL) pobrana z witryny {uri} przekroczyła maksymalny dozwolony rozmiar ({size} bajtów) dla list CRL w identyfikatorze Entra firmy Microsoft. Spróbuj ponownie za kilka minut. Jeśli problem będzie się powtarzać, skontaktuj się z administratorami dzierżawy".

Po błędzie identyfikator Entra firmy Microsoft próbuje pobrać listę CRL z limitami po stronie usługi (45 MB w publicznych identyfikatorach Entra i 150 MB w chmurach platformy Azure US Government).

Ważne

Jeśli administrator pominą konfigurację listy CRL, identyfikator Entra firmy Microsoft nie wykonuje żadnych kontroli listy CRL podczas uwierzytelniania opartego na certyfikatach użytkownika. Może to być przydatne w przypadku początkowego rozwiązywania problemów, ale nie należy ich uwzględniać w środowisku produkcyjnym.

Od tej pory nie obsługujemy protokołu OCSP (Online Certificate Status Protocol) ze względu na wydajność i niezawodność. Zamiast pobierać listę CRL przy każdym połączeniu przez przeglądarkę klienta dla dostawcy OCSP, identyfikator Entra firmy Microsoft pobiera raz przy pierwszym logowaniu i buforuje ją, co zwiększa wydajność i niezawodność weryfikacji listy CRL. Za każdym razem indeksujemy pamięć podręczną, aby wyszukiwanie było znacznie szybsze. Klienci muszą publikować listy CRL na potrzeby odwołania certyfikatów.

Poniżej przedstawiono typowy przepływ sprawdzania listy CRL:

1. Microsoft Entra ID próbuje pobrać listę CRL przy pierwszym logowaniu każdego użytkownika z certyfikatem odpowiedniego zaufanego wystawcy lub urzędu certyfikacji.
2. Microsoft Entra ID buforuje i ponownie używa listy CRL w celu późniejszego użycia. Honoruje datę następnej aktualizacji i, jeśli jest dostępna, Następna data publikacji listy CRL (używana przez urzędy certyfikacji systemu Windows Server) w dokumencie listy CRL.
3. Uwierzytelnianie oparte na certyfikatach użytkownika kończy się niepowodzeniem, jeśli:

   • Lista CRL została skonfigurowana dla zaufanego wystawcy i identyfikator entra firmy Microsoft nie może pobrać listy CRL ze względu na ograniczenia dostępności, rozmiaru lub opóźnienia.

   • Certyfikat użytkownika jest wymieniony jako odwołany na liście CRL.

     

   • Identyfikator entra firmy Microsoft próbuje pobrać nową listę CRL z punktu dystrybucji, jeśli buforowany dokument listy CRL wygasł.

Uwaga

Microsoft Entra ID sprawdza listę CRL urzędu wystawiającego certyfikaty i innych urzędów certyfikacji w łańcuchu zaufania PKI do głównego urzędu certyfikacji. Mamy limit do 10 urzędów certyfikacji z certyfikatu klienta liścia na potrzeby weryfikacji listy CRL w łańcuchu infrastruktury kluczy publicznych. Ograniczeniem jest upewnienie się, że zły aktor nie obniży usługi, przekazując łańcuch infrastruktury kluczy publicznych z ogromną liczbą urzędów certyfikacji o większym rozmiarze listy CRL. Jeśli łańcuch infrastruktury kluczy publicznych dzierżawy ma więcej niż 5 urzędów certyfikacji i w przypadku naruszenia zabezpieczeń urzędu certyfikacji, administrator powinien usunąć naruszonego zaufanego wystawcę z konfiguracji dzierżawy firmy Microsoft Entra.

Ważne

Ze względu na charakter buforowania i publikowania listy CRL zdecydowanie zaleca się odwołanie certyfikatu w celu odwołania wszystkich sesji użytkownika, którego dotyczy problem, w identyfikatorze Entra firmy Microsoft.

Od tej pory nie ma możliwości ręcznego wymuszenia lub ponownego pobierania listy CRL.

Jak skonfigurować odwołanie

Aby odwołać certyfikat klienta, identyfikator Entra firmy Microsoft pobiera listę odwołania certyfikatów (CRL) z adresów URL przekazanych w ramach informacji o urzędzie certyfikacji i buforuje go. Ostatnia sygnatura czasowa publikacji (właściwość Effective Date ) w liście CRL jest używana do zapewnienia, że lista CRL jest nadal prawidłowa. Lista CRL jest okresowo odwołuje się do odwołania dostępu do certyfikatów, które są częścią listy.

Jeśli wymagane jest bardziej natychmiastowe odwołanie (na przykład jeśli użytkownik utraci urządzenie), token autoryzacji użytkownika może zostać unieważniony. Aby unieważnić token autoryzacji, ustaw pole StsRefreshTokenValidFrom dla tego konkretnego użytkownika przy użyciu programu Windows PowerShell. Należy zaktualizować pole StsRefreshTokenValidFrom dla każdego użytkownika, dla którego chcesz odwołać dostęp.

Aby upewnić się, że odwołanie będzie się powtarzać, należy ustawić datę obowiązującą listy CRL na datę po wartości ustawionej przez StsRefreshTokenValidFrom i upewnić się, że certyfikat, którego dotyczy, znajduje się w liście CRL.

Uwaga

Moduły usług Azure AD i MSOnline programu PowerShell są przestarzałe od 30 marca 2024 r. Aby dowiedzieć się więcej, przeczytaj aktualizację o wycofaniu. Po tej dacie obsługa tych modułów jest ograniczona do pomocy dotyczącej migracji do zestawu MICROSOFT Graph PowerShell SDK i poprawek zabezpieczeń. Przestarzałe moduły będą nadal działać do 30 marca 2025 r.

Zalecamy migrację do programu Microsoft Graph PowerShell w celu interakcji z identyfikatorem Entra firmy Microsoft (dawniej Azure AD). W przypadku typowych pytań dotyczących migracji zapoznaj się z często zadawanymi pytaniami dotyczącymi migracji. Uwaga: wersje 1.0.x usługi MSOnline mogą wystąpić zakłócenia po 30 czerwca 2024 r.

W poniższych krokach opisano proces aktualizowania i unieważniania tokenu autoryzacji przez ustawienie pola StsRefreshTokenValidFrom .

1. Połączenie do programu PowerShell:

   Connect-MgGraph
   

2. Pobierz bieżącą wartość StsRefreshTokensValidFrom dla użytkownika:

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. Skonfiguruj nową wartość StsRefreshTokensValidFrom dla użytkownika równą bieżącemu znacznikowi czasu:

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

Ustawiona data musi być w przyszłości. Jeśli data nie jest w przyszłości, właściwość StsRefreshTokensValidFrom nie jest ustawiona. Jeśli data przypada w przyszłości, właściwość StsRefreshTokensValidFrom jest ustawiona na bieżącą godzinę (a nie datę wskazaną przez polecenie Set-MsolUser).

Jak cba działa z zasadami siły uwierzytelniania dostępu warunkowego

Klienci mogą utworzyć zasady siły uwierzytelniania dostępu warunkowego, aby określić, że cba ma być używana do uzyskiwania dostępu do zasobu.

Możesz użyć wbudowanej siły uwierzytelniania MFA odpornego na wyłudzanie informacji. Te zasady umożliwiają tylko metody uwierzytelniania odporne na wyłudzanie informacji, takie jak CBA, klucze zabezpieczeń FIDO2 i Windows Hello dla firm.

Możesz również utworzyć niestandardową siłę uwierzytelniania, aby umożliwić dostęp tylko do poufnych zasobów przez cba. Można zezwolić na cba jako jednoskładnikowy, wieloskładnikowy lub oba te elementy. Aby uzyskać więcej informacji, zobacz Siła uwierzytelniania dostępu warunkowego.

Siła uwierzytelniania CBA z zaawansowanymi opcjami

W zasadach metod uwierzytelniania CBA administrator może określić siłę certyfikatu przy użyciu zasad powiązania uwierzytelniania w metodzie CBA. Teraz możesz skonfigurować opcje zaawansowane podczas tworzenia niestandardowej siły uwierzytelniania, aby wymagać użycia określonego certyfikatu na podstawie identyfikatorów operacyjnego wystawcy i zasad, gdy użytkownicy wykonują cba w celu uzyskania dostępu do niektórych poufnych zasobów. Ta funkcja zapewnia bardziej precyzyjną konfigurację w celu określenia certyfikatów i użytkowników, którzy mogą uzyskiwać dostęp do zasobów. Aby uzyskać więcej informacji, zobacz Zaawansowane opcje siły uwierzytelniania dostępu warunkowego.

Informacje o dziennikach logowania

Dzienniki logowania zawierają informacje o logowaniach i sposobie użycia zasobów przez użytkowników. Aby uzyskać więcej informacji na temat dzienników logowania, zobacz Dzienniki logowania w usłudze Microsoft Entra ID.

Omówimy dwa scenariusze, w których certyfikat spełnia uwierzytelnianie jednoskładnikowe, a drugi, w którym certyfikat spełnia uwierzytelnianie wieloskładnikowe.

W przypadku scenariuszy testowych wybierz użytkownika z zasadami dostępu warunkowego, które wymagają uwierzytelniania wieloskładnikowego. Skonfiguruj zasady powiązania użytkownika, mapując główną nazwę sieci SAN na UserPrincipalName.

Certyfikat użytkownika należy skonfigurować tak jak na poniższym zrzucie ekranu:

Rozwiązywanie problemów z logowaniem przy użyciu zmiennych dynamicznych w dziennikach logowania

Mimo że dzienniki logowania zawierają wszystkie informacje dotyczące debugowania problemów z logowaniem użytkownika, istnieją czasy, w których wymagane są określone wartości, a ponieważ dzienniki logowania nie obsługują zmiennych dynamicznych, dzienniki logowania nie zawierają żadnych informacji. Na przykład: Przyczyna niepowodzenia w dzienniku logowania będzie zawierać coś takiego jak "Lista odwołania certyfikatów (CRL) nie powiodła się walidacja podpisu. Oczekiwany identyfikator klucza podmiotu {expectedSKI} nie jest zgodny z kluczem urzędu listy CRL {crlAK}. Poproś administratora dzierżawy o sprawdzenie konfiguracji listy CRL." gdzie {expectedSKI} i {crlAKI} nie są wypełniane poprawnymi wartościami.

Gdy logowanie użytkowników przy użyciu konta CBA nie powiedzie się, skopiuj szczegóły dziennika z linku "Więcej szczegółów" na stronie błędu. Aby uzyskać bardziej szczegółowe informacje, zapoznaj się ze stroną błędu CBA

Testowanie uwierzytelniania jednoskładnikowego

W pierwszym scenariuszu testowym skonfiguruj zasady uwierzytelniania, w których reguła podmiotu wystawcy spełnia uwierzytelnianie jednoskładnikowe.

1. Zaloguj się do centrum administracyjnego firmy Microsoft Entra jako użytkownik testowy przy użyciu cba. Zasady uwierzytelniania są ustawiane, gdzie reguła podmiotu wystawcy spełnia uwierzytelnianie jednoskładnikowe.

2. Wyszukaj i wybierz pozycję Dzienniki logowania.

   Przyjrzyjmy się bliżej niektórym wpisom, które można znaleźć w dziennikach logowania.

   Pierwszy wpis żąda certyfikatu X.509 od użytkownika. Stan Przerwany oznacza, że identyfikator Entra firmy Microsoft zweryfikował, czy cba jest włączona w dzierżawie, a certyfikat jest wymagany do uwierzytelnienia.

   

   Szczegóły działania pokazują, że jest to tylko część oczekiwanego przepływu logowania, w którym użytkownik wybiera certyfikat.

   

   Dodatkowe szczegóły zawierają informacje o certyfikacie.

   

   Te dodatkowe wpisy pokazują, że uwierzytelnianie zostało ukończone, podstawowy token odświeżania jest wysyłany z powrotem do przeglądarki, a użytkownik ma dostęp do zasobu.

   

Testowanie uwierzytelniania wieloskładnikowego

W następnym scenariuszu testowym skonfiguruj zasady uwierzytelniania, w których reguła policyOID spełnia uwierzytelnianie wieloskładnikowe.

1. Zaloguj się do centrum administracyjnego firmy Microsoft Entra przy użyciu cba. Ponieważ zasady zostały ustawione na potrzeby uwierzytelniania wieloskładnikowego, logowanie użytkownika kończy się pomyślnie bez drugiego czynnika.

2. Wyszukaj i wybierz pozycję Logowania.

   W dziennikach logowania zostanie wyświetlonych kilka wpisów, w tym wpis ze stanem Przerwane .

   

   Szczegóły działania pokazują, że jest to tylko część oczekiwanego przepływu logowania, w którym użytkownik wybiera certyfikat.

   

   Wpis ze stanem przerwanym zawiera więcej informacji diagnostycznych na karcie Dodatkowe szczegóły .

   

   Poniższa tabela zawiera opis każdego pola.

   Pole	opis
   Nazwa podmiotu certyfikatu użytkownika	Odwołuje się do pola nazwy podmiotu w certyfikacie.
   Powiązanie certyfikatu użytkownika	Certyfikat: główna nazwa; Atrybut użytkownika: userPrincipalName; Ranga: 1 Pokazuje to, które pole certyfikatu SAN PrincipalName zostało zamapowane na atrybut użytkownika userPrincipalName i miało priorytet 1.
   Poziom uwierzytelniania certyfikatu użytkownika	multiFactorAuthentication
   Typ poziomu uwierzytelniania certyfikatu użytkownika	IdentZasady Spowoduje to wyświetlenie danych OID zasad używanych do określania siły uwierzytelniania.
   Identyfikator poziomu uwierzytelniania certyfikatu użytkownika	1.2.3.4 Spowoduje to wyświetlenie wartości identyfikatora OID zasad identyfikatora z certyfikatu.

Opis strony błędu uwierzytelniania opartego na certyfikatach

Uwierzytelnianie oparte na certyfikatach może zakończyć się niepowodzeniem z powodów, takich jak nieprawidłowy certyfikat, lub użytkownik wybrał nieprawidłowy certyfikat lub wygasły certyfikat albo z powodu problemu z listą odwołania certyfikatów (CRL). Gdy sprawdzanie poprawności certyfikatu zakończy się niepowodzeniem, użytkownik zobaczy ten błąd:

Jeśli cba kończy się niepowodzeniem w przeglądarce, nawet jeśli błąd jest spowodowany anulowaniem selektora certyfikatów, musisz zamknąć sesję przeglądarki i otworzyć nową sesję, aby spróbować cba ponownie. Wymagana jest nowa sesja, ponieważ przeglądarki buforuje certyfikat. Po ponownym pobraniu cba przeglądarka wysyła buforowany certyfikat podczas wyzwania tls, co powoduje niepowodzenie logowania i błąd weryfikacji.

Wybierz pozycję Więcej szczegółów , aby uzyskać informacje rejestrowania, które mogą być wysyłane do administratora, który z kolei może uzyskać więcej informacji z dzienników logowania.

Wybierz pozycję Inne sposoby logowania , aby wypróbować inne metody dostępne dla użytkownika w celu zalogowania się.

Uwaga

Jeśli ponowisz próbę agenta CBA w przeglądarce, będzie ona nadal kończyła się niepowodzeniem z powodu problemu z buforowaniem przeglądarki. Użytkownicy muszą otworzyć nową sesję przeglądarki i zalogować się ponownie.

Uwierzytelnianie oparte na certyfikatach w metodach MostRecentlyUsed (MRU)

Po pomyślnym uwierzytelnieniu użytkownika przy użyciu cba metoda uwierzytelniania MostRecentlyUsed (MRU) użytkownika jest ustawiona na CBA. Następnym razem, gdy użytkownik wprowadzi swoją nazwę UPN i wybierze pozycję Dalej, użytkownik zostanie przeniesiony bezpośrednio do metody CBA i nie musi wybrać pozycji Użyj certyfikatu lub karty inteligentnej.

Aby zresetować metodę MRU, użytkownik musi anulować selektor certyfikatów, wybrać pozycję Inne sposoby logowania, a następnie wybrać inną metodę dostępną dla użytkownika i pomyślnie uwierzytelnić.

Obsługa tożsamości zewnętrznej

Tożsamość zewnętrzna nie może wykonywać uwierzytelniania wieloskładnikowego w dzierżawie zasobów za pomocą usługi Microsoft Entra CBA. Zamiast tego użytkownik musi wykonać uwierzytelnianie wieloskładnikowe przy użyciu cba w dzierżawie głównej i skonfigurować ustawienia dzierżawy zasobów w celu zaufania uwierzytelniania wieloskładnikowego z dzierżawy głównej.

Aby uzyskać więcej informacji na temat włączania uwierzytelniania wieloskładnikowego zaufania z dzierżaw firmy Microsoft Entra, zobacz Konfigurowanie dostępu między dzierżawami współpracy B2B.

Następne kroki

• Omówienie usługi Microsoft Entra CBA
• Jak skonfigurować usługę Microsoft Entra CBA
• Microsoft Entra CBA na urządzeniach z systemem iOS
• Microsoft Entra CBA na urządzeniach z systemem Android
• Logowanie za pomocą karty inteligentnej systemu Windows przy użyciu usługi Microsoft Entra CBA
• Identyfikatory użytkownika certyfikatu
• Jak migrować użytkowników federacyjnych
• Często zadawane pytania
• Rozwiązywanie problemów z usługą Microsoft Entra CBA