Możesz rozwiązać typowe błędy, które mogą wystąpić podczas integracji lub korzystania z logowania jednokrotnego w Google Workspace, gdy Google jest dostawcą usług.
Konfiguracja i aktywacja
„Ta domena nie została skonfigurowana do korzystania z logowania jednokrotnego”.
Ten błąd zwykle oznacza, że używasz wersji Google Workspace, która nie obsługuje logowania jednokrotnego (np. wycofanej bezpłatnej wersji G Suite). Wszystkie obecne wersje Workspace obsługują logowanie jednokrotne przy użyciu zewnętrznego dostawcy tożsamości.
Jeśli używasz wersji Google Workspace, która obsługuje logowanie jednokrotne, wypróbuj te rozwiązania:
- Sprawdź, czy w konfiguracji logowania jednokrotnego dostawcy tożsamości jest używana prawidłowa nazwa domeny Google Workspace.
- Jeśli ten błąd wystąpi po skonfigurowaniu profili SSO, dostawca tożsamości może być skonfigurowany do wysyłania asercji SAML do punktu końcowego starszego profilu SSO. Jeśli dostawca tożsamości ma zakodowany na stałe starszy punkt końcowy logowania jednokrotnego, wykonaj te czynności:
- Skonfiguruj starszą wersję logowania jednokrotnego.
- Poproś dostawcę tożsamości o zaktualizowanie integracji z Google.
„Nie można uzyskać dostępu do tego konta, bo domena jest skonfigurowana nieprawidłowo. Spróbuj ponownie później”.
Ten błąd oznacza, że logowanie jednokrotne zostało nieprawidłowo skonfigurowane w konsoli administracyjnej Google. Aby rozwiązać ten problem, wykonaj opisane poniżej czynności:
- W konsoli administracyjnej kliknij Bezpieczeństwo
Konfigurowanie logowania jednokrotnego (SSO) przy użyciu zewnętrznego dostawcy tożsamości i zaznacz pole Skonfiguruj logowanie jednokrotne przy użyciu zewnętrznego dostawcy tożsamości. - W odpowiednich polach podaj adresy URL strony logowania, strony wylogowywania oraz strony zmiany hasła Twojej organizacji.
- Wybierz i prześlij poprawny certyfikat weryfikacji.
- Kliknij Zapisz, poczekaj kilka minut, aż zmiany zaczną obowiązywać, i ponownie spróbuj przeprowadzić integrację.
Najemca Google skonfigurowany z niedozwolonym prefiksem
W przypadku aplikacji na iOS, gdy URL strony SSO zaczyna się od „google.” (lub podobny), aplikacja Google na iOS przekierowuje do Safari. W rezultacie proces logowania jednokrotnego kończy się niepowodzeniem. Pełna lista niedozwolonych prefiksów:
- googl.
- google.
- www.googl.
- www.google.
Jeśli używasz adresów URL stron logowania jednokrotnego z tymi prefiksami, musisz je zmienić.
Użytkownik został nieoczekiwanie przekierowany do zewnętrznego dostawcy tożsamości zamiast do logowania w Google
Jeśli po usunięciu użytkownika z grupy logowania jednokrotnego lub wyłączeniu logowania jednokrotnego dla jego grupy lub jednostki organizacyjnej użytkownik zostanie przekierowany do zewnętrznego dostawcy tożsamości, sprawdź te ustawienia w konsoli administracyjnej:
- Kolejność priorytetów grup – otwórz Zarządzaj przypisaniem profili logowania jednokrotnego Grupy i sprawdź, czy użytkownik należy do innej grupy, która ma wyższy priorytet na liście grup. Jeśli użytkownik należy do wielu grup, pierwszeństwo ma grupa o najwyższym priorytecie. Nadaj grupie z wyłączonym logowaniem jednokrotnym wyższy priorytet niż grupie, która korzysta z zewnętrznego profilu SSO, lub usuń użytkownika z grupy z logowaniem jednokrotnym o wyższym priorytecie.
- Członkostwo w grupie zagnieżdżonej – sprawdź, czy użytkownik należy do grupy podrzędnej zagnieżdżonej w grupie nadrzędnej przypisanej do logowania jednokrotnego. Użytkownicy dziedziczą profil SSO wszystkich grup nadrzędnych, do których należą. Usuń użytkownika z grupy podrzędnej lub przypisz profil SSO bezpośrednio do grupy podrzędnej i nadaj jej wyższy priorytet na liście niż grupie nadrzędnej.
- Dziedziczenie jednostki organizacyjnej – jeśli użytkownik nie ma przypisanej grupy, sprawdź profil logowania jednokrotnego przypisany do jego jednostki organizacyjnej. Jeśli jednostka organizacyjna użytkownika jest przypisana do zewnętrznego profilu SSO, przenieś użytkownika do jednostki organizacyjnej, w której logowanie jednokrotne jest wyłączone, lub wyłącz logowanie jednokrotne w jednostce organizacyjnej użytkownika.
Analizowanie odpowiedzi SAML
„Brak wymaganego parametru odpowiedzi SAMLResponse”
Ten komunikat o błędzie oznacza, że Twój dostawca tożsamości nie podaje Google prawidłowej odpowiedzi SAML. Taka sytuacja jest niemal na pewno spowodowana problemem z konfiguracją dostawcy tożsamości.
- Sprawdź dzienniki dostawcy tożsamości i upewnij się, że nic nie uniemożliwia mu prawidłowego zwracania odpowiedzi SAML.
- Upewnij się, że dostawca tożsamości nie wysyła do Google Workspace zaszyfrowanej odpowiedzi SAML. Google Workspace akceptuje tylko niezaszyfrowane odpowiedzi SAML. W szczególności zwróć uwagę na fakt, że oprogramowanie Active Directory Federation Services 2.0 firmy Microsoft często wysyła zaszyfrowane odpowiedzi SAML w konfiguracjach domyślnych.
„Brak wymaganego parametru odpowiedzi RelayState”
Specyfikacja SAML 2.0 wymaga, aby dostawcy tożsamości pobierali i odsyłali parametr adresu URL RelayState od dostawców zasobów (takich jak Google Workspace). Google Workspace przekazuje tę wartość dostawcy tożsamości w żądaniu SAML, a dokładna treść może się różnić przy każdym logowaniu. Aby uwierzytelnienie przebiegło pomyślnie, w odpowiedzi SAML musi być zwrócony dokładny parametr RelayState. Zgodnie ze specyfikacją standardu SAML dostawca tożsamości nie powinien zmieniać parametru RelayState w przepływie logowania.
- Ten problem można zdiagnozować dokładniej, przechwytując nagłówki HTTP podczas próby logowania. Wyodrębnij parametr RelayState z nagłówków HTTP zawierających zarówno żądanie, jak i odpowiedź SAML oraz upewnij się, że wartości parametru RelayState w żądaniu i odpowiedzi są takie same.
- Większość komercyjnych lub działających na licencji open-source dostawców tożsamości na potrzeby logowania jednokrotnego domyślnie przekazuje parametr RelayState bezproblemowo. Aby zapewnić optymalny poziom bezpieczeństwa i niezawodności, zalecamy użycie jednego z tych istniejących rozwiązań. Nie możemy zaoferować pomocy technicznej do niestandardowego oprogramowania logowania jednokrotnego.
Zawartość odpowiedzi SAML
„Nie można skorzystać z tej usługi, ponieważ żądanie logowania zawierało nieprawidłowe informacje o [miejscu docelowym | odbiorcach | adresacie]. Zaloguj się i spróbuj ponownie”.
Ten błąd oznacza, że element destination (miejsce docelowe), audience (odbiorcy) lub recipient (adresat) w potwierdzeniu SAML zawierał nieprawidłowe informacje lub był pusty. Potwierdzenie SAML musi zawierać wszystkie elementy. W tabelach w artykule Wymagania potwierdzenia logowania jednokrotnego znajdziesz opisy i przykłady poszczególnych elementów:
„Nie można uzyskać dostępu do tej usługi, ponieważ żądanie logowania nie zawierało informacji o adresacie. Zaloguj się i spróbuj ponownie”.
Ten komunikat o błędzie zazwyczaj oznacza, że w odpowiedzi SAML otrzymanej od dostawcy tożsamości brakuje czytelnej wartości Recipient (lub że wartość Recipient jest nieprawidłowa). Wartość Recipient jest ważnym składnikiem odpowiedzi SAML.
- Ten problem można zdiagnozować dokładniej, przechwytując nagłówki HTTP podczas próby logowania.
- Wyodrębnij żądanie i odpowiedź SAML z nagłówków HTTP.
- Upewnij się, że odpowiedź SAML zawiera wartość Recipient i że ta wartość odpowiada wartości w żądaniu SAML.
Uwaga: ten komunikat o błędzie może mieć też postać „Nie można uzyskać dostępu do tej usługi, bo Twoje żądanie logowania zawierało nieprawidłowe informacje o adresacie. Zaloguj się i spróbuj ponownie”.
„Nie można uzyskać dostępu do tego konta, ponieważ nie można potwierdzić danych logowania”.
Ten błąd wskazuje na problem z certyfikatami, których używasz do podpisywania procesu uwierzytelniania. Zwykle oznacza to, że klucz prywatny użyty do podpisania odpowiedzi SAML nie pasuje do certyfikatu klucza publicznego, który Google Workspace ma w pliku.
Błąd ten może wystąpić również wtedy, gdy odpowiedź SAML nie zawiera realnej nazwy użytkownika kont Google. Google Workspace analizuje odpowiedź SAML dla elementu XML o nazwie NameID i oczekuje, że element ten będzie zawierał nazwę użytkownika w Google Workspace lub pełny adres e-mail w Google Workspace.
- Upewnij się, że do Google Workspace został przesłany ważny certyfikat, i w razie potrzeby koniecznie go zastąp. W konsoli administracyjnej Google kliknij Bezpieczeństwo Konfigurowanie logowania jednokrotnego (SSO) przy użyciu zewnętrznego dostawcy tożsamości i kliknij Zamień certyfikat.
- Jeśli w swoim elemencie NameID używasz pełnego adresu e-mail (a na pewno tak jest, jeżeli stosujesz logowanie jednokrotne do środowiska aplikacji obejmującego wiele domen), upewnij się, że atrybut Format elementu NameID określa, iż wykorzystany zostanie pełny adres e-mail, tak jak pokazano w następującym przykładzie: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress".
- Sprawdź, czy element NameID zawiera prawidłową nazwę użytkownika lub adres e-mail. Aby mieć pewność, wyodrębnij odpowiedź SAML wysyłaną do Google Workspace i sprawdź wartość elementu NameID.
- Wielkość liter w elemencie NameID ma znaczenie: upewnij się, że odpowiedź SAML zawiera element NameID z wartością, która odpowiada wielkości liter w nazwie użytkownika lub adresie e-mail w Google Workspace.
- Jeśli Twój dostawca tożsamości szyfruje potwierdzenie SAML, wyłącz szyfrowanie.
- Upewnij się, że odpowiedź SAML nie zawiera żadnych niestandardowych znaków ASCII. Błąd ten występuje najczęściej w atrybutach DisplayName, GivenName i Surname elementu AttributeStatement, na przykład:
- <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
<AttributeValue>Blüte, Eva</AttributeValue> </Attribute> - <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>Blüte</AttributeValue> </Attribute>
- <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
Więcej informacji o formatowaniu elementu NameID znajdziesz w artykule Wymagania potwierdzenia logowania jednokrotnego.
„Nie można skorzystać z tej usługi, ponieważ wygasła ważność danych logowania. Zaloguj się i spróbuj ponownie”.
Ze względów bezpieczeństwa proces logowania jednokrotnego musi zakończyć się w określonym przedziale czasu. W przeciwnym razie uwierzytelnianie się nie powiedzie. Jeśli zegar na serwerze dostawcy tożsamości nie jest prawidłowo wyregulowany, większość prób logowania będzie uznawanych za przekraczające dopuszczalny czas i uwierzytelnianie będzie kończyło się niepowodzeniem oraz wyświetleniem wskazanego powyżej komunikatu o błędzie.
- Sprawdź zegar na serwerze dostawcy tożsamości. Ten błąd jest niemal zawsze powodowany źle wyregulowanym zegarem dostawcy tożsamości, który dodaje nieprawidłowe sygnatury czasowe do odpowiedzi SAML.
- Zsynchronizuj zegar na serwerze dostawcy tożsamości z wiarygodnym internetowym serwerem czasu. Jeśli ten problem występuje nagle w środowisku produkcyjnym, zazwyczaj jest spowodowany niepowodzeniem ostatniej synchronizacji czasu, które doprowadziło do rozregulowania czasu serwera. Ponowienie próby zsynchronizowania czasu (jeśli to możliwe, użyj bardziej wiarygodnego serwera czasu) pozwala szybko wyeliminować ten błąd.
- Ten problem może także wystąpić w przypadku ponownego wysłania danych SAML z poprzedniej próby logowania. W takim przypadku można go rozwiązać, sprawdzając żądanie i odpowiedź SAML (uzyskane z dzienników nagłówka HTTP przechwyconych podczas próby logowania).
„Nie można skorzystać z tej usługi, ponieważ dane logowania nie zostały jeszcze zweryfikowane. Zaloguj się i spróbuj ponownie”.
Ze względów bezpieczeństwa proces logowania jednokrotnego musi zakończyć się w określonym przedziale czasu. W przeciwnym razie uwierzytelnianie się nie powiedzie. Jeśli zegar na serwerze dostawcy tożsamości nie jest prawidłowo wyregulowany, większość prób logowania będzie uznawanych za przekraczające dopuszczalny czas i uwierzytelnianie będzie kończyło się niepowodzeniem oraz wyświetleniem wskazanego powyżej komunikatu o błędzie.
- Sprawdź zegar na serwerze dostawcy tożsamości. Ten błąd jest niemal zawsze powodowany źle wyregulowanym zegarem dostawcy tożsamości, który dodaje nieprawidłowe sygnatury czasowe do odpowiedzi SAML.
- Zsynchronizuj zegar na serwerze dostawcy tożsamości z wiarygodnym internetowym serwerem czasu. Jeśli ten problem występuje nagle w środowisku produkcyjnym, zazwyczaj jest spowodowany niepowodzeniem ostatniej synchronizacji czasu, które doprowadziło do rozregulowania czasu serwera. Ponowienie próby zsynchronizowania czasu (jeśli to możliwe, użyj bardziej wiarygodnego serwera czasu) pozwala szybko wyeliminować ten błąd.