Rozwiązywanie problemów z logowania jednokrotnego z usługą Active Directory Federation Services (AD FS)

Ten artykuł ułatwia rozwiązywanie problemów z logowaniem jednokrotnym (SSO) z usługą Active Directory Federation Services (AD FS).

Wybierz jedną z poniższych sekcji zgodnie z typem napotkanego problemu.

Dotyczy: Active Directory Federation Services
Oryginalny numer KB: 4034932

NTLM lub monit o uwierzytelnianie oparte na formularzach

Podczas rozwiązywania problemów z logowaniem jednokrotnym (SSO) z usługą Active Directory Federation Services (AD FS), jeśli użytkownicy otrzymali nieoczekiwany monit uwierzytelniania NTLM lub formularzy, wykonaj kroki opisane w tym artykule, aby rozwiązać ten problem.

Sprawdzanie ustawień zintegrowanego uwierzytelniania systemu Windows

Aby rozwiązać ten problem, sprawdź ustawienia zintegrowanego uwierzytelniania systemu Windows w przeglądarce klienta, ustawienia usług AD FS i parametry żądania uwierzytelniania.

Sprawdzanie przeglądarki klienta użytkownika

Sprawdź następujące ustawienia w obszarze Opcje internetowe:

  • Na karcie Zaawansowane upewnij się, że włączono ustawienie Włącz zintegrowane uwierzytelnianie systemu Windows .
  • Zgodnie z instrukcjami Security>Local intranet>Sites>Advanced upewnij się, że adres URL usług AD FS znajduje się na liście witryn sieci Web.
  • Zgodnie z poziomem niestandardowym intranetu > lokalnego zabezpieczeń >upewnij się, że wybrano ustawienie Automatyczne logowanie tylko w strefie intranetowej.

Jeśli używasz przeglądarki Firefox, Chrome lub Safari, upewnij się, że są włączone równoważne ustawienia w tych przeglądarkach.

Sprawdzanie ustawień usług AD FS

Sprawdź ustawienie WindowsIntegratedFallback
  1. Otwórz Windows PowerShell z opcją Uruchom jako administrator.

  2. Pobierz globalne zasady uwierzytelniania, uruchamiając następujące polecenie:

    Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
    
  3. Sprawdź wartość atrybutu WindowsIntegratedFallbackEnabled .

Jeśli wartość to True, oczekuje się uwierzytelniania opartego na formularzach. Oznacza to, że żądanie uwierzytelniania pochodzi z przeglądarki, która nie obsługuje zintegrowanego uwierzytelniania systemu Windows. Zobacz następną sekcję dotyczącą sposobu obsługiwania przeglądarki.

Jeśli wartość to False, należy się spodziewać zintegrowanego uwierzytelniania systemu Windows.

Sprawdź ustawienie WIASupportedUsersAgents
  1. Pobierz listę obsługiwanych agentów użytkowników, uruchamiając następujące polecenie:

    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  2. Sprawdź listę ciągów agenta użytkownika zwracanych przez polecenie.

Sprawdź, czy ciąg agenta użytkownika przeglądarki znajduje się na liście. Jeśli nie, dodaj ciąg agenta użytkownika, wykonując poniższe kroki:

  1. Przejdź do strony, która http://useragentstring.com/ wykrywa i wyświetla ciąg agenta użytkownika przeglądarki.

  2. Pobierz listę obsługiwanych agentów użytkowników, uruchamiając następujące polecenie:

    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  3. Dodaj ciąg agenta użytkownika przeglądarki, uruchamiając następujące polecenie:

    $wiaStrings = $wiaStrings+"NewUAString"
    

    Przykład:

    $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
    
  4. Zaktualizuj ustawienie WIASupportedUserAgents, uruchamiając następujące polecenie:

    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
    

Sprawdzanie parametrów żądania uwierzytelniania

Sprawdź, czy żądanie uwierzytelniania określa uwierzytelnianie oparte na formularzach jako metodę uwierzytelniania
  1. Jeśli żądanie uwierzytelniania jest żądaniem WS-Federation, sprawdź, czy żądanie zawiera wauth= urn:oasis:names:tc:SAML:1.0:am:password.
  2. Jeśli żądanie uwierzytelniania jest żądaniem SAML, sprawdź, czy żądanie zawiera element samlp:AuthnContextClassRef z wartością urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Aby uzyskać więcej informacji, zobacz Omówienie procedur obsługi uwierzytelniania stron logowania usług AD FS.

Sprawdź, czy aplikacja jest usługą Microsoft Online Services dla Office 365

Jeśli aplikacja, do której chcesz uzyskać dostęp, nie jest usługą Microsoft Online Services, oczekiwane i kontrolowane przez przychodzące żądanie uwierzytelniania. Skontaktuj się z właścicielem aplikacji, aby zmienić zachowanie.

Uwaga

Moduły programu PowerShell Azure AD i MSOnline są przestarzałe od 30 marca 2024 r. Aby dowiedzieć się więcej, przeczytaj aktualizację wycofania. Po tej dacie obsługa tych modułów jest ograniczona do pomocy w 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 Tożsamość Microsoft Entra (dawniej Azure AD). Aby uzyskać typowe pytania dotyczące migracji, zapoznaj się z często zadawanymi pytaniami dotyczącymi migracji. Uwaga: W wersjach 1.0.x usługi MSOnline mogą wystąpić zakłócenia po 30 czerwca 2024 r.

Jeśli aplikacja jest usługą Microsoft Online Services, to, czego doświadczasz, może być kontrolowane przez ustawienie PromptLoginBehavior z zaufanego obiektu obszaru. To ustawienie określa, czy dzierżawcy Microsoft Entra wysyłają monit=logowanie do usług AD FS. Aby ustawić ustawienie PromptLoginBehavior , wykonaj następujące kroki:

  1. Otwórz Windows PowerShell z opcją "Uruchom jako administrator".

  2. Pobierz istniejące ustawienie federacji domeny, uruchamiając następujące polecenie:

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  3. Ustaw ustawienie PromptLoginBehavior, uruchamiając następujące polecenie:

    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
    

    Wartości parametru PromptLoginBehavior to:

    1. TranslateToFreshPasswordAuth: Tożsamość Microsoft Entra wysyła wauth i wfresh do usług AD FS zamiast prompt=login. Prowadzi to do żądania uwierzytelniania w celu użycia uwierzytelniania opartego na formularzach.
    2. NativeSupport: parametr prompt=login jest wysyłany tak samo jak do usług AD FS.
    3. Wyłączone: do usług AD FS nic nie jest wysyłane.

Aby dowiedzieć się więcej o poleceniu Set-MSOLDomainFederationSettings, zobacz Active Directory Federation Services prompt=login parameter support (Obsługa parametrów Active Directory Federation Services prompt=login).

scenariusz Microsoft Entra

Jeśli żądanie uwierzytelniania wysłane do Tożsamość Microsoft Entra zawierać parametr prompt=login, wyłącz funkcję prompt=login, uruchamiając następujące polecenie:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Po uruchomieniu tego polecenia Office 365 aplikacje nie będą uwzględniać parametru prompt=login w każdym żądaniu uwierzytelniania.

Scenariusz inny niż Microsoft Entra

Parametry żądania, takie jak WAUTH i RequestedAuthNContext w żądaniach uwierzytelniania, mogą mieć określone metody uwierzytelniania. Sprawdź, czy inne parametry żądania wymuszają nieoczekiwany monit o uwierzytelnienie. Jeśli tak, zmodyfikuj parametr żądania, aby użyć oczekiwanej metody uwierzytelniania.

Sprawdzanie, czy funkcja logowania jednokrotnego jest wyłączona

Jeśli logowanie jednokrotne jest wyłączone, włącz je i sprawdź, czy problem został rozwiązany.

Monit o uwierzytelnianie wieloskładnikowe

Aby rozwiązać ten problem, sprawdź, czy reguły oświadczeń w jednostce uzależnionej są prawidłowo ustawione na potrzeby uwierzytelniania wieloskładnikowego.

Uwierzytelnianie wieloskładnikowe można włączyć na serwerze usług AD FS, w jednostce uzależnionej lub w parametrze żądania uwierzytelniania. Sprawdź konfiguracje, aby sprawdzić, czy zostały prawidłowo ustawione. Jeśli uwierzytelnianie wieloskładnikowe jest oczekiwane, ale jest wielokrotnie monitowane, sprawdź reguły wystawiania jednostek uzależnionych, aby sprawdzić, czy oświadczenia uwierzytelniania wieloskładnikowego są przekazywane do aplikacji.

Aby uzyskać więcej informacji na temat uwierzytelniania wieloskładnikowego w usługach AD FS, zobacz następujące artykuły:

Sprawdzanie konfiguracji na serwerze usług AD FS i jednostce uzależnionej

Aby sprawdzić konfigurację na serwerze usług AD FS, zweryfikuj globalne reguły uwierzytelniania dodatkowego. Aby sprawdzić konfigurację jednostki uzależnionej, zweryfikuj dodatkowe reguły uwierzytelniania dla zaufania jednostki uzależnionej.

  1. Aby sprawdzić konfigurację na serwerze usług AD FS, uruchom następujące polecenie w oknie Windows PowerShell.

    Get-ADFSAdditionalAuthenticationRule
    

    Aby sprawdzić konfigurację jednostki uzależnionej, uruchom następujące polecenie:

    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
    

    Uwaga

    Jeśli polecenia nic nie zwracają, dodatkowe reguły uwierzytelniania nie są skonfigurowane. Pomiń tę sekcję.

  2. Obserwuj skonfigurowany zestaw reguł oświadczeń.

Sprawdź, czy uwierzytelnianie wieloskładnikowe jest włączone w zestawie reguł oświadczeń

Zestaw reguł oświadczeń składa się z następujących sekcji:

  • Instrukcja warunku: C:[Type=``…,Value=…]
  • Instrukcja problemu: => issue (Type=``…,Value=…)

Jeśli instrukcja problemu zawiera następujące oświadczenie, zostanie określone uwierzytelnianie wieloskładnikowe.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Poniżej przedstawiono przykłady, które wymagają użycia uwierzytelniania wieloskładnikowego w przypadku urządzeń nieprzyłączonych do miejsca pracy i dostępu do ekstranetu:

  • c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
  • c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Sprawdzanie reguł wystawiania jednostek uzależnionej

Jeśli użytkownik wielokrotnie otrzymuje monity o uwierzytelnianie wieloskładnikowe po wykonaniu pierwszego uwierzytelniania, możliwe jest, że strona odpowiadająca nie przekazuje do aplikacji oświadczeń uwierzytelniania wieloskładnikowego. Aby sprawdzić, czy oświadczenia uwierzytelniania są przekazywane, wykonaj następujące kroki:

  1. Uruchom następujące polecenie w Windows PowerShell:

    Get-ADFSRelyingPartyTrust -TargetName ClaimApp
    
  2. Obserwuj zestaw reguł zdefiniowany w atrybutach IssuanceAuthorizationRules lub IssuanceAuthorizationRulesFile.

Zestaw reguł powinien zawierać następującą regułę wystawiania, aby przekazywać oświadczenia uwierzytelniania wieloskładnikowego:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)

Sprawdzanie parametru żądania uwierzytelniania

Sprawdź, czy żądanie uwierzytelniania określa uwierzytelnianie wieloskładnikowe jako metodę uwierzytelniania

  • Jeśli żądanie uwierzytelniania jest żądaniem WS-Federation, sprawdź, czy żądanie zawiera wauth= http://schemas.microsoft.com/claims/multipleauthn.
  • Jeśli żądanie uwierzytelniania jest żądaniem SAML, sprawdź, czy żądanie zawiera element samlp:AuthnContextClassRef z wartością http://schemas.microsoft.com/claims/multipleauthn.

Aby uzyskać więcej informacji, zobacz Omówienie procedur obsługi uwierzytelniania stron logowania usług AD FS.

Sprawdź, czy aplikacja jest usługą Microsoft Online Services dla Office 365

Jeśli aplikacja, do którą chcesz uzyskać dostęp, to Usługi online firmy Microsoft dla Office 365, sprawdź ustawienie Federacja domeny SupportsMFA.

  1. Pobierz bieżące ustawienie federacji domeny SupportsMFA, uruchamiając następujące polecenie:

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  2. Jeśli ustawienie SupportsMFA ma wartość FALSE, ustaw wartość TRUE, uruchamiając następujące polecenie:

    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
    

Sprawdzanie, czy funkcja logowania jednokrotnego jest wyłączona

Jeśli logowanie jednokrotne jest wyłączone, włącz je i sprawdź, czy problem został rozwiązany.

Użytkownicy nie mogą zalogować się do docelowej witryny lub usługi

Ten problem może wystąpić na stronie logowania usług AD FS lub po stronie aplikacji.

Jeśli problem występuje na stronie logowania usług AD FS, zostanie wyświetlony komunikat "Wystąpił błąd", "Usługa HTTP 503 jest niedostępna" lub inny komunikat o błędzie. Adres URL strony błędu zawiera nazwę usługi AD FS, taką jak fs.contoso.com.

Jeśli problem występuje po stronie aplikacji, adres URL strony błędu zawiera adres IP lub nazwę witryny usługi docelowej.

Wykonaj kroki opisane w poniższej sekcji, aby uzyskać informacje o tym, gdzie występuje ten problem.

Ten problem występuje na stronie logowania usług AD FS

Aby rozwiązać ten problem, sprawdź, czy problem dotyczy wszystkich użytkowników i czy użytkownicy mogą uzyskiwać dostęp do wszystkich jednostek uzależnionych.

Problem dotyczy wszystkich użytkowników, a użytkownik nie może uzyskać dostępu do żadnej z jednostek uzależnionych

Sprawdźmy funkcję logowania wewnętrznego przy użyciu funkcji IdpInitiatedSignOn. W tym celu użyj strony IdpInititatedSignOn, aby sprawdzić, czy usługa AD FS jest uruchomiona i czy funkcja uwierzytelniania działa prawidłowo. Aby otworzyć stronę IdpInitiatedSignOn, wykonaj następujące kroki:

  1. Włącz stronę IdpInitiatedSignOn, uruchamiając następujące polecenie na serwerze usług AD FS:

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. Na komputerze znajdującym się wewnątrz sieci odwiedź następującą stronę:
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. Wprowadź poprawne poświadczenia prawidłowego użytkownika na stronie logowania.

Logowanie zakończyło się pomyślnie

Jeśli logowanie zakończy się pomyślnie, sprawdź, czy stan usługi AD FS jest uruchomiony.

  1. Na serwerze usług AD FS otwórz Menedżer serwera.
  2. W Menedżer serwera kliknij pozycję Usługi narzędzi>.
  3. Sprawdź, czy stanActive Directory Federation Services jest uruchomiony.

Następnie sprawdź funkcje logowania zewnętrznego przy użyciu funkcji IdpInitiatedSignOn. Użyj strony IdpInititatedSignOn, aby szybko sprawdzić, czy usługa AD FS jest uruchomiona i działa, a funkcja uwierzytelniania działa prawidłowo. Aby otworzyć stronę IdpInitiatedSignOn, wykonaj następujące kroki:

  1. Włącz stronę IdpInitiatedSignOn, uruchamiając następujące polecenie na serwerze usług AD FS:

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. Na komputerze, który znajduje się poza siecią, odwiedź następującą stronę:
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. Wprowadź poprawne poświadczenia prawidłowego użytkownika na stronie logowania.

Jeśli logowanie nie powiedzie się, zobacz Sprawdzanie składników i usług związanych z usługami AD FS i Sprawdź relację zaufania serwera proxy.

Jeśli logowanie zakończy się pomyślnie, kontynuuj rozwiązywanie problemów, wykonując kroki opisane w temacie Wszyscy użytkownicy, których dotyczy problem, a użytkownik może uzyskać dostęp do niektórych jednostek uzależnionych.

Logowanie nie powiodło się

Jeśli logowanie nie powiedzie się, sprawdź składniki i usługi związane z usługami AD FS.

Sprawdź, czy stan usługi AD FS jest uruchomiony.

  1. Na serwerze usług AD FS otwórz Menedżer serwera.
  2. W Menedżer serwera kliknij pozycję Usługi narzędzi>.
  3. Sprawdź, czy stanActive Directory Federation Services jest uruchomiony.

Sprawdź, czy punkty końcowe są włączone. Usługi AD FS udostępniają różne punkty końcowe dla różnych funkcji i scenariuszy. Nie wszystkie punkty końcowe są domyślnie włączone. Aby sprawdzić stan punktów końcowych, wykonaj następujące kroki:

  1. Na serwerze usług AD FS otwórz konsolę zarządzania usług AD FS.

  2. Rozwiń węzełPunkty końcoweusługi>.

  3. Znajdź punkty końcowe i sprawdź, czy stan jest włączony w kolumnie Włączone .

    Sprawdź stan wszystkich punktów końcowych usług AD F S są włączone.

Następnie sprawdź, czy program Microsoft Entra Connect jest zainstalowany. Zalecamy używanie programu Microsoft Entra Connect, co ułatwia zarządzanie certyfikatami SSL.

Jeśli program Microsoft Entra Connect jest zainstalowany, upewnij się, że używasz go do zarządzania certyfikatami SSL i aktualizowania ich.

Jeśli program Microsoft Entra Connect nie jest zainstalowany, sprawdź, czy certyfikat SSL spełnia następujące wymagania dotyczące usług AD FS:

  • Certyfikat pochodzi z zaufanego głównego urzędu certyfikacji.

    Usługi AD FS wymagają, aby certyfikaty SSL pochodziły z zaufanego głównego urzędu certyfikacji. Jeśli dostęp do usług AD FS jest uzyskiwany z komputerów nieprzyłączonych do domeny, zalecamy użycie certyfikatu SSL z zaufanego głównego urzędu certyfikacji innej firmy, takiego jak DigiCert, VeriSign itp. Jeśli certyfikat SSL nie pochodzi z zaufanego głównego urzędu certyfikacji, komunikacja SSL może się przerwać.

  • Nazwa podmiotu certyfikatu jest prawidłowa.

    Nazwa podmiotu powinna być zgodna z nazwą usługi federacyjnej, a nie nazwą serwera usług AD FS lub inną nazwą. Aby uzyskać nazwę usługi federacyjnej, uruchom następujące polecenie na podstawowym serwerze usług AD FS:
    Get-AdfsProperties | select hostname

  • Certyfikat nie został odwołany.

    Sprawdź, czy nie ma odwołania certyfikatu. Jeśli certyfikat zostanie odwołany, połączenie SSL nie może być zaufane i zostanie zablokowane przez klientów.

Jeśli certyfikat SSL nie spełnia tych wymagań, spróbuj uzyskać kwalifikowany certyfikat do komunikacji SSL. Zalecamy używanie programu Microsoft Entra Connect, co ułatwia zarządzanie certyfikatami SSL. Zobacz Aktualizowanie certyfikatu TLS/SSL dla farmy Active Directory Federation Services (AD FS).

Jeśli certyfikat SSL spełnia te wymagania, sprawdź następujące konfiguracje certyfikatu SSL.

Sprawdź, czy certyfikat SSL jest poprawnie zainstalowany

Certyfikat SSL należy zainstalować w magazynie osobistym komputera lokalnego na każdym serwerze federacyjnym w farmie. Aby zainstalować certyfikat, kliknij dwukrotnie przycisk . Plik PFX certyfikatu i postępuj zgodnie z instrukcjami kreatora.

Aby sprawdzić, czy certyfikat jest zainstalowany we właściwym miejscu, wykonaj następujące kroki:

  1. Wyświetl listę certyfikatów znajdujących się w magazynie osobistym komputera lokalnego, uruchamiając następujące polecenie:
    dir Cert:\LocalMachine\My
  2. Sprawdź, czy certyfikat znajduje się na liście.
Sprawdź, czy używany jest prawidłowy certyfikat SSL

Pobierz odcisk palca certyfikatu używanego do komunikacji SSL i sprawdź, czy odcisk palca jest zgodny z oczekiwanym odciskiem palca certyfikatu.

Aby uzyskać odcisk palca używanego certyfikatu, uruchom następujące polecenie w Windows PowerShell:

Get-AdfsSslCertificate

Jeśli używany jest nieprawidłowy certyfikat, ustaw poprawny certyfikat, uruchamiając następujące polecenie:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint
Sprawdź, czy certyfikat SSL jest ustawiony jako certyfikat komunikacji usługi

Certyfikat SSL należy ustawić jako certyfikat komunikacji usługi w farmie usług AD FS. Nie dzieje się to automatycznie. Aby sprawdzić, czy ustawiono prawidłowy certyfikat, wykonaj następujące kroki:

  1. W konsoli zarządzania usług AD FS rozwiń węzełCertyfikatyusługi>.
  2. Sprawdź, czy certyfikat wymieniony w obszarze Komunikacja usługi jest oczekiwanym certyfikatem.

Jeśli na liście znajduje się niewłaściwy certyfikat, ustaw poprawny certyfikat, a następnie przyznaj usłudze AD FS uprawnienie Odczyt do certyfikatu. Aby to zrobić, wykonaj następujące kroki.

  1. Ustaw prawidłowy certyfikat:

    1. Kliknij prawym przyciskiem myszy pozycję Certyfikaty, a następnie kliknij pozycję Ustaw certyfikat komunikacji usługi.
    2. Wybierz prawidłowy certyfikat.
  2. Sprawdź, czy usługa AD FS ma uprawnienie do odczytu certyfikatu:

    1. Dodaj przystawkę Certyfikaty dla konta komputera lokalnego do konsoli zarządzania firmy Microsoft (MMC).
    2. Rozwiń węzeł Certyfikaty (komputer lokalny)>Certyfikatyosobiste>.
    3. Kliknij prawym przyciskiem myszy certyfikat SSL, kliknij pozycję Wszystkie zadania>Zarządzaj kluczami prywatnymi.
    4. Sprawdź, czy adfssrv znajduje się na liście grup i nazw użytkowników z uprawnieniem Odczyt .
  3. Jeśli adfssrv nie znajduje się na liście, przyznaj usłudze AD FS uprawnienie Do odczytu certyfikatu:

    1. Kliknij przycisk Dodaj, kliknij pozycję Lokalizacje, kliknij serwer, a następnie kliknij przycisk OK.
    2. W obszarze Wprowadź nazwy obiektów do wybrania wprowadź nt service\adfssrv, kliknij pozycję Sprawdź nazwy, a następnie kliknij przycisk OK.
      Jeśli używasz usług AD FS z usługą rejestracji urządzeń (DRS), wprowadź nt service\drs zamiast.
    3. Przyznaj uprawnienie Odczyt , a następnie kliknij przycisk OK.
Sprawdź, czy usługa rejestracji urządzeń (DRS) jest skonfigurowana w usługach AD FS

Jeśli skonfigurowano usługi AD FS z usługą DRS, upewnij się, że certyfikat SSL jest również poprawnie skonfigurowany dla usług PULPITU ZDALNEGO. Jeśli na przykład istnieją dwa sufiksy contoso.com nazw UPN i fabrikam.com, certyfikat musi mieć enterpriseregistration.contoso.comenterpriseregistration.fabrikma.com i jako alternatywne nazwy podmiotu (SAN).

Aby sprawdzić, czy certyfikat SSL ma poprawne sieci SAN, wykonaj następujące kroki:

  1. Wyświetl listę wszystkich sufiksów nazw UPN używanych w organizacji, uruchamiając następujące polecenie:

    Get-AdfsDeviceRegistratrionUpnSuffix
    
  2. Sprawdź, czy certyfikat SSL ma skonfigurowane wymagane sieci SAN.

  3. Jeśli certyfikat SSL nie ma prawidłowych nazw DRS jako sieci SAN, uzyskaj nowy certyfikat SSL, który ma poprawne nazwy SAN dla usługi DRS, a następnie użyj go jako certyfikatu SSL dla usług AD FS.

Następnie sprawdź konfigurację certyfikatu na serwerach WAP i powiązania rezerwowe:

  • Sprawdź, czy na wszystkich serwerach WAP ustawiono poprawny certyfikat SSL.

    1. Upewnij się, że certyfikat SSL jest zainstalowany w magazynie osobistym komputera lokalnego na każdym serwerze WAP.

    2. Pobierz certyfikat SSL używany przez usługę WAP, uruchamiając następujące polecenie:

      Get-WebApplicationProxySslCertificate
      
    3. Jeśli certyfikat SSL jest nieprawidłowy, ustaw poprawny certyfikat SSL, uruchamiając następujące polecenie:

      Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
      
  • Sprawdź powiązania certyfikatów i zaktualizuj je w razie potrzeby.

    Aby obsługiwać przypadki inne niż SNI, administratorzy mogą określić powiązania rezerwowe. Inne niż standardowe powiązanie federationservicename:443 poszukaj powiązań rezerwowych w ramach następujących identyfikatorów aplikacji:

    • {5d89a20c-beab-4389-9447-324788eb944a}: Jest to identyfikator aplikacji dla usług AD FS.
    • {f955c070-e044-456c-ac00-e9e4275b3f04}: jest to identyfikator aplikacji dla serwer proxy aplikacji sieci Web.

    Jeśli na przykład certyfikat SSL jest określony dla powiązania rezerwowego, takiego jak 0.0.0.0:443, upewnij się, że powiązanie jest odpowiednio aktualizowane po zaktualizowaniu certyfikatu SSL.

Problem dotyczy wszystkich użytkowników, a użytkownik może uzyskać dostęp do niektórych jednostek uzależnionych

Najpierw uzyskajmy informacje o jednostce uzależnionej i kliencie OAuth. Jeśli używasz konwencjonalnej jednostki uzależnionej, wykonaj następujące kroki:

  1. Na podstawowym serwerze usług AD FS otwórz Windows PowerShell z opcją Uruchom jako administrator.

  2. Dodaj składnik usług AD FS 2.0 do Windows PowerShell, uruchamiając następujące polecenie:

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. Pobierz informacje jednostki uzależnionej, uruchamiając następujące polecenie:

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. Pobierz informacje o kliencie OAuth, uruchamiając następujące polecenie:

    $client = Get-AdfsClient ClientName
    

Jeśli używasz funkcji Grupy aplikacji w Windows Server 2016, wykonaj poniższe kroki:

  1. Na podstawowym serwerze usług AD FS otwórz Windows PowerShell z opcją Uruchom jako administrator.

  2. Pobierz informacje jednostki uzależnionej, uruchamiając następujące polecenie:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Jeśli klient OAuth jest publiczny, pobierz informacje o kliencie, uruchamiając następujące polecenie:

    $client = Get-AdfsNativeClientApplication ClientName
    

    Jeśli klient jest poufny, pobierz informacje o kliencie, uruchamiając następujące polecenie:

    $client = Get-AdfsServerApplication ClientName
    

Teraz kontynuuj korzystanie z następujących metod rozwiązywania problemów.

Sprawdzanie ustawień jednostki uzależnionej i klienta

Identyfikator jednostki uzależnionej, identyfikator klienta i identyfikator URI przekierowania powinny być udostępniane przez właściciela aplikacji i klienta. Jednak nadal może wystąpić niezgodność między tym, co zapewnia właściciel, a tym, co jest skonfigurowane w usługach AD FS. Na przykład niezgodność może być spowodowana literówką. Sprawdź, czy ustawienia podane przez właściciela są zgodne z ustawieniami skonfigurowanymi w usługach AD FS. Kroki opisane na poprzedniej stronie zawierają ustawienia skonfigurowane w usługach AD FS za pośrednictwem programu PowerShell.

Ustawienia udostępniane przez właściciela Ustawienia skonfigurowane w usługach AD FS
Identyfikator jednostki uzależnionej $rp. Identyfikator
Identyfikator URI przekierowania jednostki uzależnionej Prefiks lub dopasowanie symboli wieloznacznych
  • $rp. WSFedEndpoint dla jednostki uzależnionej WS-Fed
  • $rp. SamlEndpoints dla jednostki uzależnionej SAML
Identyfikator klienta $client. Clientid
Identyfikator URI przekierowania klienta Dopasowanie prefiksu $client. Identyfikator RedirectUri

Jeśli elementy w tabeli są zgodne, dodatkowo sprawdź, czy te ustawienia są zgodne między tym, co jest wyświetlane w żądaniu uwierzytelniania wysyłanym do usług AD FS, a tym, co jest skonfigurowane w usługach AD FS. Spróbuj odtworzyć problem podczas przechwytywania śledzenia programu Fiddler w żądaniu uwierzytelniania wysłanym przez aplikację do usług AD FS. Sprawdź parametry żądania, aby wykonać następujące kontrole w zależności od typu żądania.

Żądania OAuth

Żądanie OAuth wygląda następująco:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Sprawdź, czy parametry żądania są zgodne z ustawieniami skonfigurowanymi w usługach AD FS.

Parametry żądania Ustawienia skonfigurowane w usługach AD FS
client_id $client. Clientid
redirect_uri Dopasowanie prefiksu @client_RedirectUri

Parametr "zasób" powinien reprezentować prawidłową jednostkę uzależnioną w usługach AD FS. Pobierz informacje jednostki uzależnionej, uruchamiając jedno z następujących poleceń.

  • Jeśli używasz konwencjonalnej jednostki uzależnionej, uruchom następujące polecenie:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
  • Jeśli używasz funkcji Grupy aplikacji w Windows Server 2016, uruchom następujące polecenie:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"
żądania WS-Fed

Żądanie WS-Fed wygląda następująco:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Sprawdź, czy parametry żądania są zgodne z ustawieniami skonfigurowanymi w usługach AD FS:

Parametry żądania Ustawienia skonfigurowane w usługach AD FS
Wtrealm $rp. Identyfikator
Wreply Dopasowanie prefiksu lub dopasowanie symboli wieloznacznych $rp. WSFedEndpoint
Żądania SAML

Żądanie SAML wygląda następująco:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Dekoduj wartość parametru SAMLRequest przy użyciu opcji "From DeflatedSAML" w Kreatorze tekstu programu Fiddler. Zdekodowana wartość wygląda następująco:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Wykonaj następujące kontrole w ramach wartości zdekodowanej:

  • Sprawdź, czy nazwa hosta w wartości Docelowa jest zgodna z nazwą hosta usług AD FS.
  • Sprawdź, czy wartość wystawcy jest zgodna $rp.Identifierz wartością .

Dodatkowe uwagi dotyczące protokołu SAML:

  • $rp. SamlEndpoints: pokazuje wszystkie typy punktów końcowych SAML. Odpowiedź z usług AD FS jest wysyłana do odpowiednich adresów URL skonfigurowanych w punktach końcowych. Punkt końcowy SAML może używać powiązań przekierowania, wpisu lub artefaktu na potrzeby transmisji komunikatów. Wszystkie te adresy URL można skonfigurować w usługach AD FS.
  • $rp. SignedSamlRequestsRequired: Jeśli wartość jest ustawiona, należy podpisać żądanie SAML wysłane od jednostki uzależnionej. Parametry "SigAlg" i "Signature" muszą być obecne w żądaniu.
  • $rp. RequestSigningCertificate: jest to certyfikat podpisywania używany do generowania podpisu na żądanie SAML. Upewnij się, że certyfikat jest prawidłowy i poproś właściciela aplikacji o dopasowanie certyfikatu.
Sprawdzanie certyfikatu szyfrowania

Jeśli $rp.EncryptClaims zwraca wartość Włączone, szyfrowanie jednostki uzależnionej jest włączone. Usługi AD FS używa certyfikatu szyfrowania do szyfrowania oświadczeń. Wykonaj następujące testy:

  • $rp. EncryptionCertificate: użyj tego polecenia, aby pobrać certyfikat i sprawdzić, czy jest on prawidłowy.
  • $rp. EncryptionCertificateRevocationCheck: użyj tego polecenia, aby sprawdzić, czy certyfikat spełnia wymagania dotyczące sprawdzania odwołania.
Dwie poprzednie metody nie działają

Aby kontynuować rozwiązywanie problemów, zobacz Korzystanie z aplikacji Token zrzutu.

Problem dotyczy nie wszystkich użytkowników, a użytkownik nie może uzyskać dostępu do żadnej z jednostek uzależnionych

W tym scenariuszu wykonaj następujące testy.

Sprawdzanie, czy użytkownik jest wyłączony

Sprawdź stan użytkownika w Windows PowerShell lub interfejsie użytkownika. Jeśli użytkownik jest wyłączony, włącz użytkownika.

Sprawdzanie stanu użytkownika przy użyciu Windows PowerShell
  1. Zaloguj się do dowolnego kontrolera domeny.

  2. Otwórz Windows PowerShell.

  3. Sprawdź stan użytkownika, uruchamiając następujące polecenie:

    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    

    Użyj polecenia Get-ADUser, aby sprawdzić stan włączonego użytkownika.

Sprawdzanie stanu użytkownika w interfejsie użytkownika
  1. Zaloguj się do dowolnego kontrolera domeny.

  2. Otwórz konsolę zarządzania Użytkownicy i komputery usługi Active Directory.

  3. Kliknij węzeł Użytkownicy , kliknij prawym przyciskiem myszy użytkownika w okienku po prawej stronie, a następnie kliknij pozycję Właściwości.

  4. Kliknij kartę Konto .

  5. W obszarze Opcje konta sprawdź, czy konto jest wyłączone , jest zaznaczone.

    Sprawdź, czy opcja Konto jest wyłączona, jest zaznaczona.

  6. Jeśli opcja jest zaznaczona, usuń jej zaznaczenie.

Sprawdzanie, czy właściwości użytkownika zostały ostatnio zaktualizowane

Jeśli dowolna właściwość użytkownika zostanie zaktualizowana w usłudze Active Directory, spowoduje to zmianę metadanych obiektu użytkownika. Sprawdź obiekt metadanych użytkownika, aby zobaczyć, które właściwości zostały ostatnio zaktualizowane. Jeśli zostaną znalezione zmiany, upewnij się, że zostały one odebrane przez powiązane usługi. Aby sprawdzić, czy w użytkowniku nastąpiły zmiany właściwości, wykonaj następujące kroki:

  1. Zaloguj się do kontrolera domeny.

  2. Otwórz Windows PowerShell.

  3. Pobierz metadane obiektu użytkownika, uruchamiając następujące polecenie:
    repadmin /showobjmeta <destination DC> "user DN"

    Przykładem polecenia jest:
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. W metadanych sprawdź kolumnę Time/Date dla każdego atrybutu pod kątem jakichkolwiek wskazówek dotyczących zmiany. W poniższym przykładzie atrybut userPrincipleName przyjmuje nowszą datę niż inne atrybuty, które reprezentują zmianę metadanych obiektu użytkownika.

    Dane wyjściowe polecenia repadmin showobjmeta.

Sprawdzanie zaufania lasu, jeśli użytkownik należy do innego lasu

W środowisku usług AD FS z wieloma lasami między lasem, w którym wdrożono usługi AD FS, a innymi lasami, które używają wdrożenia usług AD FS do uwierzytelniania, jest wymagane zaufanie lasu dwukierunkowego. Aby sprawdzić, czy relacja zaufania między lasami działa zgodnie z oczekiwaniami, wykonaj następujące kroki:

  1. Zaloguj się do kontrolera domeny w lesie, w którym wdrożono usługi AD FS.

  2. Otwórz konsolę zarządzania Domenami i relacjami zaufania usługi Active Directory .

  3. W konsoli zarządzania kliknij prawym przyciskiem myszy domenę zawierającą zaufanie, które chcesz zweryfikować, a następnie kliknij pozycję Właściwości.

  4. Kliknij kartę Trusts (Zaufania ).

  5. W obszarze Domeny zaufane przez tę domenę (relacje zaufania wychodzące) lub Domeny, które ufają tej domenie (przychodzące relacje zaufania), kliknij relację zaufania do zweryfikowania, a następnie kliknij pozycję Właściwości.

  6. Kliknij pozycję Weryfikuj.
    W oknie dialogowym Active Directory Domain Services wybierz jedną z opcji.

    • Jeśli wybierzesz pozycję Nie, zalecamy powtórzenie tej samej procedury dla domeny wzajemnej.

    • Jeśli wybierzesz pozycję Tak, podaj poświadczenia użytkownika administracyjnego dla domeny wzajemnej. Nie ma potrzeby wykonywania tej samej procedury dla domeny wzajemnej.

      Zweryfikuj zaufanie przychodzące w oknie dialogowym Active Directory Domain Services.

Jeśli te kroki nie pomogły w rozwiązaniu problemu, kontynuuj rozwiązywanie problemów, wykonując kroki opisane w sekcji Nie wszyscy użytkownicy, na które ma wpływ ten problem, a użytkownik może uzyskać dostęp do części sekcji jednostki uzależnionej .

Problem dotyczy nie wszystkich użytkowników, a użytkownik może uzyskać dostęp do niektórych jednostek uzależnionych

W tym scenariuszu sprawdź, czy ten problem występuje w scenariuszu Microsoft Entra. Jeśli tak, wykonaj te testy, aby rozwiązać ten problem. Jeśli nie, zobacz Use the Dump Token app to troubleshoot this issue (Rozwiązywanie tego problemu przy użyciu aplikacji tokenu zrzutu ).

Sprawdź, czy użytkownik jest synchronizowany z Tożsamość Microsoft Entra

Jeśli użytkownik próbuje zalogować się do Tożsamość Microsoft Entra, zostanie przekierowany do usług AD FS w celu uwierzytelnienia dla domeny federacyjnej. Jedną z możliwych przyczyn niepowodzenia logowania jest to, że użytkownik nie jest jeszcze zsynchronizowany z Tożsamość Microsoft Entra. Po pierwszej próbie uwierzytelnienia w usługach AD FS może zostać wyświetlona pętla z Tożsamość Microsoft Entra do usług Active Directory FS. Aby ustalić, czy użytkownik jest synchronizowany z Tożsamość Microsoft Entra, wykonaj następujące kroki:

  1. Pobierz i zainstaluj moduł Azure AD programu PowerShell dla Windows PowerShell.
  2. Otwórz Windows PowerShell z opcją "Uruchom jako administrator".
  3. Zainicjuj połączenie z Tożsamość Microsoft Entra, uruchamiając następujące polecenie:
    Connect-MsolService
  4. Podaj poświadczenia administratora globalnego dla połączenia.
  5. Pobierz listę użytkowników w Tożsamość Microsoft Entra, uruchamiając następujące polecenie:
    Get-MsolUser
  6. Sprawdź, czy użytkownik znajduje się na liście.

Jeśli użytkownik nie znajduje się na liście, zsynchronizuj użytkownika z Tożsamość Microsoft Entra.

Sprawdzanie identyfikatora immutableID i nazwy UPN w regule oświadczenia wystawiania

Tożsamość Microsoft Entra wymaga niezmiennego identyfikatora ID i nazwy UPN użytkownika w celu uwierzytelnienia użytkownika.

Uwaga

Identyfikator immutableID jest również nazywany sourceAnchor w następujących narzędziach:

  • Azure AD Sync
  • Azure Active Directory Sync (DirSync)

Administratorzy mogą używać programu Microsoft Entra Connect do automatycznego zarządzania zaufaniem usług AD FS przy użyciu Tożsamość Microsoft Entra. Jeśli nie zarządzasz zaufaniem za pośrednictwem programu Microsoft Entra Connect, zalecamy, aby to zrobić, pobierając Microsoft Entra Connect Microsoft Entra Connect umożliwia automatyczne zarządzanie regułami oświadczeń na podstawie ustawień synchronizacji.

Aby sprawdzić, czy reguły oświadczeń dla niezmiennych identyfikatorów ID i NAZW UPN w usługach AD FS są zgodne z Tożsamość Microsoft Entra, wykonaj następujące kroki:

  1. Pobierz sourceAnchor i NAZWĘ UPN w programie Microsoft Entra Connect.

    1. Otwórz Microsoft Entra Connect.

    2. Kliknij pozycję Wyświetl bieżącą konfigurację.

      Wybierz pozycję Wyświetl bieżącą konfigurację na stronie Microsoft Entra Łączenie dodatkowych zadań.

    3. Na stronie Przeglądanie rozwiązania zanotuj wartości KOTWICA ŹRÓDŁA i GŁÓWNA NAZWA UŻYTKOWNIKA.

  2. Sprawdź wartości niezmiennych identyfikatorów ID (sourceAnchor) i nazwy UPN w odpowiedniej regule oświadczeń skonfigurowanej na serwerze usług AD FS.

    1. Na serwerze usług AD FS otwórz konsolę zarządzania usług AD FS.

    2. Kliknij pozycję Relacje zaufania jednostki uzależnionej.

    3. Kliknij prawym przyciskiem myszy relację zaufania jednostki uzależnionej z Tożsamość Microsoft Entra, a następnie kliknij pozycję Edytuj zasady wystawiania oświadczeń.

    4. Otwórz regułę oświadczenia dla niezmiennego identyfikatora i nazwy UPN.

    5. Sprawdź, czy zmienne, których dotyczy zapytanie o wartości niezmienialnymi identyfikatorami ID i NAZWĄ UPN, są takie same, jak te wyświetlane w programie Microsoft Entra Connect.

      Sprawdź wartości niezmiennych identyfikatorów ID i nazwy UPN w odpowiedniej regule oświadczeń skonfigurowanej na serwerze usług AD F S.

  3. Jeśli istnieje różnica, użyj jednej z poniższych metod:

    • Jeśli usługi AD FS są zarządzane przez program Microsoft Entra Connect, zresetuj relację zaufania jednostki uzależnionej przy użyciu programu Microsoft Entra Connect.
    • Jeśli usługi AD FS nie są zarządzane przez program Microsoft Entra Connect, popraw oświadczenia przy użyciu odpowiednich atrybutów.

Jeśli te kontrole nie pomogły rozwiązać problemu, zobacz Temat Rozwiązywanie tego problemu za pomocą aplikacji Token zrzutu .

Ten problem występuje po stronie aplikacji

Jeśli certyfikat podpisywania tokenu został niedawno odnowiony przez usługi AD FS, sprawdź, czy nowy certyfikat został odebrany przez partnera federacyjnego. W przypadku, gdy usługi AD FS używa tokenu odszyfrowywania certyfikatu, który również został odnowiony niedawno, wykonaj również tę samą kontrolę. Aby sprawdzić, czy bieżący certyfikat podpisywania tokenu usług AD FS w usługach AD FS jest zgodny z certyfikatem partnera federacyjnego, wykonaj następujące kroki:

  1. Pobierz bieżący certyfikat podpisywania tokenu w usługach AD FS, uruchamiając następujące polecenie:

    Get-ADFSCertificate -CertificateType token-signing
    
  2. Na liście zwróconych certyfikatów znajdź ten z wartością IsPrimary = TRUE i zanotuj odcisk palca.

  3. Pobierz odcisk palca bieżącego certyfikatu podpisywania tokenu u partnera federacyjnego. Właściciel aplikacji musi ci to podać.

  4. Porównaj odciski palca dwóch certyfikatów.

Wykonaj tę samą kontrolę, czy usługi AD FS używa odnowionego certyfikatu odszyfrowywania tokenu, z tą różnicą, że polecenie pobierania certyfikatu odszyfrowywania tokenu w usługach AD FS jest następujące:

Get-ADFSCertificate -CertificateType token-decrypting

Odciski palca dwóch certyfikatów są zgodne

Jeśli odciski palca są zgodne, upewnij się, że partnerzy używają nowych certyfikatów usług AD FS.

Jeśli występują niezgodności certyfikatów, upewnij się, że partnerzy używają nowych certyfikatów. Certyfikaty są uwzględniane w metadanych federacji opublikowanych przez serwer usług AD FS.

Uwaga

Partnerzy odwołują się do wszystkich partnerów organizacji zasobów lub organizacji kont reprezentowanych w usługach AD FS przez relacje zaufania jednostki uzależnionej i relacje zaufania dostawcy oświadczeń.

  • Partnerzy mogą uzyskiwać dostęp do metadanych federacji

    Jeśli partnerzy mogą uzyskać dostęp do metadanych federacji, poproś partnerów o użycie nowych certyfikatów.

  • Partnerzy nie mogą uzyskać dostępu do metadanych federacji

    W takim przypadku należy ręcznie wysłać partnerom klucze publiczne nowych certyfikatów. Aby to zrobić, wykonaj następujące kroki.

    1. Wyeksportuj klucze publiczne jako pliki cert lub jako pliki p7b, aby uwzględnić całe łańcuchy certyfikatów.
    2. Wyślij klucze publiczne do partnerów.
    3. Poproś partnerów o użycie nowych certyfikatów.

Odciski palca dwóch certyfikatów nie są zgodne

Następnie sprawdź, czy istnieje niezgodność algorytmu podpisywania tokenu. Aby to zrobić, wykonaj następujące kroki.

  1. Określ algorytm używany przez jednostkę uzależnioną, uruchamiając następujące polecenie:

    Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
    

    Możliwe wartości to SHA1 lub SHA256.

  2. Skontaktuj się z właścicielem aplikacji, aby uzyskać algorytm używany po stronie aplikacji.

  3. Sprawdź, czy dwa algorytmy są zgodne.

Jeśli te dwa algorytmy są zgodne, sprawdź, czy format identyfikatora nazwy jest zgodny z wymaganiami aplikacji.

  1. Na serwerze usług AD FS zrzuć reguły przekształcania wystawiania, uruchamiając następujące polecenie:

    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
    
  2. Znajdź regułę, która wystawia oświadczenie NameIdentifier. Jeśli taka reguła nie istnieje, pomiń ten krok.

    Oto przykład reguły:

    c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

    Zwróć uwagę na format NameIdentifier w następującej składni:

    Properties["Property-type-URI"] = "ValueURI"

    Poniżej wymieniono możliwe formaty. Pierwszy format jest domyślny.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
  3. Poproś właściciela aplikacji o format NameIdentifier wymagany przez aplikację.

  4. Sprawdź, czy dwa formaty NameIdentifier są zgodne.

  5. Jeśli formaty nie są zgodne, skonfiguruj oświadczenie NameIdentifier tak, aby używało formatu wymaganej przez aplikację. Aby to zrobić, wykonaj następujące kroki.

    1. Otwórz konsolę zarządzania usług AD FS.
    2. Kliknij pozycję Relacje zaufania jednostki uzależnionej, wybierz odpowiedniego partnera federacyjnego, a następnie kliknij pozycję Edytuj zasady wystawiania oświadczeń w okienku Akcje .
    3. Dodaj nową regułę, jeśli nie ma reguły wystawiania oświadczenia NameIdentifier, lub zaktualizuj istniejącą regułę. Wybierz pozycję Identyfikator nazwydla typu oświadczenia przychodzącego, a następnie określ format wymagany przez aplikację.

    Dodaj regułę oświadczenia przekształcenia, jeśli nie ma reguły wystawiania oświadczenia NameIdentifier, lub zaktualizuj istniejącą regułę.

Jeśli dwa algorytmy są niezgodne, zaktualizuj algorytm podpisywania używany przez zaufanie jednostki uzależnionej.

  1. Otwórz konsolę zarządzania usług AD FS.

  2. Kliknij prawym przyciskiem myszy relację zaufania jednostki uzależnionej, a następnie kliknij pozycję Właściwości.

  3. Na karcie Zaawansowane wybierz algorytm zgodny z wymaganiami aplikacji.

    Wybierz algorytm zgodny z wymaganiami aplikacji na karcie Zaawansowane w oknie dialogowym Ustawienie właściwości.

Informacje o automatycznym odnawianiu certyfikatu

Jeśli certyfikat podpisywania tokenu lub certyfikat odszyfrowywania tokenu są podpisane samodzielnie, funkcja AutoCertificateRollover jest domyślnie włączona dla tych certyfikatów, a usługi AD FS zarządza automatycznym odnawianiem certyfikatów, gdy są one bliskie wygaśnięcia.

Aby określić, czy używasz certyfikatów z podpisem własnym, wykonaj następujące kroki:

  1. Uruchom następujące polecenie:

    Get-ADFSCerticate -CertificateType "token-signing"
    

    Uruchom polecenie cmdlet Get-ADFSCerticate Certificate Type token-signing.

  2. Sprawdź atrybuty certyfikatu.

    Jeśli atrybuty Podmiot i Wystawca zaczynają się od "CN=ADFS Signing...", certyfikat jest podpisem własnym i jest zarządzany przez funkcję AutoCertRollover.

Aby potwierdzić, czy certyfikaty są odnawiane automatycznie, wykonaj następujące kroki:

  1. Uruchom następujące polecenie:

    Get-ADFSProperties | FL AutoCertificateRollover
    

    Uruchom polecenie cmdlet Get-ADFSProperties, aby potwierdzić, czy certyfikaty są odnawiane automatycznie.

  2. Sprawdź atrybut AutoCertificateRollover.

    • Jeśli AutoCertificateRollover = TRUE, usługi AD FS automatycznie generuje nowe certyfikaty (domyślnie 30 dni przed wygaśnięciem) i ustawia je jako certyfikaty podstawowe (25 dni przed wygaśnięciem).
    • Jeśli AutoCertificateRollover = FALSE, należy ręcznie zastąpić certyfikaty.

W tym artykule przedstawiono sposób sprawdzania składników i usług związanych z usługami AD FS. Te kroki mogą pomóc w rozwiązywaniu problemów z logowaniem (SSO) w usłudze Active Directory Federation Services (ADFS).

Sprawdzanie systemu DNS

Dostęp do usług ADFS powinien wskazywać bezpośrednio jeden z serwerów WAP (Web serwer proxy aplikacji) lub moduł równoważenia obciążenia przed serwerami WAP. Wykonaj następujące testy:

  • Wyślij polecenie ping do nazwy usługi federacyjnej (np. fs.contoso.com). Sprawdź, czy adres IP rozpoznany przez polecenie Ping należy do jednego z serwerów WAP lub modułu równoważenia obciążenia serwerów WAP.
  • Sprawdź, czy istnieje rekord A dla usługi federacyjnej na serwerze DNS. Rekord A powinien wskazywać jeden z serwerów WAP lub moduł równoważenia obciążenia serwerów WAP.

Jeśli protokół WAP nie jest zaimplementowany w scenariuszu dostępu zewnętrznego, sprawdź, czy dostęp do punktów usług AD FS jest uzyskiwany bezpośrednio do jednego z serwerów usług AD FS lub modułu równoważenia obciążenia przed serwerami usług ADFS:

  • Wyślij polecenie ping do nazwy usługi federacyjnej (np. fs.contoso.com). Upewnij się, że adres IP rozpoznany na jednym z serwerów usług AD FS lub modułu równoważenia obciążenia serwerów usług AD FS.
  • Sprawdź, czy istnieje rekord A dla usługi federacyjnej na serwerze DNS. Rekord A powinien wskazywać jeden z serwerów usług AD FS lub moduł równoważenia obciążenia serwerów usług AD FS.

Sprawdzanie modułu równoważenia obciążenia, czy jest on używany

Sprawdź, czy zapora blokuje ruch między:

  • Serwer usług ADFS i moduł równoważenia obciążenia.
  • Serwer WAP (Web serwer proxy aplikacji) i moduł równoważenia obciążenia, jeśli jest używany protokół WAP.

Jeśli sonda jest włączona w module równoważenia obciążenia, sprawdź następujące kwestie:

  • Jeśli używasz Windows Server 2012 R2, upewnij się, że pakiet zbiorczy aktualizacji z sierpnia 2014 r. jest zainstalowany.
  • Sprawdź, czy port 80 jest włączony w zaporze na serwerach WAP i serwerach usług AD FS.
  • Upewnij się, że dla portu 80 i dla punktu końcowego /adfs/probe ustawiono sondę.

Sprawdzanie ustawień zapory

Sprawdź, czy ruch przychodzący przez port TCP 443 jest włączony:

  • zapora między serwerem serwer proxy aplikacji sieci Web a farmą serwerów federacyjnych.
  • zapory między klientami a serwerem serwer proxy aplikacji sieci Web.

Sprawdź, czy ruch przychodzący przez port TCP 49443 jest włączony w zaporze między klientami a serwerem sieci Web serwer proxy aplikacji, gdy spełnione są następujące warunki:

  • Uwierzytelnianie klienta protokołu TLS przy użyciu certyfikatu X.509 jest włączone.
  • Używasz usług ADFS w Windows Server 2012 R2.

Uwaga

Konfiguracja nie jest wymagana w zaporze między serwerem serwer proxy aplikacji sieci Web a serwerami federacyjnymi.

Sprawdź, czy punkt końcowy jest włączony na serwerze proxy

Usługa ADFS udostępnia różne punkty końcowe dla różnych funkcji i scenariuszy. Nie wszystkie punkty końcowe są domyślnie włączone. Aby sprawdzić, czy punkt końcowy jest włączony na serwerze proxy, wykonaj następujące kroki:

  1. Na serwerze usług ADFS otwórz konsolę zarządzania usług AD FS.

  2. Rozwiń węzełPunkty końcoweusługi>.

  3. Znajdź punkt końcowy i sprawdź, czy stan jest włączony w kolumnie Włączono serwer proxy .

    Sprawdź stan punktów końcowych usług AD F S wyświetlany w kolumnie Włączono serwer proxy.

Sprawdzanie relacji zaufania serwera proxy

Jeśli wdrożono serwer proxy aplikacji sieci Web (WAP), należy ustanowić relację zaufania serwera proxy między serwerem WAP a serwerem usług AD FS. Sprawdź, czy relacja zaufania serwera proxy została ustanowiona, czy zaczyna kończyć się niepowodzeniem w pewnym momencie.

Uwaga

Informacje na tej stronie dotyczą usług AD FS 2012 R2 i nowszych.

Informacje podstawowe

Relacja zaufania serwera proxy jest oparta na certyfikacie klienta. Po uruchomieniu kreatora serwer proxy aplikacji sieci Web po instalacji kreator generuje certyfikat klienta z podpisem własnym przy użyciu poświadczeń określonych w kreatorze. Następnie kreator wstawia certyfikat do bazy danych konfiguracji usług AD FS i dodaje go do magazynu certyfikatów AdfsTrustedDevices na serwerze usług AD FS.

W przypadku dowolnej komunikacji SSL http.sys używa następującej kolejności priorytetu dla powiązań certyfikatów SSL w celu dopasowania certyfikatu:

Priority (Priorytet) Name (Nazwa) Parametry Opis
1 Adres IP IP:port Dokładne dopasowanie adresów IP i portów
2 SNI Nazwa hosta:port Dokładne dopasowanie nazwy hosta (połączenie musi określać SNI)
3 CCS Port Wywoływanie centralnego magazynu certyfikatów
4 Symbol wieloznaczny IPv6 Port Dopasowanie symbolu wieloznacznego IPv6 (połączenie musi być IPv6)
5 Symbol wieloznaczny adresu IP Port Dopasowanie symbolu wieloznacznego adresu IP (połączenie może mieć wartość IPv4 lub IPv6)

Usługi AD FS 2012 R2 i nowsze są niezależne od usług Internet Information Services (IIS) i działają jako usługa oprócz http.sys. hostname:port powiązania certyfikatów SSL są używane przez usługi AD FS. Podczas uwierzytelniania certyfikatu klienta usługi AD FS wysyła listę zaufania certyfikatów (CTL) na podstawie certyfikatów w magazynie AdfsTrustedDevices. Jeśli powiązanie certyfikatu SSL dla serwera usług AD FS używa adresu IP:port lub magazyn CTL nie jest AdfsTrustedDevices, relacja zaufania serwera proxy może nie zostać ustanowiona.

Pobieranie powiązań certyfikatów SSL dla usług AD FS

Na serwerze usług AD FS uruchom następujące polecenie w Windows PowerShell:
netsh http show sslcert

Na liście zwróconych powiązań poszukaj tych z identyfikatorem aplikacji 5d89a20c-beab-4389-9447-324788eb944a. Oto przykład powiązania w dobrej kondycji. Zwróć uwagę na wiersz "Nazwa magazynu Ctl".

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Uruchamianie skryptu w celu automatycznego wykrywania problemów

Aby automatycznie wykryć problemy z relacją zaufania serwera proxy, uruchom następujący skrypt. Na podstawie wykrytego problemu należy odpowiednio wykonać akcję.

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Problem 1: Istnieje powiązanie specyficzne dla adresu IP

Powiązanie może spowodować konflikt z powiązaniem certyfikatu usług AD FS na porcie 443.

Powiązanie IP:port ma najwyższy priorytet. Jeśli powiązanie ip:port znajduje się w powiązaniach certyfikatów SSL usług AD FS, http.sys zawsze używa certyfikatu do powiązania komunikacji SSL. Aby rozwiązać ten problem, użyj następujących metod.

  1. Usuwanie powiązania IP:port

    Należy pamiętać, że powiązanie IP:port może wrócić po jego usunięciu. Na przykład aplikacja skonfigurowana przy użyciu tego powiązania IP:port może automatycznie utworzyć je ponownie przy następnym uruchomieniu usługi.

  2. Używanie innego adresu IP do komunikacji SSL usług AD FS

    Jeśli powiązanie IP:port jest wymagane, rozpoznaj nazwę FQDN usługi ADFS na inny adres IP, który nie jest używany w żadnych powiązaniach. W ten sposób http.sys użyje powiązania Nazwa hosta:port na potrzeby komunikacji SSL.

  3. Ustaw pozycję AdfsTrustedDevices jako magazyn CTL dla powiązania IP:port

    Jest to ostatnia deska ratunku, jeśli nie możesz użyć powyższych metod. Jednak przed zmianą domyślnego magazynu CTL na AdfsTrustedDevices lepiej zrozumieć następujące warunki:

    • Dlaczego istnieje powiązanie IP:port.
    • Jeśli powiązanie opiera się na domyślnym magazynie CTL na potrzeby uwierzytelniania certyfikatu klienta.

Problem 2. Powiązanie certyfikatu usług AD FS nie ma nazwy magazynu CTL ustawionej na AdfsTrustedDevices

Jeśli Microsoft Entra connect jest zainstalowany, użyj Microsoft Entra Connect, aby ustawić nazwę magazynu CTL na AdfsTrustedDevices dla powiązań certyfikatów SSL na wszystkich serwerach usług AD FS. Jeśli program Microsoft Entra Connect nie jest zainstalowany, ponownie wygeneruj powiązania certyfikatów usług AD FS, uruchamiając następujące polecenie na wszystkich serwerach usług AD FS.

Set-AdfsSslCertificate -Thumbprint Thumbprint

Problem 3. Certyfikat, który nie jest podpisany samodzielnie, istnieje w magazynie certyfikatów AdfsTrustedDevices

Jeśli certyfikat wystawiony przez urząd certyfikacji znajduje się w magazynie certyfikatów, w którym zwykle istnieją tylko certyfikaty z podpisem własnym, czas wygaśnięcia wygenerowany z magazynu będzie zawierać tylko certyfikat wystawiony przez urząd certyfikacji. Magazyn certyfikatów AdfsTrustedDevices jest takim magazynem, który ma mieć tylko certyfikaty z podpisem własnym. Są to następujące certyfikaty:

  • MS-Organization-Access: certyfikat z podpisem własnym używany do wystawiania certyfikatów dołączania do miejsca pracy.
  • Zaufanie serwera proxy usług ADFS: certyfikaty dla każdego serwera serwer proxy aplikacji sieci Web.

Certyfikaty dla każdego serwera serwer proxy aplikacji sieci Web.

W związku z tym usuń certyfikat wystawiony przez urząd certyfikacji z magazynu certyfikatów AdfsTrustedDevices.

Problem 4. Instalowanie KB2964735 lub ponowne uruchamianie skryptu za pomocą polecenia -syncproxytrustcerts

Po ustanowieniu relacji zaufania serwera proxy z serwerem usług AD FS certyfikat klienta jest zapisywany w bazie danych konfiguracji usług AD FS i dodawany do magazynu certyfikatów AdfsTrustedDevices na serwerze usług AD FS. W przypadku wdrożenia farmy usług AD FS oczekuje się, że certyfikat klienta zostanie zsynchronizowany z innymi serwerami usług AD FS. Jeśli synchronizacja nie nastąpi z jakiegoś powodu, relacja zaufania serwera proxy będzie działać tylko z serwerem usług AD FS, z którym ustanowiono zaufanie, ale nie względem innych serwerów usług AD FS.

Aby rozwiązać ten problem, użyj jednej z następujących metod.

Metoda 1

Zainstaluj aktualizację udokumentowaną w bazie wiedzy 2964735 na wszystkich serwerach usług AD FS. Po zainstalowaniu aktualizacji oczekuje się, że synchronizacja certyfikatu klienta nastąpi automatycznie.

Metoda 2

Uruchom skrypt z przełącznikiem — syncproxytrustcerts, aby ręcznie zsynchronizować certyfikaty klienta z bazy danych konfiguracji usług AD FS z magazynem certyfikatów AdfsTrustedDevices. Skrypt powinien być uruchamiany na wszystkich serwerach usług AD FS w farmie.

Uwaga

Nie jest to trwałe rozwiązanie, ponieważ certyfikaty klienta będą regularnie odnawiane.

Problem 5. Wszystkie testy są przekazywane. Ale problem nadal występuje

Sprawdź, czy występuje niezgodność strefy czasowej lub czasowej. Jeśli czas jest zgodny, ale strefa czasowa nie, relacja zaufania serwera proxy również nie zostanie ustanowiona.

Sprawdź, czy między serwerem usług AD FS a serwerem WAP występuje kończenie protokołu SSL

Jeśli kończenie protokołu SSL odbywa się na urządzeniu sieciowym między serwerami usług AD FS i serwerem WAP, komunikacja między usługami AD FS i WAP zostanie przerwana, ponieważ komunikacja jest oparta na certyfikacie klienta.

Wyłącz zakończenie protokołu SSL na urządzeniu sieciowym między serwerami usług AD FS i WAP.

Korzystanie z aplikacji Token zrzutu

Aplikacja Dump Token jest przydatna podczas debugowania problemów z usługą federacyjną, a także sprawdzania poprawności niestandardowych reguł oświadczeń. Nie jest to oficjalne rozwiązanie, ale dobre niezależne rozwiązanie do debugowania, które jest zalecane do celów rozwiązywania problemów.

Przed użyciem aplikacji Token zrzutu

Przed użyciem aplikacji Dump Token należy wykonać następujące czynności:

  1. Pobierz informacje jednostki uzależnionej dla aplikacji, do którą chcesz uzyskać dostęp. Jeśli zostanie zaimplementowane uwierzytelnianie OAuth, uzyskaj również informacje o kliencie OAuth.
  2. Skonfiguruj aplikację Token zrzutu.

Uzyskiwanie informacji o kliencie jednostki uzależnionej i OAuth

Jeśli używasz konwencjonalnej jednostki uzależnionej, wykonaj następujące kroki:

  1. Na serwerze usług AD FS otwórz Windows PowerShell z opcją Uruchom jako administrator.

  2. Dodaj składnik usług AD FS 2.0 do Windows PowerShell, uruchamiając następujące polecenie:

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. Pobierz informacje jednostki uzależnionej, uruchamiając następujące polecenie:

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. Pobierz informacje o kliencie OAuth, uruchamiając następujące polecenie:

    $client = Get-AdfsClient ClientName
    

Jeśli używasz funkcji Grupy aplikacji w Windows Server 2016, wykonaj poniższe kroki:

  1. Na serwerze usług AD FS otwórz Windows PowerShell z opcją Uruchom jako administrator.

  2. Pobierz informacje jednostki uzależnionej, uruchamiając następujące polecenie:

    $rp = Get-AdfsWebApiApplication ResourceID
    
  3. Jeśli klient OAuth jest publiczny, pobierz informacje o kliencie, uruchamiając następujące polecenie:

    $client = Get-AdfsNativeClientApplication ClientName
    

    Jeśli klient OAuth jest poufny, pobierz informacje o kliencie, uruchamiając następujące polecenie:

    $client = Get-AdfsServerApplication ClientName
    

Konfigurowanie aplikacji tokenu zrzutu

Aby skonfigurować aplikację Token zrzutu, uruchom następujące polecenia w oknie Windows PowerShell:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Teraz kontynuuj korzystanie z następujących metod rozwiązywania problemów. Na końcu każdej metody sprawdź, czy problem został rozwiązany. Jeśli nie, użyj innej metody.

Metody rozwiązywania problemów

Sprawdź zasady autoryzacji, aby sprawdzić, czy ma to wpływ na użytkownika

W tej metodzie zaczniesz od uzyskania szczegółów zasad, a następnie użyjesz aplikacji Token zrzutu, aby zdiagnozować zasady, aby sprawdzić, czy ma to wpływ na użytkownika.

Pobieranie szczegółów zasad

$rp. IssuanceAuthorizationRules pokazuje reguły autoryzacji jednostki uzależnionej.

W Windows Server 2016 i nowszych wersjach można użyć $rp. AccessControlPolicyName do konfigurowania zasad uwierzytelniania i autoryzacji. Jeśli $rp. AccessControlPolicyName ma wartość. Obowiązują zasady kontroli dostępu, które regulują zasady autoryzacji. W takim przypadku $rp. IssuanceAuthorizationRules jest pusty. Użyj $rp. ResultantPolicy, aby dowiedzieć się szczegółów dotyczących zasad kontroli dostępu.

Jeśli $rp. ResultantPolicy nie zawiera szczegółów dotyczących zasad, przyjrzyj się rzeczywistym regułom oświadczeń. Aby uzyskać reguły oświadczeń, wykonaj następujące kroki:

  1. Ustaw zasady kontroli dostępu na $null, uruchamiając następujące polecenie:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
  2. Pobierz informacje jednostki uzależnionej, uruchamiając następujące polecenie:
    $rp = Get-AdfsRelyingPartyTrust RPName
  3. Sprawdź $rp.IssuanceAuthorizationRules i $rp. AdditionalAuthenticationRules.
Diagnozowanie zasad autoryzacji przy użyciu aplikacji Token zrzutu
  1. Ustaw zasady uwierzytelniania tokenu zrzutu tak, aby były takie same jak w przypadku awarii jednostki uzależnionej.

  2. Niech użytkownik otworzy jeden z następujących linków w zależności od ustawionych zasad uwierzytelniania.

    • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Wymuś uwierzytelnianie wieloskładnikowe: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. Zaloguj się na stronie Sign-In.

To, co otrzymujesz, to zestaw oświadczeń użytkownika. Sprawdź, czy w zasadach autoryzacji istnieje coś, co jawnie odmawia lub zezwala użytkownikowi na podstawie tych oświadczeń.

Sprawdź, czy brakujące lub nieoczekiwane oświadczenie powoduje odmowę dostępu do zasobu

  1. Skonfiguruj reguły oświadczeń w aplikacji Token zrzutu tak, aby były takie same jak reguły oświadczeń jednostki uzależnionej, która nie powiodła się.

  2. Skonfiguruj zasady uwierzytelniania tokenu zrzutu tak, aby były takie same jak w przypadku awarii jednostki uzależnionej.

  3. Niech użytkownik otworzy jeden z następujących linków w zależności od ustawionych zasad uwierzytelniania.

    • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Wymuś uwierzytelnianie wieloskładnikowe: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. Zaloguj się na stronie Sign-In.

Jest to zestaw oświadczeń, które jednostka uzależniająca będzie pobierać dla użytkownika. Jeśli brakuje jakichkolwiek oświadczeń lub są one nieoczekiwane, zapoznaj się z zasadami wystawiania, aby dowiedzieć się przyczyny.

Jeśli wszystkie oświadczenia są obecne, skontaktuj się z właścicielem aplikacji, aby sprawdzić, które oświadczenie jest brakujące lub nieoczekiwane.

Sprawdzanie, czy stan urządzenia jest wymagany

Jeśli reguły autoryzacji sprawdzają oświadczenia urządzeń, sprawdź, czy na liście oświadczeń pobranych z aplikacji Token zrzutu brakuje któregokolwiek z tych oświadczeń urządzenia. Brakujące oświadczenia mogą blokować uwierzytelnianie urządzenia. Aby uzyskać oświadczenia z aplikacji Token zrzutu, wykonaj kroki opisane w sekcji Używanie aplikacji tokenu zrzutu w celu zdiagnozowania zasad autoryzacji w zasadach sprawdzania autoryzacji, czy użytkownik miał wpływ na metodę .

Poniżej przedstawiono oświadczenia urządzenia. Reguły autoryzacji mogą używać niektórych z nich.

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
  • http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
  • http://schemas.microsoft.com/2014/02/deviceusagetime
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Jeśli brakuje oświadczenia, wykonaj kroki opisane w temacie Konfigurowanie lokalnego dostępu warunkowego przy użyciu zarejestrowanych urządzeń , aby upewnić się, że środowisko jest skonfigurowane na potrzeby uwierzytelniania urządzenia.

Jeśli wszystkie oświadczenia są obecne, sprawdź, czy wartości oświadczeń z aplikacji Token zrzutu są zgodne z wartościami wymaganymi w zasadach autoryzacji.