Szczegółowa analiza techniczna dotycząca 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?

Poniższy obraz pokazuje, co się stanie, gdy użytkownik próbuje zalogować się do aplikacji w dzierżawie, gdzie włączono Microsoft Entra CBA.

Poniżej przedstawiono kroki, które należy wykonać:

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 Microsoft Entra umożliwia odnajdywanie domeny macierzystej przy użyciu nazwy dzierżawy, a nazwa użytkownika jest używana do wyszukiwania użytkownika w tej dzierżawie.

   

4. Microsoft Entra ID sprawdza, czy CBA jest włączona dla dzierżawcy. 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 u odbiorcy. Aby uzyskać więcej informacji, zobacz Jak mogę włączyć 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 z hasłem. Jednak tylko użytkownicy objęci zakresem CBA mogą pomyślnie uwierzytelniać się w aplikacji, która używa Microsoft Entra ID jako dostawcy tożsamości (IdP).

   

   Jeśli włączono inne metody uwierzytelniania, takie jak logowanie na telefonie 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 firmy Microsoft. 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 podczas wymiany kluczy TLS. Wpis dla tego żądania pojawia się w rejestrze logowań.

   Uwaga

   Administrator sieci powinien zezwolić na dostęp do strony logowania użytkownika oraz do punktu końcowego *.certauth.login.microsoftonline.com związanego z uwierzytelnianiem certyfikatu dla środowiska chmury klienta. Wyłącz inspekcję TLS na certauth endpoint, aby zapewnić powodzenie żądania certyfikatu klienta w ramach uzgadniania 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 zakończy się niepowodzeniem, jeśli włączysz wskazówki dotyczące wystawcy.

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

   

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

8. Jeśli unikatowy użytkownik zostanie znaleziony z polityką dostępu warunkowego, która wymaga uwierzytelniania wieloskładnikowego, a reguła powiązania uwierzytelniania certyfikatu spełnia MFA, wtedy Microsoft Entra ID natychmiast loguje użytkownika. Jeśli uwierzytelnianie wieloskładnikowe jest wymagane, ale certyfikat spełnia tylko jeden czynnik, jako drugi czynnik oferowane jest logowanie bez hasła lub metoda FIDO2, pod warunkiem, że są 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.

Zrozumienie wskazówek wystawcy (wersja próbna)

Wskazówki wystawcy wysyłają z powrotem zaufane wskazanie urzędu certyfikacji w ramach uzgadniania protokołu TLS. Lista zaufanych urzędów certyfikacji zależy od urzędów certyfikacji przesłanych przez użytkownika w magazynie zaufania Entra. Klient przeglądarki lub klient aplikacji natywnej może używać wskazówek wysyłanych z powrotem przez serwer do filtrowania certyfikatów wyświetlanych w selektorze certyfikatów. Klient wyświetla tylko certyfikaty uwierzytelniania wystawione przez urzędy certyfikacji w magazynie certyfikatów zaufanych.

Włącz wskazówki wystawcy

Aby umożliwić zaznaczenie pola wyboru Wskazówki wystawcy. Administratorzy zasad uwierzytelniania powinni wybrać potwierdzam po upewnieniu się, że serwer proxy z włączoną inspekcją TLS został poprawnie zaktualizowany, i zapisać.

Uwaga

Jeśli Twoja organizacja używa zapór ogniowych lub serwerów proxy z inspekcją TLS, upewnij się, że wyłączyłeś inspekcję TLS na punkcie końcowym certyfikatu, który może odpowiadać dowolnej nazwie w [*.]certauth.login.microsoftonline.com, dostosowanej do konkretnego używanego serwera proxy.

Uwaga

Adres URL urzędu certyfikacji przyjmuje format t{tenantId}.certauth.login.microsoftonline.com po włączeniu wskazówek wystawcy.

Propagowanie aktualizacji magazynu zaufania CA

Po włączeniu wskazówek dotyczących wystawcy oraz dodaniu, zaktualizowaniu lub usunięciu urzędów certyfikacji ze stanu zaufania, istnieje opóźnienie do 10 minut w rozpropagowaniu tych wskazówek z powrotem do klienta. Użytkownicy nie mogą uwierzytelniać się przy użyciu certyfikatów wystawionych przez nowe urzędy certyfikacji, dopóki wskazówki nie zostaną rozpropagowane.

Administratorzy zasad uwierzytelniania powinni zalogować się przy użyciu certyfikatu po włączeniu wskazówek wystawcy w celu zainicjowania propagacji. Użytkownicy widzą następujący komunikat o błędzie, gdy aktualizacje magazynu zaufania CA są wdrażane.

Uwierzytelnianie wieloskładnikowe (MFA) z użyciem jednoskładnikowego uwierzytelniania opartego na certyfikatach

Usługa Microsoft Entra CBA jest obsługiwana zarówno jako pierwszy czynnik, jak i drugi czynnik uwierzytelniania. Niektóre z obsługiwanych kombinacji to:

1. CBA (pierwszy czynnik) i klucz dostępu (drugi czynnik)
2. CBA (pierwszy czynnik) i logowanie bez hasła na telefon (drugi czynnik)
3. CBA (pierwszy czynnik) i klucze zabezpieczeń FIDO2 (drugi czynnik)
4. Hasło (pierwszy czynnik) + CBA (drugi czynnik uwierzytelniania) (wersja próbna)

Uwaga

CBA jako drugi czynnik w systemie iOS ma znane problemy i jest blokowany w systemie iOS. Pracujemy nad rozwiązaniem problemów i powinniśmy być obsługiwani w systemie iOS.

Użytkownicy muszą mieć możliwość uzyskania uwierzytelniania wieloskładnikowego i zarejestrowania 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 zdolnego do korzystania z uwierzytelniania wieloskładnikowego, gdy zostanie uwzględniony w ustawieniach metody CBA. Oznacza to, że użytkownik nie może użyć metody "proof up" jako części uwierzytelniania, aby zarejestrować inne dostępne metody. 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).

Opcje uzyskania możliwości uwierzytelniania wieloskładnikowego przy użyciu certyfikatów jednofaktorowych.

Usługa Microsoft Entra CBA obsługuje 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żawcy. Włączenie CBA sprawia, że użytkownik ma potencjalną możliwość ukończenia uwierzytelniania wieloskładnikowego. Użytkownik z certyfikatem pojedynczego czynnika wymaga innego czynnika do ukończenia uwierzytelniania wieloskładnikowego, dlatego nie zezwolimy na rejestrację innych metod bez spełnienia uwierzytelniania wieloskładnikowego. Jeśli użytkownik nie ma żadnej innej zarejestrowanej metody uwierzytelniania wieloskładnikowego i jest dodany do zakresu dla metody uwierzytelniania CBA, użytkownik nie może zarejestrować innych metod uwierzytelniania i uzyskać dostęp do uwierzytelniania wieloskładnikowego.

Jeśli użytkownik z włączoną usługą CBA ma tylko certyfikat jednopoziomowy (SF) i musi przeprowadzić uwierzytelnianie wieloskładnikowe (MFA):

1. Używanie hasła i certyfikatu SF (OR)
2. Administrator zasad uwierzytelniania może wydać tymczasowy dostęp próbny (OR)
3. Administrator zasad uwierzytelniania 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 otrzymał jeszcze certyfikatu i musi przejść uwierzytelnianie wieloskładnikowe:

1. Administrator zasad uwierzytelniania może wydać tymczasowy dostęp próbny (OR)
2. Administrator zasad uwierzytelniania 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. Administrator zasad uwierzytelniania może wydać tymczasowy dostęp próbny (OR)
2. Użytkownik musi zarejestrować inną metodę uwierzytelniania wieloskładnikowego (gdy użytkownik jest w stanie użyć certyfikatu MFA na niektórych urządzeniach) (LUB)
3. Administrator zasad uwierzytelniania dodaje numer telefonu i zezwala na uwierzytelnianie wiadomości głosowych/tekstowych dla konta użytkownika.

Kroki konfigurowania logowania się za pomocą telefonu bez użycia 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 co najmniej jako administrator 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 Ochrona>Uwierzytelnianie wieloskładnikowe>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 MFA przy użyciu certyfikatów jednoskładnikowych i wejścia 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 logowanie na telefon 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ć.

Zrozumienie zasad powiązania uwierzytelniania

Zasady powiązania uwierzytelniania pomagają określić siłę uwierzytelniania jako uwierzytelnianie jednoskładnikowe lub wieloskładnikowe. Administratorzy zasad uwierzytelniania mogą zmienić wartość domyślną z pojedynczego uwierzytelniania na uwierzytelnianie wieloskładnikowe lub skonfigurować niestandardowe konfiguracje zasad, korzystając z pola podmiotu wystawcy, identyfikatora OID zasad lub obu tych elementów w certyfikacie.

Mocne strony certyfikatu

Administratorzy zasad uwierzytelniania mogą 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 Microsoft Entra, która opiera się na NIST SP 800-63B, Wytyczne dotyczące tożsamości cyfrowej: Uwierzytelnianie i zarządzanie cyklem życia.

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 administrator zasad uwierzytelniania powinien upewnić się, że certyfikaty są chronione przy użyciu numeru PIN lub biometrycznego, aby zostały uznane za wieloskładnikowe.

Jak Microsoft Entra ID rozwiązuje wiele reguł powiązania polityk 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, tylko identyfikatora OID zasad, albo 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 identyfikatora OID zasad. Reguły identyfikatora OID polityk mają pierwszeństwo przed regułami wystawcy certyfikatów.
2. Najpierw oceniane są reguły OID wystawcy i polityki. Jeśli masz regułę niestandardową z wystawcą CA1 i identyfikatorem OID zasad 1.2.3.4.5 z MFA, tylko certyfikat A, który spełnia zarówno wartość wystawcy, jak i identyfikator OID zasad, otrzymuje MFA.
3. Następnie oceniane są reguły niestandardowe korzystające z identyfikatorów OID. 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 zasad polityki (OID) (na przykład gdy certyfikat ma dwa identyfikatory zasad polityki, gdzie jeden jest powiązany z uwierzytelnianiem jednoskładnikowym, a drugi z uwierzytelnianiem wieloskładnikowym), certyfikat należy uznać za uwierzytelnianie jednoskładnikowe.
5. Następnie oceniane są reguły niestandardowe wykorzystujące CA wystawcy.
6. Jeśli certyfikat ma zarówno OID polityki, jak i zgodne reguły wystawcy, najpierw zawsze sprawdzany jest OID polityki. Jeśli nie zostanie znaleziona żadna reguła polityki, wtedy sprawdzane są powiązania wystawcy. OID polityki ma wyższy priorytet powiązania silnego uwierzytelnienia niż priorytet wystawcy.
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, w którym Administrator Zasad Uwierzytelniania Microsoft Entra konfiguruje regułę polityki uwierzytelniania CBA przy użyciu zarówno Identyfikatora OID Wystawcy, jak i OID Polityki, co wpływa na niektóre scenariusze rejestracji urządzeń, w tym:

• Rejestracja w usłudze Windows Hello dla firm
• Rejestracja klucza zabezpieczeń Fido2
• Logowanie przy użyciu telefonu bez hasła systemu Windows

Nie ma to wpływu na rejestrację urządzeń przy użyciu Workplace Join, Microsoft Entra ID oraz scenariusze hybrydowego dołączania urządzeń Microsoft Entra. Reguły zasad uwierzytelniania CBA przy użyciu OID wystawcy LUB OID zasad nie są dotknięte. Aby rozwiązać ten problem, administratorzy zasad uwierzytelniania powinni:

• Edytuj reguły uwierzytelniania oparte na certyfikatach, które obecnie używają opcji wystawcy i identyfikatora OID, następnie usuń wymaganie wystawcy lub identyfikatora OID i zapisz. LUB
• Usuń regułę polityki uwierzytelniania, która obecnie używa zarówno OID wystawcy, jak i OID polityki, i utwórz reguły przy użyciu tylko OID wystawcy lub OID polityki.

Pracujemy nad rozwiązaniem problemu.

Zrozumienie zasad powiązania nazwy użytkownika

Zasady powiązania nazwy użytkownika pomagają zweryfikować certyfikat użytkownika. Domyślnie nazwa alternatywna 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ą zgodność, jeśli są oparte na identyfikatorach, których nie można użyć ponownie, takich jak identyfikatory klucza podmiotu lub klucz publiczny SHA-1. 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ą uznawane za niskie powiązania. Microsoft Entra ID implementuje trzy mapowania, uznawane za o niskiej afinitas, na podstawie identyfikatorów wielokrotnego użytku. Pozostałe są uznawane za wiązania o wysokim powinowactwie. Aby uzyskać więcej informacji, zobacz certificateUserIds.

Pole mapowania certyfikatu	Przykłady wartości w certificateUserIds	Atrybuty obiektu użytkownika	Typ
NazwaGłówna	X509:<PN>bob@woodgrove.com	Nazwa główna użytkownika onPremisesUserPrincipalName IdentyfikatoryUżytkownikówCertyfikatu	niskiego powinowactwa
RFC822Name	X509:<RFC822>user@woodgrove.com	Główna Nazwa Użytkownika onPremisesUserPrincipalName certificateUserIds	niskie powinowactwo
IssuerAndSubject (wersja zapoznawcza)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	niskie powinowactwo
Temat (wersja zapoznawcza)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	niskie powinowactwo
NARTA	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	wysoka koligacja
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	IdentyfikatoryUżytkownikówCertyfikatu	wysoka powinowatość
IssuerAndSerialNumber (wersja zapoznawcza)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT 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	identyfikatory użytkowników certyfikatu	wysokie powinowactwo

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

Dzięki tej funkcji administrator polityki uwierzytelniania może skonfigurować, czy użytkownik może być uwierzytelniony przy użyciu mapowania nazwy użytkownika o niskiej lub wysokiej sile powiązania. 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 na podstawie samego identyfikatora OID zasad, lub samego identyfikatora OID wystawcy.

Jak Microsoft Entra ID rozwiązuje wiele reguł wiązania polityk nazwy użytkownika

Użyj wiązania o najwyższym priorytecie (najniższym numerze).

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 zasad uwierzytelniania w konfiguracji metody uwierzytelniania CBA uporządkowanej według atrybutu "priority". Obecnie koncepcja priorytetu nie jest widoczna w interfejsie użytkownika portalu. Program Graph zwraca atrybut priorytetu dla każdego powiązania i są one używane w procesie oceny.
3. Jeśli najemca ma włączone powiązanie o dużej zgodności lub jeśli wartość certyfikatu odpowiada niestandardowej regule wymagającej powiązania dużej zgodności, usuń wszystkie powiązania o niskiej zgodności 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, Microsoft Entra ID dopasowuje wartość 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 nie zostanie znalezione dopasowanie, przejdź do następnego priorytetowego powiązania.
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 aż jeden z nich dopasuje się i 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 Microsoft Entra przy użyciu wielu wiązań nazw użytkowników

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 zasad uwierzytelniania dostosowanie jednego certyfikatu do wielu konfiguracji kont użytkowników firmy Microsoft Entra.

Ważne

Jeśli skonfigurujesz wiele powiązań, uwierzytelnianie Microsoft Entra CBA jest tak bezpieczne, jak najniższe powiązanie koligacji, ponieważ CBA weryfikuje każde z powiązań, aby uwierzytelnić użytkownika. Aby zapobiec scenariuszowi, w którym jeden certyfikat jest zgodny z wieloma kontami firmy Microsoft Entra, administrator zasad uwierzytelniania może:

• Skonfiguruj pojedynczą metodę wiązania w polityce wiązania nazwy użytkownika.
• Jeśli najemca ma skonfigurowane wiele metod powiązań i nie chce zezwalać na przyporządkowanie jednego certyfikatu do wielu kont, administrator zasad uwierzytelniania musi upewnić się, że wszystkie dozwolone metody skonfigurowane w polityce mapują na to samo konto Microsoft Entra. Wszystkie konta użytkowników powinny mieć wartości pasujące do wszystkich powiązań.
• Jeśli najemca ma skonfigurowane wiele metod uwierzytelniania, administrator zasad uwierzytelniania powinien upewnić się, że nie ma więcej niż jednego powiązania o niskiej afinitet.

Załóżmy, że masz dwa powiązania nazwy użytkownika dla PrincipalName zamapowane na UPN i SubjectKeyIdentifier (SKI) na identyfikatory użytkowników certyfikatu. Jeśli chcesz, aby certyfikat był używany tylko dla jednego konta, administrator zasad uwierzytelniania musi upewnić się, że konto ma nazwę UPN, który jest obecny w certyfikacie, i zaimplementować mapowanie SKI w atrybucie certificateUserId tego samego konta.

Obsługa wielu certyfikatów przy użyciu jednego konta użytkownika microsoft 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 wysokim powinowactwie, takich jak 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>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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 na pole certificateUserIds w celu wyszukania określonego formatu powiązania (czyli Wystawca+Numer seryjny w tym przykładzie), 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 wysokim stopniu zaufania (czyli silnego uwierzytelniania), przykład takiego powiązania to Wystawca + Numer seryjny, co może wyglądać następująco:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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 identyfikatorze Entra firmy Microsoft.

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

Istnieją scenariusze, w których organizacja wymaga, aby użytkownik uwierzytelniał się 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 służbowych. 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 Microsoft Entra CBA sytuacja się różni i nie ma pomocniczych wskazówek. Zamiast tego mechanizm Home Realm Discovery 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 firmy Microsoft Entra i zaleca się, aby nie zezwalać na jeden certyfikat dla wielu kont użytkowników usługi Microsoft Entra.

konta wyłącznie w chmurze Dla kont wyłącznie w chmurze należy utworzyć wiele asocjacji nazw użytkowników i przypisać unikatowe wartości do każdego konta użytkownika, które ma używać certyfikatu. Każde konto jest uwierzytelniane przy użyciu innego powiązania nazwy użytkownika. Dotyczy to granic pojedynczego katalogu/dzierżawy (czyli administratorzy zasad uwierzytelniania mogą mapować certyfikat do użycia w innym katalogu/dzierżawie, o ile wartości pozostają unikatowe dla każdego konta).

Wypełnij pole certificateUserIds (informacje o autoryzacji w portalu użytkowników) unikatową wartością identyfikującą żądany certyfikat. Jeśli organizacja korzysta z wiązań o wysokiej przynależności (czyli silnego uwierzytelniania), takich jak kombinacja Wystawca + Numer Seryjny oraz SKI, mogą one wyglądać następująco:

Powiązania nazwy użytkownika:

• Wystawca + Numer Seryjny -> Identyfikatory CertificateUserIds
• SKI —> CertificateUserIds

Wartości CertificateUserIds konta użytkownika:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Teraz, gdy którykolwiek z użytkowników przedstawi ten sam certyfikat podczas logowania, zaloguje się pomyślnie, ponieważ jego konto jest powiązane z unikatową wartością tego certyfikatu. Jedno konto jest uwierzytelniane przy użyciu wystawcy+numeru seryjnego, natomiast drugie przy użyciu powiązania z SKI.

Uwaga

Liczba kont, które mogą być używane w ten sposób, jest ograniczona liczbą powiązań nazw użytkowników zdefiniowanych na dzierżawie. Jeśli organizacja używa tylko powiązań wysokiej koligacji, liczba obsługiwanych kont jest ograniczona do 3. Jeśli organizacja korzysta również z powiązań o niskim powiązaniu, liczba ta zwiększa się do 7 kont (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Wystawca+Podmiot, 1 Wystawca+Numer seryjny, 1 Temat).

konta zsynchronizowane hybrydowe W przypadku zsynchronizowanych kont podejście jest inne. Podczas gdy administratorzy zasad uwierzytelniania mogą przypisywać unikatowe wartości do każdego konta użytkownika korzystającego z certyfikatu, powszechną praktyką w usłudze Microsoft Entra ID jest wypełnianie każdej wartości dla każdego konta, co sprawia, że jest to trudniejsze. Zamiast tego Microsoft Entra Connect powinien filtrować wartości przypisane do każdego konta, aby uzyskać unikatowe wartości wypełnione w danym koncie w Microsoft Entra ID. Reguła unikatowości ma zastosowanie w granicach pojedynczego katalogu/dzierżawy (czyli Administratorzy zasad uwierzytelniania mogą mapować certyfikat do użycia w innym katalogu/dzierżawie, pod warunkiem, że wartości pozostają unikatowe dla każdego konta). Ponadto organizacja może mieć wiele lasów AD przekazujących użytkowników do jednej dzierżawy Microsoft Entra. W takim przypadku program Microsoft Entra Connect stosuje filtr do każdego z tych lasów usługi AD w tym samym celu, aby uzupełnić konto w chmurze tylko żądaną unikatową wartością.

Wypełnij pole altSecurityIdentities w usłudze AD wartościami, które identyfikują żądany certyfikat, i uwzględnij wartość tego certyfikatu dla danego typu konta użytkownika (na przykład pracownik oddelegowany, administrator, deweloper itp.). Wybierz kluczowy atrybut w usłudze AD, który wskazuje synchronizacji, jaki typ konta użytkownika jest oceniany (np. msDS-cloudExtensionAttribute1). Wypełnij ten atrybut wartością typu użytkownika, którą chcesz, taką jak oddelegowany, 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>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Las 1 — Konto2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Las 2 — ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

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

Kroki synchronizacji do identyfikatorów użytkowników certyfikatu

1. Konfigurowanie programu Microsoft Entra Connect w celu dodania pola alternativeSecurityIds do metaverse
2. Dla każdego lasu AD skonfiguruj nową niestandardową regułę ruchu przychodzącego o wysokim priorytecie (niska liczba poniżej 100). Dodaj przekształcenie wyrażenia za pomocą pola altSecurityIdentities jako źródła. Wyrażenie docelowe 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 atrybut altSecurityIdentities i atrybut klucza msDS-cloudExtensionAttribute1is są najpierw sprawdzane, aby sprawdzić, czy zostały wypełnione. Jeśli nie, altSecurityIdentities jest sprawdzane, aby ustalić, czy zostało wypełnione. Jeśli jest ona pusta, ustawimy ją na wartość NULL. W przeciwnym razie konto przechodzi do przypadku domyślnego, a w tym przykładzie filtrujemy jedynie mapowanie Wystawca+Numer seryjny. Jeśli atrybut klucza jest wypełniany, sprawdzana jest wartość, aby sprawdzić, czy jest równa jednemu z naszych zdefiniowanych typów użytkowników. W tym przykładzie, jeśli wartość to 'detailee', to przefiltrowujemy wartość SHA1PublicKey z altSecurityIdentities. Jeśli wartość jest programistą, filtrujemy do wartości 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 pobiera wszystkie wartości i synchronizuje się z identyfikatorem Entra firmy Microsoft — nie tylko pierwszym, który znajdzie.

1. Drugi przykład pokazujący, jak wypchnąć pustą wartość, jeśli atrybut kontrolki jest pusty:

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 altSecurityIdentities nie jest zgodna z żadną wartością wyszukiwania w atrybucie kontrolnym, 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 firmy Microsoft.

1. Skonfiguruj nową niestandardową regułę ruchu wychodzącego o niskim priorytecie (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 firmy Microsoft.

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 z polem certificateUserIds, użytkownik zostaje pomyślnie zalogowany.

Opis procesu odwoływania certyfikatów

Proces odwoływania certyfikatów pozwala Administratorom Zasad Uwierzytelniania na odwołanie wcześniej wydanego certyfikatu, uniemożliwiając jego użycie w przyszłym uwierzytelnianiu. 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.

Administratorzy zasad uwierzytelniania mogą 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 odwołania certyfikatów (CRL) dla Microsoft Entra ID, który można pomyślnie pobrać przy interaktywnym logowaniu i przechować w pamięci podręcznej, wynosi 20 MB dla publicznego Microsoft Entra ID i 45 MB w chmurach Azure US Government. Czas wymagany do pobrania CRL nie może przekraczać 10 sekund. Jeśli Microsoft Entra ID nie może pobrać listy CRL, uwierzytelnianie oparte na certyfikatach 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 Microsoft Entra ID próbuje pobrać listę CRL z limitami po stronie usługi (45 MB w publicznej wersji Microsoft Entra ID i 150 MB w chmurach Azure US Government).

Ważne

Jeśli administrator zasad uwierzytelniania pomija konfigurację listy CRL, Microsoft Entra ID nie przeprowadza żadnej kontroli listy CRL podczas uwierzytelniania użytkownika opartego na certyfikatach. 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 dostępu do OCSP, Microsoft Entra ID pobiera ją raz przy pierwszym logowaniu i buforuje. To działanie poprawia wydajność i niezawodność weryfikacji 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 odwołanych certyfikatów (CRL):

1. Microsoft Entra ID próbuje pobrać Listę Unieważnionych Certyfikatów (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. Uwzględnia datę następnej aktualizacji i, jeśli jest dostępna, datę następnej publikacji CRL (używaną 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 jest skonfigurowana dla zaufanego wystawcy, ale Microsoft Entra ID nie może jej pobrać ze względu na ograniczenia związane z dostępnością, rozmiarem lub opóźnieniem.

   • Certyfikat użytkownika jest oznaczony 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 CA z końcowego certyfikatu klienta do weryfikacji CRL w łańcuchu PKI. Ograniczenie ma na celu zapewnienie, że złośliwy użytkownik nie spowoduje awarii usługi poprzez przekazanie łańcucha infrastruktury kluczy publicznych z ogromną liczbą urzędów certyfikacji, co prowadzi do zwiększenia rozmiaru listy CRL. Jeśli łańcuch PKI dzierżawy ma więcej niż 5 urzędów certyfikacji i jeśli dojdzie do kompromitacji urzędu certyfikacji, administratorzy zasad uwierzytelniania powinni usunąć kompromitowanego zaufanego wystawcę z konfiguracji dzierżawcy Microsoft Entra.

Ważne

Ze względu na charakter buforowania i publikowania listy CRL zdecydowanie zaleca się, aby w przypadku odwołania certyfikatu, unieważnić również wszystkie sesje użytkownika, którego certyfikat został unieważniony, w usłudze Microsoft Entra ID.

Obecnie nie ma możliwości ręcznego wymuszenia lub ponownego uruchomienia pobierania 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. Ostatni znacznik czasu publikacji (właściwość Effective Date) w liście CRL jest używany do zapewnienia, że lista CRL jest wciąż ważna. Lista CRL jest okresowo przeglądana w celu unieważnienia dostępu do certyfikatów, które są częścią tej 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 StsRefreshTokensValidFrom dla tego konkretnego użytkownika za pomocą programu Windows PowerShell. Należy zaktualizować pole StsRefreshTokensValidFrom dla każdego użytkownika, dla którego chcesz odwołać dostęp.

Aby upewnić się, że odwołanie będzie trwałe, należy ustawić datę wejścia w życie listy CRL na datę późniejszą niż wartość ustawiona przez StsRefreshTokensValidFrom i upewnić się, że certyfikat znajduje się na liście CRL.

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

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

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).

Zrozumienie weryfikacji CRL (wersja zapoznawcza)

Lista CRL to rekord certyfikatów cyfrowych, które zostały odwołane przed końcem okresu ważności przez urząd certyfikacji. Gdy urzędy certyfikacji są przekazywane do magazynu zaufania Microsoft Entra, CRL, a w szczególności atrybut CrlDistributionPoint, nie jest wymagany. Urząd certyfikacji można załadować bez punktu końcowego listy odwołania certyfikatów (CRL), a uwierzytelnianie oparte na certyfikatach nie zawiedzie, jeśli urząd wystawiający certyfikaty nie ma określonej listy odwołania certyfikatów.

Aby zwiększyć bezpieczeństwo i uniknąć błędów konfiguracji, administrator zasad uwierzytelniania może wymagać, aby uwierzytelnianie CBA zakończyło się niepowodzeniem, jeśli nie skonfigurowano listy CRL dla urzędu certyfikacji, który wystawia certyfikat użytkownika końcowego.

Włącz walidację CRL

Aby włączyć weryfikację CRL, wybierz Wymagaj weryfikacji CRL (zalecane).

Po włączeniu tej funkcji, każde niepowodzenie CBA jest spowodowane tym, że certyfikat użytkownika końcowego został wystawiony przez urząd certyfikacji, który nie skonfigurował Listy Certyfikatów Odwołanych (CRL).

Administrator polityki uwierzytelniania może wykluczyć urząd certyfikacji cyfrowej, jeśli jego lista odwołanych certyfikatów (CRL) ma problemy, które należy rozwiązać. Wybierz pozycję Dodaj zwolnienie i wybierz wszystkie urzędy certyfikacji, które powinny być zwolnione.

Urzędy certyfikacji na liście zwolnionych nie muszą mieć skonfigurowanej listy CRL, a certyfikaty użytkowników końcowych, które wystawiają, nie mają problemów z uwierzytelnianiem.

Uwaga

Istnieje znany problem z selektorem obiektów, w którym wybrane elementy nie są poprawnie wyświetlane. Użyj karty Urządy certyfikacji, aby wybrać lub usunąć urzędy certyfikacji.

Jak CBA działa z zasadą siły uwierzytelniania w dostępie warunkowym

Klienci mogą utworzyć zasady siły uwierzytelniania dla dostępu warunkowego w celu określenia, że CBA ma być używana do dostępu do zasobu.

Możesz użyć wbudowanego poziomu 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ć niestandardowy poziom uwierzytelniania, aby umożliwić dostęp do poufnych zasobów tylko za pomocą CBA. Można zezwolić na CBA w trybie jednoczynnikowym, wieloczynnikowym lub oba jednocześnie. 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 zasad uwierzytelniania 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.

Zrozumienie dzienników 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 SAN Principal Name 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ą informacji. Na przykład: Przyczyna niepowodzenia w dzienniku logowania będzie zawierała coś takiego, jak "Lista odwołania certyfikatów (CRL) nie przeszła walidacji podpisu". Oczekiwany identyfikator klucza podmiotu {expectedSKI} nie jest zgodny z kluczem urzędu certyfikacji CRL {crlAK}. Poproś administratora dzierżawy o sprawdzenie konfiguracji CRL, gdzie {expectedSKI} i {crlAKI} nie są uzupełnione 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 Microsoft Entra jako użytkownik testowy przy użyciu CBA. Zasady uwierzytelniania są skonfigurowane tak, że reguła dotycząca podmiotu wystawcy spełnia wymagania uwierzytelniania jednoskładnikowego.

2. Wyszukaj i wybierz 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 Microsoft Entra ID zweryfikował, że CBA jest włączone 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 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 Zalogowania.

   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 o stanie Przerwany 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	uwierzytelnianie wieloskładnikowe
   Typ poziomu uwierzytelniania certyfikatu użytkownika	IdentZasady Pokazuje to, że identyfikator OID polityki był używany do określenia mocy 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. Gdy CBA jest ponownie uruchamiane, przeglądarka wysyła certyfikat z pamięci podręcznej 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 zasad uwierzytelniania, 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ę CBA w przeglądarce, nadal będzie się nie udawać 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, metodą uwierzytelniania najczęściej używaną (MRU) przez użytkownika staje się 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

Użytkownik-gość B2B tożsamości zewnętrznej może używać CBA w dzierżawie gospodarza, a jeśli ustawienia międzydzierżawowe dla dzierżawy zasobów są skonfigurowane tak, aby ufać MFA z dzierżawy gospodarza, uwierzytelnienie CBA użytkownika w dzierżawie gospodarza jest respektowane. Aby uzyskać więcej informacji na temat włączania zaufanego uwierzytelniania wieloskładnikowego z dzierżaw Microsoft Entra, zobacz Konfigurowanie międzydzierżawowego dostępu współpracy B2B. Usługa CBA w dzierżawie zasobów nie jest jeszcze obsługiwana.

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