Otwórz aplikację Zarządzanie programem AD FS na serwerze. W folderze AD FS > Usługa > Punkty końcowe wybierz opcję Metadane federacji.
Ostatnia aktualizacja
16 gru 2024
Instrukcje rozwiązywania typowych problemów z uwierzytelnianiem i logowaniem SSO na podstawie identyfikatorów Federated ID (logowaniem SSO) oraz weryfikowania powiązanej konfiguracji w produktach Adobe. Porady pozwalające usunąć błędy SAML, błędy certyfikatów oraz inne problemy z uwierzytelnianiem.
Po pomyślnym skonfigurowaniu SSO w Adobe Admin Console, wybierz Pobierz plik metadanych Adobe i zapisz plik metadanych SAML XML na komputerze. Plik ten trzeba przekazać do usługi IdP używanej przez przedsiębiorstwo, aby umożliwić włączenie logowania SSO. Te dane konfiguracyjne XML należy prawidłowo zaimportować do usługi IdP. Jest to wymagane do integracji SAML z dostawcą tożsamości i zapewnia prawidłowe skonfigurowanie danych.
Jeśli masz pytania dotyczące używania pliku metadanych SAML XML do konfiguracji dostawcy tożsamości, skontaktuj się bezpośrednio z dostawcą tożsamości w celu uzyskania instrukcji, ponieważ różnią się one w zależności od dostawcy.
Spostrzeżenie
Jeżeli w organizacji skonfigurowano logowanie jednokrotne (SSO) z użyciem usługi Google Federation lub Microsoft Azure Sync, zapoznaj się z następującymi artykułami:
Podstawowa procedura rozwiązywania problemów
Problemy z logowaniem SSO wynikają często z podstawowych błędów, które łatwo przeoczyć. Sprawdź zwłaszcza następujące kwestie:
- Użytkownik musi być przypisany do profilu produktowego z odpowiednim uprawnieniem.
- Nazwa użytkownika wysłana do SAML jest zgodna z nazwą użytkownika w panelu przedsiębiorstwa.
- Sprawdź wszystkie wpisy w serwisie Admin Console i usłudze IdP pod kątem błędów pisowni lub składni.
- Program Creative Cloud Desktop musi być uaktualniony do najnowszej wersji.
- Użytkownik musi logować się w odpowiednim miejscu (program Creative Cloud Desktop, aplikacja Creative Cloud lub serwis Adobe.com)
Rozwiązania innych często występujących błędów
Błąd o treści: „Wystąpił błąd” z przyciskiem „Spróbuj ponownie”
Ten błąd zwykle występuje po pomyślnym uwierzytelnieniu użytkownika, gdy Okta przesłała odpowiedź uwierzytelniającą do Adobe.
Sprawdź następujące elementy w serwisie Adobe Admin Console:
Na karcie Tożsamość:
- Sprawdź, czy aktywowano odpowiednią domenę.
Na karcie Produkty:
- Sprawdź, czy użytkownik jest powiązany z poprawnym pseudonimem produktu i znajduje się w domenie, którą przypisano na potrzeby konfiguracji identyfikatorów Federated ID.
- Sprawdź, czy do pseudonimu produktu przypisano prawidłowe uprawnienia.
Na karcie Użytkownicy:
- Sprawdź, czy nazwa użytkownika ma postać pełnego adresu e-mail.
Błąd: „Odmowa dostępu” podczas logowania
Możliwe przyczyny tego błędu:
- Nazwa użytkownika lub adres e-mail w asercji SAML nie jest zgodna z informacjami wprowadzonymi w Admin Console.
- Użytkownik nie został powiązany z odpowiednim produktem lub produkt nie został powiązany z prawidłowym uprawnieniem.
- Nazwa użytkownika w kodzie SAML nie jest adresem e-mail. Wszyscy użytkownicy muszą należeć do domeny, którą przypisano w ramach procesu konfiguracji.
- Klient logowania SSO używa języka JavaScript w ramach procesu logowania, a użytkownik próbuje zalogować się do klienta, który nie obsługuje tego języka.
Jak rozwiązać ten problem:
- Sprawdź nazwę użytkownika i adres e-mail w Adobe Admin Console i dopasuj je do atrybutów NameID i Email w dziennikach SAML.
- Sprawdź konfigurację użytkownika w konsoli: dane użytkownika i profil produktowy.
- Uruchom śledzenie SAML i sprawdź, czy wysyłane informacje są zgodne z informacjami w konsoli, a następnie popraw wszelkie niespójności.
Błąd „Obecnie jest zalogowany inny użytkownik”
Taki błąd występuje wtedy, gdy atrybuty wysłane w asercji SAML nie są zgodne z adresem e-mail użytym do rozpoczęcia procesu logowania.
Wykonaj operację SAML Trace i zweryfikuj, czy adres e-mail użytkownika używany do logowania jest zgodny z:
- adresem e-mail użytkownika podanym w serwisie Admin Console;
- nazwą konta użytkownika zwracaną w polu NameID asercji SAML.
Błąd „Wystawca w odpowiedzi SAML nie jest zgodny z wystawcą skonfigurowanym w usłudze IdP”
Wystawca IdP w asercji SAML różni się od wystawcy skonfigurowanego w przychodzącym komunikacie SAML. Przejrzyj dane w poszukiwaniu literówek (takich jak http/https). Porównując łańcuch wystawcy IdP z systemem SAML klienta, trzeba znaleźć dane IDENTYCZNE z podanymi przez tego klienta informacjami. Czasami problem ten występuje, ponieważ na końcu łańcucha brakuje ukośnika.
Jeśli potrzebna jest pomoc w związku z tym błędem, prześlij dane ze śledzenia SAML oraz wartości wprowadzone w konsoli Adobe.
Błąd „Podpis cyfrowy w odpowiedzi SAML nie został zweryfikowany za pomocą certyfikatu usługi IdP”
Ten problem występuje, gdy certyfikat katalogu wygasł. Aby go zaktualizować, należy pobrać ten certyfikat lub metadane z usługi IdP i przesłać je do serwisu Adobe Admin Console.
Przykład: Jeśli używasz rozwiązania Microsoft AD FS jako usługi IdP, wykonaj następujące czynności:
Użyj przeglądarki, aby przejść do adresu URL podanego w metadanych federacji i pobrać plik. Na przykład: https://<nazwa używanego hosta AD FS>/FederationMetadata/2007-06/FederationMetadata.xml.
Spostrzeżenie
Jeśli zostaną wyświetlone ostrzeżenia, zaakceptuj je.
Na karcie Ustawienia w serwisie Admin Console wybierz opcje Ustawienia identyfikatorów > Katalogi. Wybierz katalog, który chcesz uaktualnić, i kliknij opcję Konfiguruj na karcie Dostawca SAML.
Następnie prześlij plik metadanych usługi IdP i kliknij przycisk Zapisz.
Błąd „Bieżąca godzina jest wcześniejsza niż przedział czasu określony w warunkach asercji”
Serwer IdP oparty na systemie Windows:
- Upewnij się, że zegar systemowy jest zsynchronizowany z dokładnym serwerem czasu.
Sprawdź dokładność zegara systemowego względem serwera czasu za pomocą tego polecenia; wartość „Phase Offset" powinna wynosić niewielki ułamek sekundy:
w32tm /query /status /verbose
Można spowodować natychmiastową resynchronizację zegara systemowego z serwerem czasu za pomocą następującego polecenia:
w32tm /resync
Jeśli zegar systemowy jest ustawiony prawidłowo, a nadal widzisz powyższy błąd, może być konieczne dostosowanie ustawienia przesunięcia czasowego w celu zwiększenia tolerancji różnic zegara między serwerem a klientem. - Zwiększ dozwoloną różnicę zegara systemowego między serwerami.
W oknie PowerShell z prawami administratora ustaw dozwoloną wartość przesunięcia na 2 minuty.Sprawdź, czy możesz się zalogować, a następnie zwiększ lub zmniejsz wartość w zależności od wyniku.
Określ bieżące ustawienie przesunięcia czasowego dla odpowiedniego zaufania jednostki uzależnionej za pomocą następującego polecenia:
Get-ADFSRelyingPartyTrust | Format-List -property Identifier,Name,NotBeforeSkew
Zaufanie jednostki uzależnionej jest identyfikowane przez adres URL pokazany w polu „Identifier" w wyniku poprzedniego polecenia dla tej konkretnej konfiguracji.Ten adres URL jest również pokazany w narzędziu zarządzania ADFS w oknie właściwości dla odpowiedniego zaufania jednostki uzależnionej na karcie „Identifiers" w polu „Relying Party Trusts", jak pokazano na poniższym zrzucie ekranu.
Ustaw przesunięcie czasowe na 2 minuty za pomocą następującego polecenia, odpowiednio podstawiając adres identyfikatora:
Set-ADFSRelyingPartyTrust –TargetIdentifier 'https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx' –NotBeforeSkew 2
Serwer IdP oparty na systemie UNIX
Upewnij się, że zegar systemowy jest ustawiony prawidłowo za pomocą usługi ntpd lub ręcznie za pomocą polecenia ntpdate z powłoki root lub z sudo, jak pokazano poniżej (zauważ, że jeśli czas jest przesunięty o więcej niż 0,5 sekundy, zmiana nie nastąpi natychmiast, ale powoli skoryguje zegar systemowy).Sprawdź, czy prawidłowo ustawiono także strefę czasową.
# ntpdate -u pool.ntp.org
Spostrzeżenie
To rozwiązanie można zastosować w przypadku takich usług IdP, jak Shibboleth.
Błąd 401: Brak autoryzacji danych logowania
Ten błąd występuje wtedy, gdy aplikacja nie obsługuje logowania federacyjnego i trzeba się do niej logować za pomocą kont Adobe ID. Przykłady takich aplikacji to: FrameMaker, RoboHelp i Adobe Captivate.
Błąd „Niepowodzenie przychodzącego żądania logowania SAML z następującym komunikatem: Odpowiedź SAML nie zawierała żadnych asercji”
Sprawdź proces logowania. Jeśli dostęp do strony logowania jest możliwy na innym komputerze lub w sieci, ale nie w systemach wewnętrznych, problem może dotyczyć łańcucha block agent. Ponadto przeprowadź śledzenie żądania SAML i sprawdź, czy w temacie SAML (element Subject) znajdują się parametry First Name (imię), Last Name (nazwisko) i Username (nazwa konta w postaci prawidłowego adresu e-mail).
Sprawdź, czy jest wysyłana prawidłowa asercja SAML:
- Brak elementu NameID w temacie. Sprawdź, czy element Subject (temat) zawiera element NameId. Musi być zgodny z atrybutem Email, który powinien być adresem e-mail użytkownika przeznaczonego do uwierzytelnienia.
- Sprawdź pisownię, szczególnie pod kątem łatwych do przeoczenia błędów, takich jak https zamiast http.
- Sprawdź, czy podano prawidłowy certyfikat. Dostawcy tożsamości muszą być skonfigurowani do używania nieskompresowanych żądań i odpowiedzi SAML.
Narzędzie takie jak SAML tracer dla Firefox może pomóc w rozpakowaniu asercji i wyświetleniu jej do inspekcji.Jeśli potrzebujesz pomocy od obsługi klienta Adobe, zostaniesz poproszony o ten plik.Szczegółowe informacje: Jak przeprowadzić śledzenie SAML.
Ten działający przykład SAML może pomóc w prawidłowym formatowaniu asercji SAML:
Z Microsoft ADFS
Upewnij się, że każde konto Active Directory ma adres e-mail wymieniony w Active Directory, aby pomyślnie się zalogować (dziennik zdarzeń: Odpowiedź SAML nie ma NameId w asercji).
Uzyskaj dostęp do Admin Console i wybierz kartę Tożsamość i domenę.
Wybierz Edytuj konfigurację i znajdź opcję Powiązanie IDP.Zmień ją na wartość HTTP-POST, a potem zapisz.
Przetestuj ponownie proces logowania.
Jeśli działa, ale wolisz poprzednie ustawienie, przełącz z powrotem na HTTP-REDIRECT i ponownie prześlij metadane do usługi ADFS.
Z innymi dostawcami tożsamości
Napotkanie błędu 400 oznacza, że dostawca tożsamości odrzucił pomyślne logowanie.
Sprawdź dzienniki dostawcy tożsamości w celu znalezienia źródła błędu i popraw problem przed ponowną próbą.
Błąd 403 „Nieprawidłowe działanie certyfikatu”
Zaktualizuj certyfikat w systemie Google Console w sekcji aplikacji Adobe SAML, a następnie prześlij ponownie pliki metadanych do serwisu Adobe Admin Console.
Błąd 403 „Nie skonfigurowano aplikacji dla użytkownika”
Zaktualizuj atrybut Entity ID (identyfikator jednostki) w systemie Google Console. Następnie wyeksportuj plik metadanych i prześlij go do serwisu Adobe Admin Console.
Błąd: „Obecnie brak dostępu” lub „Dostęp do tego elementu stąd nie jest możliwy”
Ten błąd na ogół występuje w sytuacji, gdy organizacja włączyła zasady dostępu warunkowego w konfiguracji usługi IdP.
Jeśli do wdrażania produktów stosuje się pakiety zarządzane, to należy utworzyć pakiet zarządzany w serwisie Adobe Admin Console z zaznaczoną opcją uwierzytelniania w przeglądarce. Następnie pakiet ten należy wdrożyć na urządzeniu użytkownika.
Jeśli nie, użytkownicy mogą otworzyć aplikację komputerową Creative Cloud Desktop i wybrać Zaloguj się za pomocą przeglądarki z menu Pomoc.
Błąd: „Aplikacja nie została przypisana”
W takim przypadku administrator musi dodać użytkowników do aplikacji Adobe SAML utworzonej na ich dostawcy tożsamości.Dowiedz się, jak utworzyć aplikację Adobe SAML w Google Admin Console lub portalu Microsoft Azure.
Błąd: „Nie masz dostępu do tej usługi.” Skontaktuj się z administratorem w celu uzyskania dostępu lub zaloguj się przy użyciu identyfikatora Adobe ID.
Przejrzyj dzienniki SAML. Imię, nazwisko lub adres e-mail wysyłane w potwierdzeniu SAML nie są zgodne z informacjami wprowadzonymi w serwisie Admin Console.
