Udostępnij za pośrednictwem

Konfigurowanie obsługi usług AD FS na potrzeby uwierzytelniania certyfikatu użytkownika

W tym artykule opisano sposób włączania uwierzytelniania certyfikatu użytkownika w usługach Active Directory Federation Services (AD FS). Zawiera również informacje dotyczące rozwiązywania typowych problemów z uwierzytelnianiem tego typu.

Istnieją dwa główne przypadki użycia uwierzytelniania certyfikatu użytkownika:

  • Użytkownicy używają kart inteligentnych do logowania się w systemie usług AD FS.
  • Użytkownicy korzystają z certyfikatów wystawianych dla urządzeń przenośnych.

Wymagania wstępne

  • Określ tryb uwierzytelniania certyfikatu użytkownika w usługach AD FS, który chcesz włączyć, korzystając z jednego z trybów opisanych w obsłudze alternatywnego powiązania nazwy hosta dla uwierzytelniania certyfikatu w usługach AD FS.
  • Upewnij się, że łańcuch zaufania certyfikatów użytkownika jest zainstalowany i zaufany przez wszystkie serwery AD FS i serwery proxy aplikacji internetowej (WAP), w tym przez wszystkie pośrednie urzędy certyfikacji. Zazwyczaj można to zrobić za pośrednictwem obiektu zasad grupy (GPO) na serwerach usług AD FS i WAP.
  • Upewnij się, że główny certyfikat łańcucha zaufania dla certyfikatów użytkownika znajduje się w magazynie NTAuth w usłudze Active Directory.
  • Jeśli używasz AD FS w trybie uwierzytelniania certyfikatem alternatywnym, upewnij się, że serwery AD FS i WAP mają certyfikaty Secure Sockets Layer (SSL), które zawierają nazwę hosta AD FS z prefiksem "certauth". Przykładem jest certauth.fs.contoso.com. Upewnij się również, że ruch do tej nazwy hosta jest dozwolony przez zaporę.
  • Jeśli używasz uwierzytelniania certyfikatu z ekstranetu, upewnij się, że co najmniej jeden dostęp do informacji o urzędzie (AIA) i co najmniej jeden punkt dystrybucji listy CRL (CDP) lub lokalizacja protokołu OCSP (Online Certificate Status Protocol) z listy określonej w certyfikatach są dostępne z Internetu.
  • Jeśli konfigurujesz AD FS do uwierzytelniania certyfikatów firmy Microsoft Entra, upewnij się, że skonfigurowano ustawienia Microsoft Entra oraz reguły oświadczeń AD FS wymagane dla wystawcy certyfikatu i numeru seryjnego.
  • Jeśli używasz uwierzytelniania certyfikatu Microsoft Entra dla klientów Exchange ActiveSync, certyfikat klienta musi zawierać trasowalny adres e-mail użytkownika w usłudze Exchange Online w wartości Nazwy głównej użytkownika lub wartości Nazwy RFC822 pola Alternatywna nazwa podmiotu. Microsoft Entra ID przypisuje wartość RFC822 do atrybutu adresu proxy w katalogu.

Uwaga

Usługi AD FS nie obsługują wskazówek dotyczących nazw użytkowników przy użyciu karty inteligentnej ani uwierzytelniania opartego na certyfikatach.

Włączanie uwierzytelniania certyfikatu użytkownika

Włącz uwierzytelnianie certyfikatu użytkownika jako metodę uwierzytelniania w intranecie lub ekstranecie w AD FS, korzystając z konsoli zarządzania AD FS lub polecenia cmdlet programu PowerShell Set-AdfsGlobalAuthenticationPolicy.

Zagadnienia opcjonalne obejmują:

  • Jeśli chcesz używać oświadczeń opartych na polach i rozszerzeniach certyfikatów, oprócz typu oświadczenia EKU (https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku), skonfiguruj dodatkowe reguły przekazywania oświadczeń w zaufaniu dostawcy oświadczeń w usłudze Active Directory. Zobacz pełną listę oświadczeń dotyczących certyfikatów w dalszej części tego artykułu.

  • Jeśli chcesz ograniczyć dostęp na podstawie typu certyfikatu, możesz użyć dodatkowych właściwości certyfikatu w regułach autoryzacji wystawiania usług AD FS dla aplikacji. Typowe scenariusze to zezwalanie tylko na certyfikaty aprowidowane przez dostawcę zarządzania urządzeniami przenośnymi (MDM) lub zezwalanie tylko na certyfikaty kart inteligentnych.

    Ważne

    Klienci korzystający z mechanizmu przepływu kodu urządzenia do uwierzytelniania i uwierzytelniania urządzeń przy użyciu dostawcy tożsamości innego niż Microsoft Entra ID (na przykład AD FS) nie mogą wymuszać dostępu opartego na urządzeniu dla zasobów Microsoft Entra. Na przykład nie mogą zezwalać na dostęp tylko urządzeniom zarządzanym za pomocą usługi MDM innej firmy.

    Aby chronić dostęp do zasobów firmowych w usłudze Microsoft Entra ID i zapobiegać wyciekom danych, skonfiguruj dostęp warunkowy oparty na urządzeniach firmy Microsoft Entra. Na przykład użyj Wymagaj, aby urządzenie było oznaczone jako skarga w celu udzielenia kontroli w usłudze Microsoft Entra Conditional Access.

    Skonfiguruj dozwolone urzędy certyfikacji dla certyfikatów klientów, korzystając ze wskazówek w sekcji "Zarządzanie zaufanymi wystawcami na potrzeby uwierzytelniania klientów" w technicznym przeglądzie SSP .

  • Rozważ zmodyfikowanie stron logowania, aby odpowiadały potrzebom użytkowników podczas uwierzytelniania certyfikatu. Typowym przypadkiem jest zmiana Zaloguj się przy użyciu certyfikatu X509 na opcję bardziej przyjazną dla użytkownika.

Konfigurowanie bezproblemowego uwierzytelniania certyfikatów dla przeglądarki Chrome na komputerach z systemem Windows

Jeśli komputer ma wiele certyfikatów użytkownika (takich jak certyfikaty Wi-Fi), które spełniają cele uwierzytelniania klienta, przeglądarka Chrome na komputerach z systemem Windows wyświetli monit o wybranie odpowiedniego certyfikatu. Ten monit może być mylący dla użytkowników. Aby zoptymalizować to środowisko, możesz ustawić zasady dla programu Chrome, aby automatycznie wybierać odpowiedni certyfikat.

Tę zasadę można ustawić ręcznie, zmieniając ustawienia w rejestrze, lub skonfigurować ją automatycznie za pośrednictwem obiektu zasad grupy (GPO) w celu ustawienia kluczy rejestru. Wymaga to, aby certyfikaty klienta użytkownika na potrzeby uwierzytelniania w usługach AD FS miały odrębnych wystawców z innych przypadków użycia.

Aby uzyskać więcej informacji na temat konfigurowania uwierzytelniania certyfikatów dla przeglądarki Chrome, zobacz lista zasad programu Chrome Enterprise.

Rozwiązywanie problemów z uwierzytelnianiem certyfikatów

Skorzystaj z poniższych informacji, aby rozwiązać typowe problemy podczas konfigurowania usług AD FS na potrzeby uwierzytelniania certyfikatów dla użytkowników.

Sprawdź, czy zaufani wydawcy certyfikatów są poprawnie skonfigurowani na wszystkich serwerach AD FS i WAP

Jeśli zaufani wystawcy certyfikatów nie są prawidłowo skonfigurowani, typowym objawem jest błąd HTTP 204: "Brak zawartości od https://certauth.adfs.contoso.com.""

AD FS używa bazowego systemu operacyjnego Windows do udowodnienia posiadania certyfikatu użytkownika oraz aby upewnić się, że jest zgodny z zaufanym wystawcą, walidując łańcuch zaufania certyfikatu. Aby dopasować zaufanego wystawcę, należy upewnić się, że wszystkie główne i pośrednie urzędy są skonfigurowane jako zaufane wystawcy w magazynie lokalnym dla urzędów certyfikacji komputera.

Aby to sprawdzić automatycznie, użyj narzędzia Analizatora diagnostyki usług AD FS. Narzędzie wysyła zapytanie do wszystkich serwerów i zapewnia poprawną aprowizację odpowiednich certyfikatów.

  1. Pobierz i uruchom narzędzie.
  2. Przekaż wyniki i przejrzyj pod kątem ewentualnych błędów.

Sprawdź, czy uwierzytelnianie certyfikatu jest włączone w zasadach uwierzytelniania usług AD FS

Usługa AD FS domyślnie przeprowadza uwierzytelnianie certyfikatu użytkownika na porcie 49443 z tą samą nazwą hosta co AD FS (na przykład: adfs.contoso.com). Usługi AD FS można również skonfigurować tak, aby używały portu 443 (domyślnego portu HTTPS) przy użyciu alternatywnego powiązania SSL. Jednak adres URL używany w tej konfiguracji jest certauth.<adfs-farm-name> (na przykład: certauth.contoso.com). Aby uzyskać więcej informacji, zobacz obsługę AD FS alternatywnego powiązania nazwy hosta do uwierzytelniania certyfikatu.

Uwaga

W usługach AD FS w systemie Windows Server 2016 są teraz obsługiwane dwa tryby. Pierwszy tryb używa hosta adfs.contoso.com z portami 443 i 49443. Drugi tryb używa hostów adfs.contoso.com i certauth.adfs.contoso.com z portem 443. Potrzebujesz certyfikatu SSL do obsługi certauth.\<adfs-service-name> jako alternatywnej nazwy podmiotu. Można to zrobić w momencie tworzenia farmy lub później za pomocą PowerShell.

Najczęstszym przypadkiem problemów z łącznością sieciową jest to, że zapora została nieprawidłowo skonfigurowana i blokuje ruch na potrzeby uwierzytelniania certyfikatu użytkownika. Zazwyczaj po wystąpieniu tego problemu jest wyświetlany pusty ekran lub błąd serwera 500. Aby rozwiązać ten problem:

  1. Zwróć uwagę na nazwę hosta i port skonfigurowany w usługach AD FS.
  2. Upewnij się, że każda zapora przed usługami AD FS lub WAP jest skonfigurowana tak, aby zezwalała na kombinację hostname:port dla farmy usług AD FS. Inżynier sieci musi wykonać ten krok.

Sprawdź połączenie z CRL

Listy odwołania certyfikatów (CRL) to punkty końcowe zakodowane w certyfikacie użytkownika w celu przeprowadzenia kontroli odwołania środowiska uruchomieniowego. Jeśli na przykład urządzenie zawierające certyfikat zostanie skradzione, administrator może dodać certyfikat do listy odwołanych certyfikatów. Każdy punkt końcowy, który wcześniej zaakceptował ten certyfikat, nie przejdzie teraz uwierzytelnienia.

Każdy serwer usług AD FS i WAP musi uzyskać dostęp do punktu końcowego CRL, aby sprawdzić, czy certyfikat, który został przedstawiony, jest nadal ważny i nie został odwołany. Walidacja CRL może odbywać się za pośrednictwem protokołów HTTPS, HTTP, LDAP lub OCSP. Jeśli serwery usług AD FS i WAP nie mogą uzyskać dostępu do punktu końcowego, uwierzytelnianie zakończy się niepowodzeniem. Aby rozwiązać ten problem, wykonaj następujące czynności:

  1. Skontaktuj się z inżynierem infrastruktury kluczy publicznych (PKI), aby ustalić, które punkty końcowe CRL są wykorzystywane do odwoływania certyfikatów użytkowników z Twojego systemu PKI.
  2. Na każdym serwerze usług AD FS i WAP upewnij się, że punkty końcowe listy CRL są osiągalne za pośrednictwem używanego protokołu (zazwyczaj HTTPS lub HTTP).
  3. Aby uzyskać zaawansowaną walidację, włącz rejestrowanie zdarzeń CAPI2 na każdym serwerze AD FS i WAP.
  4. Sprawdź identyfikator zdarzenia 41 (Sprawdź odwołanie) w dziennikach operacyjnych CAPI2.
  5. Sprawdź <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Wskazówka

W celu łatwiejszego rozwiązywania problemów można określić pojedynczy serwer usług AD FS lub WAP, konfigurując rozpoznawanie nazw DNS (plik hostów w systemie Windows), aby wskazać określony serwer. Ta technika umożliwia włączenie śledzenia przez ukierunkowanie serwera.

Sprawdzanie problemów z interfejsem SNI

Usługi AD FS wymagają urządzeń klienckich (lub przeglądarek) i modułów równoważenia obciążenia do obsługi wskazania nazwy serwera (SNI). Niektóre urządzenia klienckie (na przykład starsze wersje systemu Android) mogą nie obsługiwać sieci SNI. Ponadto moduły równoważenia obciążenia mogą nie obsługiwać SNI ani nie być do niego skonfigurowane. W tych przypadkach prawdopodobnie wystąpią błędy certyfikacji użytkownika.

Aby rozwiązać ten problem, skontaktuj się z inżynierem sieci, aby upewnić się, że moduł równoważenia obciążenia dla usług AD FS i WAP obsługuje SNI. Jeśli nie można obsługiwać sieci SNI, użyj następującego obejścia w usługach AD FS:

  1. Otwórz okno wiersza polecenia z podwyższonym poziomem uprawnień na podstawowym serwerze usług AD FS.
  2. Wprowadź Netsh http show sslcert.
  3. Skopiuj identyfikator GUID aplikacji i skrót certyfikatu usługi federacyjnej.
  4. Wprowadź netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}.

Sprawdź, czy urządzenie klienckie zostało poprawnie skonfigurowane za pomocą certyfikatu

Możesz zauważyć, że niektóre urządzenia działają poprawnie, ale inne urządzenia nie działają. W większości przypadków oznacza to, że certyfikat użytkownika nie został poprawnie aprowizowany na niektórych urządzeniach klienckich. Wykonaj te kroki:

  1. Jeśli problem dotyczy urządzenia z systemem Android, najczęstszą przyczyną jest to, że łańcuch certyfikatów nie jest w pełni zaufany na urządzeniu. Zapoznaj się z dostawcą rozwiązania MDM, aby upewnić się, że certyfikat został poprawnie aprowizowany, a cały łańcuch jest w pełni zaufany na urządzeniu z systemem Android.

    Jeśli problem jest specyficzny dla urządzenia z systemem Windows, sprawdź, czy certyfikat jest poprawnie aprowizowany, sprawdzając magazyn certyfikatów systemu Windows dla zalogowanego użytkownika (nie systemu lub komputera).

  2. Wyeksportuj certyfikat użytkownika klienta do pliku .cer i uruchom polecenie certutil -f -urlfetch -verify certificatefilename.cer.

Sprawdź, czy wersja protokołu TLS jest zgodna z serwerami usług AD FS/WAP i urządzeniem klienckim

W rzadkich przypadkach urządzenie klienckie jest aktualizowane tak, aby obsługiwało tylko wyższą wersję protokołu TLS (na przykład 1.3). Może też wystąpić problem odwrotny, w którym usługi AD FS i serwery WAP zostały zaktualizowane tak, aby używały tylko wyższej wersji protokołu TLS, której urządzenie klienckie nie obsługuje.

Możesz użyć narzędzi ssl online, aby sprawdzić usługi AD FS i serwery WAP i sprawdzić, czy są one zgodne z urządzeniem. Aby uzyskać więcej informacji na temat kontrolowania wersji protokołu TLS, zobacz Zarządzanie protokołami SSL/TLS i zestawami szyfrowania dla usług AD FS.

Sprawdź, czy program Microsoft Entra PromptLoginBehavior jest poprawnie skonfigurowany w ustawieniach domeny federacyjnej

Wiele aplikacji Office 365 wysyła prompt=login do Microsoft Entra ID. Microsoft Entra ID domyślnie konwertuje go na nowe hasło logowania do usług AD FS. W związku z tym, nawet jeśli skonfigurowano uwierzytelnianie certyfikatu w usługach AD FS, użytkownicy widzą tylko logowanie przy użyciu hasła. Aby rozwiązać ten problem:

  1. Pobierz ustawienia domeny federacyjnej przy użyciu polecenia cmdlet Get-MgDomainFederationConfiguration.
  2. Upewnij się, że parametr PromptLoginBehavior jest ustawiony na wartość Disabled lub NativeSupport.

Aby uzyskać więcej informacji, zobacz obsługę parametru prompt=login usługi AD FS.

Dodatkowe procedury rozwiązywania problemów

W rzadkich przypadkach, jeśli listy CRL są bardzo długie, mogą one napotkać przekroczenie limitu czasu podczas próby pobrania. W takim przypadku należy zaktualizować MaxFieldLength i MaxRequestByte zgodnie z opisem w Http.sys ustawień rejestru systemu Windows.

Dokumentacja: Pełna lista typów oświadczeń certyfikatów użytkownika i przykładowych wartości

Typ oświadczenia Przykładowa wartość
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4