Diagnozowanie i rozwiązywanie problemów z AD FS w Microsoft Entra ID i Office 365

2025-04-09

W tym artykule omówiono rozwiązywanie problemów z uwierzytelnianiem dla użytkowników federacyjnych w usłudze Microsoft Entra ID lub Office 365.

Oryginalny numer KB: 3079872

Symptomy

Użytkownicy federacyjni nie mogą zalogować się do usługi Office 365 lub Microsoft Azure, mimo że użytkownicy korzystający tylko z chmury, którzy mają sufiks domainxx.onmicrosoft.com nazwy UPN, mogą się zalogować bez problemu.
Przekierowywanie do usług Active Directory Federation Services (AD FS) lub STS nie występuje dla użytkownika federacyjnego. Lub pojawi się błąd "Nie można wyświetlić strony".
Podczas próby uwierzytelnienia za pomocą usług AD FS w przeglądarce jest wyświetlane ostrzeżenie dotyczące certyfikatów. Oznacza to, że weryfikacja certyfikatu kończy się niepowodzeniem lub że certyfikat nie jest zaufany.
Błąd lub błędy "Nieznana metoda uwierzytelniania" z informacją, że AuthnContext nie jest obsługiwana. Ponadto błędy na poziomie usług AD FS lub STS podczas przekierowywania z usługi Office 365.
Usługi AD FS zgłasza błąd "Odmowa dostępu".
AD FS zgłasza błąd informujący o problemie z dostępem do witryny, w którym zawarty jest numer referencyjny.
Użytkownik jest wielokrotnie proszony o podanie poświadczeń na poziomie AD FS.
Użytkownicy federacyjni nie mogą uwierzytelniać się z sieci zewnętrznej lub gdy korzystają z aplikacji, która korzysta z trasy sieci zewnętrznej (na przykład Outlook).
Użytkownicy federacyjni nie mogą się zalogować po zmianie certyfikatu podpisywania tokenu w usługach AD FS.
Błąd "Niestety, ale mamy problem z zalogowaniem się" jest wyzwalany, gdy użytkownik federacyjny loguje się do usługi Office 365 na platformie Microsoft Azure. Ten błąd zawiera kody błędów, takie jak 8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06, 8004789A lub NIEPRAWIDŁOWE żądanie.

Rozwiązywanie problemów z przepływem pracy

Uzyskaj dostęp do witryny domowej Microsoft Office, a następnie wprowadź nazwę logowania użytkownika federacyjnego (ktoś@przykład.com). Po naciśnięciu Tab w celu usunięcia fokusu z pola logowania sprawdź, czy stan strony zmieni się na Przekierowanie , a następnie nastąpi przekierowanie do usługi federacyjnej Active Directory (AD FS) na potrzeby logowania.

Uwaga

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

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

Po wystąpieniu przekierowania zostanie wyświetlona następująca strona:
1. Jeśli nie nastąpi przekierowanie i zostanie wyświetlony monit o wprowadzenie hasła na tej samej stronie, oznacza to, że Microsoft Entra ID lub usługa Office 365 nie rozpoznaje użytkownika ani domeny użytkownika do federacji. Aby sprawdzić, czy istnieje relacja zaufania federacyjnego między Microsoft Entra ID lub Office 365 a serwerem AD FS, uruchom polecenie Get-MgDomain cmdlet i sprawdź AuthenticationType.
2. Jeśli nastąpi przekierowanie, ale nie nastąpi przekierowanie do serwera usług AD FS na potrzeby logowania, sprawdź, czy nazwa usługi AD FS jest rozpoznawana jako prawidłowy adres IP i czy może nawiązać połączenie z tym adresem IP na porcie TCP 443.
  
  Jeśli domena jest wyświetlana jako federacyjna, uzyskaj informacje o relacji zaufania federacji, uruchamiając następujące polecenia:
```
Get-MgDomainFederationConfiguration -DomainId <domain_id>
```
  Uwaga 16.
  
  < > domain_id jest symbolem zastępczym nazwy domeny. Na przykład contoso.com.
  
  Sprawdź identyfikator URI, adres URL i certyfikat partnera federacyjnego skonfigurowanego przez usługę Office 365 lub Identyfikator entra firmy Microsoft.
Po przekierowaniu do usług AD FS przeglądarka może zgłosić błąd związany z zaufaniem certyfikatu, a dla niektórych klientów i urządzeń może nie umożliwić ustanowienia sesji SSL (Secure Sockets Layer) z usługami AD FS. Aby rozwiązać ten problem, wykonaj poniższe czynności:
1. Upewnij się, że certyfikat komunikacji usług AD FS przedstawiony klientowi jest taki sam, który jest skonfigurowany w usługach AD FS.
  
  W idealnym przypadku certyfikat komunikacji usług AD FS powinien być taki sam jak certyfikat SSL przedstawiony klientowi podczas próby ustanowienia tunelu SSL z usługą AD FS.
  
  W usługach AD FS 2.0:
  - Powiąż certyfikat z pierwszą domyślną witryną usług IIS>.
  - Użyj przystawki AD FS, aby dodać ten sam certyfikat jako certyfikat komunikacji usługowej.
  W AD FS 2012 R2:
  - Użyj przystawki AD FS lub Add-adfscertificate polecenia, aby dodać certyfikat komunikacji usługi.
  - Użyj polecenia , Set-adfssslcertificate aby ustawić ten sam certyfikat dla powiązania SSL.
2. Upewnij się, że certyfikat komunikacji usług AD FS jest zaufany przez klienta.
3. Jeśli klienci bez obsługi SNI próbują ustanowić sesję SSL z usługami AD FS lub WAP 2-12 R2, próba może zakończyć się niepowodzeniem. W takim przypadku rozważ dodanie wpisu rezerwowego na serwerach AD FS lub WAP, aby obsługiwać klientów nieobsługujących SNI. Aby uzyskać więcej informacji, zobacz Jak obsługiwać klientów, którzy nie obsługują SNI, za pomocą serwera proxy aplikacji sieci Web i AD FS 2012 R2.

Może wystąpić błąd "Nieznana metoda uwierzytelniania" lub błędy informujące, że AuthnContext nie jest obsługiwany na poziomie usług AD FS lub STS podczas przekierowywania z usługi Office 365. Najczęściej występuje przekierowanie do usług AD FS lub STS przy użyciu parametru, który wymusza metodę uwierzytelniania. Aby wymusić metodę uwierzytelniania, użyj jednej z następujących metod:

W przypadku usługi WS-Federation użyj ciągu zapytania WAUTH, aby wymusić preferowaną metodę uwierzytelniania.

W przypadku protokołu SAML2.0 użyj następującego polecenia:

<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

Po wysłaniu wymuszonej metody uwierzytelniania z nieprawidłową wartością lub jeśli ta metoda uwierzytelniania nie jest obsługiwana w usługach AD FS lub STS, przed uwierzytelnieniem zostanie wyświetlony komunikat o błędzie.

W poniższej tabeli przedstawiono URI typu uwierzytelniania rozpoznawane przez AD FS dla pasywnego uwierzytelniania WS-Federation.

Metoda uwierzytelniania, która jest poszukiwana	wauth URI
Uwierzytelnianie przy użyciu nazwy użytkownika i hasła	urn:oasis:names:tc:SAML:1.0:am:password
Uwierzytelnianie klienta SSL	urn:ietf:rfc:2246
Uwierzytelnianie zintegrowane z systemem Windows	urn:federation:authentication:windows

Obsługiwane klasy kontekstowe uwierzytelniania SAML

Metoda uwierzytelniania	Identyfikator URI klasy kontekstu uwierzytelniania
Nazwa użytkownika i hasło	urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Transport chroniony hasłem	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Klient protokołu Transport Layer Security (TLS)	urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
Certyfikat X.509	urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Zintegrowane uwierzytelnianie systemu Windows	urn:federation:authentication:windows
Kerberos	urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

Aby upewnić się, że metoda uwierzytelniania jest obsługiwana na poziomie usług AD FS, sprawdź następujące kwestie.

AD FS 2.0

W obszarze /adfs/ls/web.config upewnij się, że wpis dla typu uwierzytelniania jest obecny.

<microsoft.identityServer.web>
<localAuthenticationTypes>
 < add name="Forms" page="FormsSignIn.aspx" />  
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2.0: Jak zmienić typ uwierzytelniania lokalnego

AD FS 2012 R2

W obszarze Zarządzanie usługami AD FS wybierz pozycję Zasady uwierzytelniania w przystawce usług AD FS.
W sekcji Uwierzytelnianie podstawowe wybierz pozycję Edytuj obok pozycji Ustawienia globalne. Możesz również kliknąć prawym przyciskiem myszy pozycję Zasady uwierzytelniania, a następnie wybrać polecenie Edytuj globalne uwierzytelnianie podstawowe. W okienku Akcje wybierz pozycję Edytuj globalne uwierzytelnianie podstawowe.
W oknie Edytowanie globalnych zasad uwierzytelniania na karcie Podstawowe można skonfigurować ustawienia w ramach globalnych zasad uwierzytelniania. Na przykład w przypadku uwierzytelniania podstawowego można wybrać dostępne metody uwierzytelniania w obszarze Ekstranet i Intranet.

Upewnij się, że zaznaczono pole wyboru wymagana metoda uwierzytelniania.

Jeśli uzyskujesz dostęp do swojego AD FS i wprowadzasz poświadczenia, ale nie możesz się uwierzytelnić, zwróć uwagę na następujące kwestie.
1. Problem z replikacją usługi Active Directory
  
  Jeśli replikacja usługi AD zostanie przerwana, zmiany wprowadzone w użytkowniku lub grupie mogą nie zostać zsynchronizowane między kontrolerami domeny. Między kontrolerami domeny może występować niezgodność hasła, nazwy UPN, członkostwa w grupie lub adresu proxy, która wpływa na odpowiedź usług AD FS (uwierzytelnianie i oświadczenia). Należy zacząć analizować kontrolery domeny w tym samym miejscu co AD FS. Uruchomienie polecenia repadmin /showreps lub DCdiag /v powinno ujawnić, czy istnieje problem na kontrolerach domeny, które najprawdopodobniej będą nawiązywać kontakt z AD FS.
  
  Możesz również zebrać podsumowanie replikacji usługi AD, aby upewnić się, że zmiany usługi AD są replikowane poprawnie na wszystkich kontrolerach domeny. Dane repadmin /showrepl * /csv > showrepl.csv wyjściowe są przydatne do sprawdzania stanu replikacji. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z replikacją usługi Active Directory.
2. Konto jest zablokowane lub wyłączone w usłudze Active Directory
  
  Gdy użytkownik końcowy jest uwierzytelniany za pośrednictwem usług AD FS, nie otrzyma komunikatu o błędzie informującego, że konto jest zablokowane lub wyłączone. Z usług AD FS i inspekcji logowania powinno być możliwe ustalenie, czy uwierzytelnianie nie powiodło się z powodu nieprawidłowego hasła, czy konto jest wyłączone, czy zablokowane itd.
  
  Aby włączyć inspekcję AD FS oraz audyt logowania na serwerach usług AD FS, wykonaj następujące kroki:
  1. Użyj zasad lokalnych lub zasad domeny, aby włączyć sukcesy i niepowodzenia dla następujących zasad:
    - Zarejestruj zdarzenie logowania znajdujące się w Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
    - Inspekcja dostępu do obiektów, które znajdują się w lokalizacji Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
  2. Wyłącz następujące zasady:
    
    Audyt: wymuś ustawienia podkategorii zasad audytu (system Windows Vista lub nowszy), aby zastąpić ustawienia kategorii zasad audytu
    
    Ta polityka znajduje się w lokalizacji Computer configuration\Windows Settings\Security setting\Local Policy\Security Option.
    
    Jeśli chcesz ją skonfigurować przy użyciu zaawansowanej inspekcji, zobacz Konfigurowanie komputerów na potrzeby rozwiązywania problemów z usługami AD FS 2.0.
  3. Konfigurowanie usług AD FS na potrzeby inspekcji:
    1. Otwórz przystawkę Zarządzanie usługami AD FS 2.0.
    2. W okienku Akcje wybierz pozycję Edytuj właściwości usługi federacyjnej.
    3. W oknie dialogowym Właściwości usługi federacyjnej wybierz kartę Zdarzenia.
    4. Zaznacz pola wyboru Inspekcje zakończone sukcesem i Inspekcje zakończone niepowodzeniem.
    5. Uruchom GPupdate /force na serwerze.
3. Główna nazwa usługi (SPN) jest niepoprawnie zarejestrowana
  
  Mogą istnieć zduplikowane SPN lub SPN zarejestrowane na koncie innym niż konto usługi AD FS. W przypadku konfiguracji farmy AD FS upewnij się, że SPN HOST/AD FSservicename jest dodana do konta usługi, które uruchamia usługę AD FS. W przypadku autonomicznej konfiguracji usług AD FS, w której usługa jest uruchomiona w ramach Network Service, nazwa SPN musi znajdować się na koncie serwerowego komputera hostującego usługi AD FS.
  
  Upewnij się, że nie ma zduplikowanych nazw SPN dla usługi AD FS, ponieważ może to spowodować sporadyczne błędy uwierzytelniania z usługami AD FS. Aby wyświetlić listę SPN, uruchom SETSPN -L <ServiceAccount>.
  
  Uruchom polecenie SETSPN -A HOST/AD FSservicename ServiceAccount , aby dodać nazwę SPN.
  
  Uruchom SETSPN -X -F, aby sprawdzić zduplikowane SPN.
4. Duplikowanie nazw UPN w usłudze Active Directory
  
  Użytkownik może być w stanie uwierzytelnić się za pośrednictwem usług AD FS, gdy używa nazwy SAMAccountName, ale nie może uwierzytelnić się podczas korzystania z nazwy UPN. W tym scenariuszu usługa Active Directory może zawierać dwóch użytkowników, którzy mają tę samą nazwę UPN. W przypadku dodawania i modyfikowania za pomocą skryptów (NA przykład ADSIedit) można utworzyć dwie osoby, które mają tę samą nazwę UPN.
  
  Gdy nazwa UPN jest używana do uwierzytelniania w tym scenariuszu, użytkownik jest uwierzytelniany względem zduplikowanego użytkownika. Dlatego podane poświadczenia nie są weryfikowane.
  
  Możesz użyć zapytań, takich jak poniżej, aby sprawdzić, czy w usłudze AD istnieje wiele obiektów, które mają te same wartości dla atrybutu:
```
Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN
```
  Upewnij się, że nazwa UPN w zduplikowanym użytkowniku została zmieniona, aby żądanie uwierzytelniania przy użyciu nazwy UPN zostało zweryfikowane pod kątem poprawnych obiektów.
5. W scenariuszu, w którym używasz adresu e-mail jako identyfikatora logowania w usłudze Office 365 i wprowadzasz ten sam adres e-mail po przekierowaniu do usług AD FS na potrzeby uwierzytelniania, uwierzytelnianie może zakończyć się niepowodzeniem z powodu błędu "NO_SUCH_USER" w dziennikach inspekcji. Aby umożliwić usługom AD FS znalezienie użytkownika do uwierzytelniania przy użyciu atrybutu innego niż UPN lub SAMaccountname, należy skonfigurować usługi AD FS do wsparcia alternatywnego identyfikatora logowania. Aby uzyskać więcej informacji, zobacz Konfigurowanie alternatywnego identyfikatora logowania.
  
  Na AD FS 2012 R2
  1. Zainstaluj aktualizację 2919355.
  2. Zaktualizuj konfigurację usług AD FS, uruchamiając następujące polecenie cmdlet programu PowerShell na dowolnym z serwerów federacyjnych w farmie (jeśli masz farmę WID, musisz uruchomić to polecenie na serwerze podstawowym usług AD FS w farmie):
```
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
```
    Uwaga
    
    AlternateLoginID jest nazwą atrybutu LDAP, którego chcesz używać do logowania. LookupForests to lista wpisów DNS lasów, do których należą użytkownicy.
    
    Aby włączyć funkcję alternatywnego identyfikatora logowania, należy skonfigurować parametry AlternateLoginID i LookupForests z niepustą i prawidłową wartością.
6. Konto usługi AD FS nie ma dostępu do odczytu w tokenie usług AD FS, który podpisuje klucz prywatny certyfikatu. Aby dodać to uprawnienie, wykonaj następujące kroki:
  1. Po dodaniu nowego certyfikatu podpisywania tokenu zostanie wyświetlone następujące ostrzeżenie:
    
    Upewnij się, że klucz prywatny wybranego certyfikatu jest dostępny dla konta usługi dla tej usługi federacyjnej na każdym serwerze w farmie.
  2. Wybierz pozycję Start, wybierz pozycję Uruchom, wpisz mmc.exe, a następnie naciśnij Enter.
  3. Wybierz pozycję Plik, a następnie wybierz pozycję Dodaj/Usuń przystawkę.
  4. Kliknij dwukrotnie pozycję Certyfikaty.
  5. Wybierz konto komputera, a następnie wybierz pozycję Dalej.
  6. Wybierz Komputer lokalny i Zakończ.
  7. Rozwiń węzeł Certyfikaty (komputer lokalny), rozwiń węzeł Persona l, a następnie wybierz pozycję Certyfikaty.
  8. Kliknij prawym przyciskiem myszy nowy certyfikat podpisywania tokenu, wybierz pozycję Wszystkie zadania, a następnie wybierz pozycję Zarządzaj kluczami prywatnymi.
  9. Dodaj dostęp do odczytu dla konta usługi AD FS 2.0, a następnie wybierz przycisk OK.
  10. Zamknij konsolę MMC do zarządzania certyfikatami.
7. Opcja Rozszerzonej Ochrony dla uwierzytelniania Windows jest włączona dla wirtualnego katalogu AD FS lub LS. Może to powodować problemy z określonymi przeglądarkami. Czasami może się zdarzyć, że usługi AD FS wielokrotnie monitują o poświadczenia. Może to być związane z ustawieniem rozszerzonej ochrony, które jest włączone dla uwierzytelniania Windows w usługach AD FS lub aplikacji LS w usługach IIS.
  
  Po włączeniu rozszerzonej ochrony na potrzeby uwierzytelniania żądania uwierzytelniania są powiązane zarówno z głównymi nazwami usługi (SPN) serwera, z którym klient próbuje nawiązać połączenie i z zewnętrznym kanałem tls (Transport Layer Security), za pośrednictwem którego odbywa się zintegrowane uwierzytelnianie systemu Windows. Rozszerzona ochrona rozszerza istniejącą funkcję uwierzytelniania systemu Windows, aby ograniczyć możliwości przekazywania uwierzytelniania lub ataków typu "człowiek w środku". Jednak niektóre przeglądarki nie działają z ustawieniem Rozszerzonej ochrony; zamiast tego wielokrotnie monitują o poświadczenia, a następnie odmawiają dostępu. Wyłączenie rozszerzonej ochrony pomaga w tym scenariuszu.
  
  Aby uzyskać więcej informacji, zobacz AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger (Ciągłe monitowanie o poświadczenia podczas korzystania z debugera internetowego programu Fiddler).
  
  W przypadku usług AD FS 2012 R2
  
  Uruchom następujące polecenie cmdlet, aby wyłączyć ochronę rozszerzoną:
```
Set-ADFSProperties -ExtendedProtectionTokenCheck None
```
8. Reguły autoryzacji wystawiania w zaufaniu odwołującego się podmiotu (RP) mogą odmawiać dostępu użytkownikom. Na zaufaniu do aplikacji korzystającej w usługach AD FS można skonfigurować reguły autoryzacji wystawiania, które kontrolują, czy uwierzytelnionemu użytkownikowi powinien zostać przyznany token dla aplikacji korzystającej. Administratorzy mogą korzystać z wystawionych roszczeń, aby zdecydować o odmowie dostępu użytkownikowi, który jest członkiem grupy traktowanej jako roszczenie.
  
  Jeśli niektórzy użytkownicy federacyjni nie mogą uwierzytelniać się za pośrednictwem usług AD FS, warto sprawdzić reguły autoryzacji wystawiania dla usługi Office 365 RP oraz sprawdzić, czy jest skonfigurowana reguła Zezwól na dostęp do wszystkich użytkowników.
  
  Jeśli ta reguła nie jest skonfigurowana, zapoznaj się z niestandardowymi regułami autoryzacji, aby sprawdzić, czy warunek w tej regule ocenia wartość "true" dla użytkownika, którego dotyczy problem. Aby uzyskać więcej informacji, zobacz następujące zasoby:
  Jeśli możesz uwierzytelnić się z intranetu podczas uzyskiwania dostępu do serwera usług AD FS bezpośrednio, ale nie można uwierzytelnić się podczas uzyskiwania dostępu do usług AD FS za pośrednictwem serwera proxy usług AD FS, sprawdź następujące problemy:
  - Problem z synchronizacją czasu na serwerze usług AD FS i serwerze proxy usług AD FS
    
    Upewnij się, że czas na serwerze usług AD FS i czas na serwerze proxy są zsynchronizowane. Gdy czas na serwerze usług AD FS jest wyłączony przez więcej niż pięć minut od czasu na kontrolerach domeny, występują błędy uwierzytelniania. Gdy czas na serwerze proxy AD FS nie jest synchronizowany z AD FS, relacja zaufania serwera proxy jest naruszona i przerywana. Dlatego żądanie przekazywane przez serwer proxy usług AD FS kończy się niepowodzeniem.
  - Sprawdź, czy zaufanie serwera proxy AD FS z usługą AD FS działa poprawnie. Uruchom ponownie konfigurację serwera proxy, jeśli podejrzewasz, że relacja zaufania serwera proxy jest uszkodzona.
Po wydaniu tokenu przez AD FS, Microsoft Entra ID lub Office 365 zgłasza błąd. W takiej sytuacji sprawdź, czy występują następujące problemy:
- Oświadczenia wystawiane przez usługi AD FS w tokenie powinny być zgodne z odpowiednimi atrybutami użytkownika w microsoft Entra ID. W tokenie dla identyfikatora Entra firmy Microsoft lub usługi Office 365 wymagane są następujące oświadczenia.
  
  WSFED:
  UPN: Wartość tego roszczenia powinna być zgodna z UPN użytkowników w Microsoft Entra ID.
  ImmutableID: Wartość tego oświadczenia powinna być zgodna z sourceAnchor lub ImmutableID użytkownika w Microsoft Entra ID.
  
  Aby uzyskać wartość atrybutu użytkownika w Microsoft Entra ID, uruchom następujące polecenie:
```
Get-MgUser -UserId <user_id_string>
```
  SAML 2.0:
  IDPEmail: wartość tego oświadczenia powinna być zgodna z główną nazwą użytkownika w identyfikatorze Entra firmy Microsoft.
  NAMEID: wartość tego oświadczenia powinna być zgodna z wartością sourceAnchor lub ImmutableID użytkownika w identyfikatorze Entra firmy Microsoft.
  
  Aby uzyskać więcej informacji, zobacz Use a SAML 2.0 Identity Provider (IdP) for Single Sign On (Używanie dostawcy tożsamości SAML 2.0 na potrzeby logowania jednokrotnego).
  
  Przykłady:
  Ten problem może wystąpić, gdy nazwa UPN zsynchronizowanego użytkownika zostanie zmieniona w Active Directory, ale bez aktualizowania katalogu online. W tym scenariuszu można poprawić nazwę UPN użytkownika w usłudze AD (aby dopasować nazwę logowania powiązanego użytkownika) lub uruchomić następujące polecenie cmdlet, aby zmienić nazwę logowania powiązanego użytkownika w katalogu online:
```
Update-MgUser -UserId <user_id_string> -UserPrincipalName <DomainUPN-AD>
```
  Może się zdarzyć, że używasz narzędzia AADsync do synchronizacji MAIL jako UPN i EMPID jako SourceAnchor, ale reguły roszczeń strony polegającej na poziomie AD FS nie zostały zaktualizowane, aby wysyłać MAIL jako UPN i EMPID jako ImmutableID.
- Istnieje niezgodność certyfikatu podpisywania tokenu między usługami AD FS i Office 365.
  
  Jest to jeden z najczęstszych problemów. Usługi AD FS używają certyfikatu podpisywania tokenu do podpisywania tokenu wysyłanego do użytkownika lub aplikacji. Zaufanie między usługami AD FS i Office 365 jest federacyjnym zaufaniem opartym na tym certyfikacie podpisywania tokenu (na przykład usługa Office 365 sprawdza, czy otrzymany token jest podpisany przy użyciu certyfikatu podpisywania tokenu dostawcy oświadczeń [usługi AD FS], któremu ufa).
  
  Jeśli jednak certyfikat podpisywania tokenu w usługach AD FS zostanie zmieniony z powodu automatycznego przerzucania certyfikatu lub przez interwencję administratora (po wygaśnięciu certyfikatu lub przed jego wygaśnięciem), szczegóły nowego certyfikatu muszą zostać zaktualizowane w dzierżawie usługi Office 365 dla domeny federacyjnej. Nie musi się to zdarzyć automatycznie; może wymagać interwencji administratora. Gdy podstawowy certyfikat podpisywania tokenów w usłudze AD FS różni się od tego, o którym wie Office 365, token wystawiony przez usługę AD FS nie jest uznawany za zaufany przez Office 365. W związku z tym użytkownik federacyjny nie może się zalogować.
  
  Usługa Office 365 lub Microsoft Entra ID spróbuje skontaktować się z usługą AD FS, zakładając, że usługa jest osiągalna za pośrednictwem sieci publicznej. Staramy się sondować metadane federacji usług AD FS w regularnych odstępach czasu, aby ściągnąć wszelkie zmiany konfiguracji w usługach AD FS, głównie informacje o certyfikacie podpisywania tokenu. Jeśli ten proces nie działa, administrator globalny powinien otrzymać ostrzeżenie w portalu usługi Office 365 o wygaśnięciu certyfikatu podpisywania tokenu oraz o akcjach wymaganych do jego zaktualizowania.
  
  Można użyć Get-MgDomainFederationConfiguration -DomainId <domain_id> do zrzutu właściwości federacyjnej w usługach AD FS i Office 365. W tym miejscu możesz porównać odcisk palca TokenSigningCertificate, aby sprawdzić, czy konfiguracja dzierżawy usługi Office 365 dla domeny federacyjnej jest zsynchronizowana z usługami AD FS. Jeśli znajdziesz niezgodność w konfiguracji certyfikatu podpisywania tokenu, uruchom następujące polecenie, aby go zaktualizować:
```
Connect-MgGraph -scopes Domain.ReadWrite.All, Directory.ReadWrite.All
$tdo= Get-MgDomainFederationConfiguration -DomainID <domain_id>
Update-MgDomainFederationConfiguration -DomainId <domain_id> -InternalDomainFederationId $tdo.Id -SigningCertificate <certificate_token>
Disconnect-MgGraph
```
  Uwaga
  
  < > domain_id jest symbolem zastępczym nazwy domeny. Na przykład contoso.com.
  
  Aby uzyskać więcej informacji, zobacz Odnawianie certyfikatów federacyjnych dla platformy Microsoft 365 i identyfikatora Entra firmy Microsoft.
- Reguły przekształcania wystawiania oświadczeń dla dostawcy usługi Office 365 nie są poprawnie skonfigurowane.
  
  W scenariuszu, w którym masz wiele domen TLD (domen najwyższego poziomu), mogą wystąpić problemy z logowaniem, jeśli przełącznik Supportmultipledomain nie był używany podczas tworzenia i aktualizowania zaufania dostawcy zasobów.
  
  Zalecamy używanie programu Entra Connect do zarządzania federacjami i regułami oświadczeń. Zwykle proces ten automatycznie konfigurował usługi ADFS i Entra w odpowiedni sposób. Aby uzyskać więcej informacji, zobacz Multiple Domain Support for Federating with Microsoft Entra ID (Obsługa wielu domen na potrzeby federacji przy użyciu identyfikatora Entra firmy Microsoft).
- Upewnij się, że szyfrowanie tokenu nie jest używane przez usługi AD FS lub STS, gdy token jest wystawiony dla identyfikatora Entra firmy Microsoft lub usługi Office 365.
W Menedżerze poświadczeń systemu Windows znajdują się przestarzałe przechowywane dane uwierzytelniające.

Czasami podczas logowania z stacji roboczej do portalu (lub w przypadku korzystania z programu Outlook), gdy użytkownik jest monitowany o poświadczenia, poświadczenia mogą być zapisywane dla miejsca docelowego (usługi Office 365 lub AD FS) w Menedżerze poświadczeń systemu Windows (Control Panel\User Accounts\Credential Manager). Pomaga to zapobiec monitowaniu o poświadczenia przez jakiś czas, ale może to spowodować problem po zmianie hasła użytkownika, a menedżer poświadczeń nie zostanie zaktualizowany. W tym scenariuszu nieaktualne poświadczenia są wysyłane do usługi AD FS i dlatego uwierzytelnianie kończy się niepowodzeniem. Usunięcie lub zaktualizowanie buforowanych poświadczeń w Menedżerze poświadczeń systemu Windows może pomóc.
Upewnij się, że algorytm SHA skonfigurowany w ufności zależnej dla usługi Office 365 jest ustawiony na SHA1.

Gdy zaufanie między usługami STS / AD FS a Microsoft Entra ID / Office 365 jest realizowane z użyciem protokołu SAML 2.0, algorytm bezpiecznego haszowania skonfigurowany dla podpisu cyfrowego powinien być ustawiony na SHA1.
Jeśli żadna z powyższych przyczyn nie ma zastosowania do Twojej sytuacji, utwórz zgłoszenie do wsparcia technicznego firmy Microsoft i poproś o sprawdzenie, czy konto użytkownika jest spójnie wyświetlane w dzierżawie usługi Office 365. Aby uzyskać więcej informacji, zobacz Użytkownik federacyjny jest wielokrotnie monitowany o poświadczenia podczas logowania się do usługi Office 365, platformy Azure lub usługi Intune.

W zależności od tego, do której usługi w chmurze (zintegrowanej z identyfikatorem Entra firmy Microsoft) uzyskujesz dostęp, żądanie uwierzytelniania wysyłane do usług AD FS może się różnić. Na przykład: niektóre żądania mogą zawierać dodatkowe parametry, takie jak Wauth lub Wfresh, a te parametry mogą powodować różne zachowanie na poziomie usług AD FS.

Zalecamy, aby pliki binarne usług AD FS były zawsze aktualizowane w celu uwzględnienia poprawek znanych problemów. Aby uzyskać więcej informacji na temat najnowszych aktualizacji, zobacz poniższą tabelę.

AD FS 2.0	AD FS 2012 R2
Opis pakietu zbiorczego aktualizacji 3 dla usług Active Directory Federation Services (AD FS) 2.0 Aktualizacja jest dostępna, aby rozwiązać kilka problemów po zainstalowaniu aktualizacji zabezpieczeń 2843638 na serwerze usług AD FS	Pakiet zbiorczy aktualizacji z grudnia 2014 r. dla systemów Windows RT 8.1, Windows 8.1 i Windows Server 2012 R2

Źródło

Aby uzyskać więcej informacji na temat poleceń cmdlet programu Microsoft Graph, zobacz następujące artykuły:

Udostępnij za pośrednictwem

Diagnozowanie i rozwiązywanie problemów z AD FS w Microsoft Entra ID i Office 365

Symptomy

Rozwiązywanie problemów z przepływem pracy

Źródło

Opinia

Dodatkowe zasoby