Your Case Information Can Not Be Verified Please Try Again
Troubleshoot single sign-on (SSO)
This document provides steps to resolve common error messages encountered during the integration or use of SAML-based single sign-on (SSO) with Google Workspace when Google is the service provider (SP).
Configuration and Activation
"This domain is not configured to use single sign-on."
This error typically indicates that you're trying to use single sign-on with a Standard (Free) Edition of G Suite, which doesn't support SSO. If you're certain that you're using a Google Workspace edition that supports SSO, check the configuration in your identity provider to ensure that you have entered your Google Workspace domain name correctly.
"This account cannot be accessed because the domain is incorrectly configured. Please try again later."
This error indicates you haven't set up SSO correctly in the Google Admin console. Please review the following steps to correct the situation:
- In the Admin console, go toSecurity
Set up single sign-on (SSO) with a third party IdP, and check theSet up SSO with third-party identity provider box.
- Provide URLs for your organization's sign-in page, sign-out page, and change password page in the corresponding fields.
- Choose and upload a valid verification certificate file.
- Click Save, wait a few minutes for your changes to take effect, and test your integration again.
Parsing the SAML Response
"The required response parameter SAMLResponse was missing"
This error message indicates that your Identity Provider is not providing Google with a valid SAML response of some kind. This problem is almost certainly due to a configuration issue in the Identity Provider.
- Check your Identity Provider logs and make sure that there is nothing preventing it from correctly returning a SAML Response.
- Ensure that your Identity Provider is not sending Google Workspace an encrypted SAML Response. Google Workspace only accepts SAML Responses that are unencrypted. In particular, please note that Microsoft's Active Directory Federation Services 2.0 often sends encrypted SAML Responses in default configurations.
"The required response parameter RelayState was missing"
The SAML 2.0 specification requires that Identity Providers retrieve and send back a RelayState URL parameter from Resource Providers (such as Google Workspace). Google Workspace provides this value to the Identity Provider in the SAML Request, and the exact contents can differ in every login. For authentication to complete successfully, the exact RelayState must be returned in the SAML Response. According to the SAML standard specification, your Identity Provider should not modify the RelayState during the login flow.
- Diagnose this issue further by capturing HTTP headers during a login attempt. Extract the RelayState from the HTTP headers with both the SAML Request and Response, and make sure that the RelayState values in the Request and Response match.
- Most commercially-available or open-source SSO Identity Providers transmit the RelayState seamlessly by default. For optimum security and reliability, we recommend that you use one of these existing solutions and cannot offer support for your own custom SSO software.
Contents of the SAML Response
"This service cannot be accessed because your login request contained invalid [destination|audience|recipient] information. Please log in and try again."
This error indicates that the destination,audience or recipient elements in the SAML assertion contained invalid information or were empty. All elements must be included in the SAML assertion. Check the following table for descriptions and examples for each element.
| Element | <Audience> |
|---|---|
| Description | URI that identifies the intended audience which requires the value of ACS URI. Note: element value cannot be empty |
| Required Value | https://www.google.com/a/<example.com>/acs |
| Example | <saml:Conditions NotBefore="2014-11-05T17:31:37Z" |
| Element | Destination attribute of the <StatusResponseType> type |
|---|---|
| Description | URI the SAML assertion is sent to. Optional, but if declared it will need a value of the ACS URI. |
| Required Value | https://www.google.com/a/<example.com>/acs |
| Example | <saml:Response |
| Element | Recipient attribute of <SubjectConfirmationData> |
|---|---|
| Description |
|
| Required Value | https://www.google.com/a/<example.com>/acs |
| Example | <saml:Subject> |
For details of all the required elements, please review the article SSO assertion requirements.
"This service cannot be accessed because your login request contained no recipient information. Please log in and try again."
This error usually indicates that the SAML Response from your Identity Provider lacks a readable Recipient value (or that the Recipient value is incorrect). The Recipient value is an important component of the SAML Response.
- Diagnose this issue further by capturing HTTP headers during a login attempt.
- Extract the SAML Request and Response from the HTTP headers.
- Ensure that the Recipient value in the SAML Response exists and that it matches the value in the SAML Request.
Note: this error message may also appear as "This service cannot be accessed because your login request contained invalid recipient information. Please log in and try again."
"This account cannot be accessed because the login credentials could not be verified."
This error indicates a problem with the certificates you're using to sign the authentication flow. It usually means the private key used to sign the SAML Response doesn't match the public key certificate that Google Workspace has on file.
It can also occur if your SAML Response doesn't contain a viable Google Accounts username. Google Workspace parses the SAML Response for a XML element called a NameID, and expects this element to contain a Google Workspace username or a full Google Workspace email address.
- Ensure that you've uploaded a valid certificate to Google Workspace, and if necessary replace the certificate. In the Google Admin console, go toSecurity
- If you're using a full email address in your NameID element (you must be if you are using SSO with a multidomain Apps environment), ensure that the Format attribute of the NameID element specifies that a full email address is to be used, as in the following example: Format="urn:oasis:names:tc:SAML:2.0:nameid-format:email"
- Ensure that you're populating the NameID element with a valid username or email address. To be certain, extract the SAML Response you're sending to Google Workspace, and check the value of the NameID element.
- NameID is case-sensitive: ensure that the SAML Response is populating NameID with a value that matches the case of the Google Workspace username or email address.
- If your Identity Provider is encrypting your SAML Assertion, disable encryption.
- Ensure that the the SAML Response doesn't include any non-standard ASCII characters. This issue most commonly occurs in the DisplayName, GivenName, and Surname attributes in the AttributeStatement, for example:
- <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">
For more information on how to format the NameID element, see SSO assertion requirements.
"This service cannot be accessed because your login credentials have expired. Please log in and try again."
For security reasons, the SSO login flow must complete within a certain timeframe, or authentication will fail. If the clock on your Identity Provider is incorrect, most or all login attempts will appear to be out of the acceptable timeframe, and authentication will fail with the above error message.
- Check the clock on your Identity Provider's server. This error is almost always caused by the Identity Provider's clock being incorrect, which adds incorrect timestamps to the SAML Response.
- Re-sync the Identity Provider server clock with a reliable internet time server. When this issue suddenly occurs in a production environment, it is typically because the last time sync failed, causing the server time to become inaccurate. Repeating the time sync (possibly with a more reliable time server) will quickly remedy this issue.
- This issue can also occur if you are re-sending SAML from a previous login attempt. Examining your SAML Request and Response (obtained from HTTP header logs captured during a login attempt) can help you debug this further.
"This service cannot be accessed because your login credentials are not yet valid. Please log in and try again."
For security reasons, the SSO login flow must complete within a certain timeframe, or authentication will fail. If the clock on your Identity Provider is incorrect, most or all login attempts will appear to be out of the acceptable timeframe, and authentication will fail with the above error message.
- Check the clock on your Identity Provider's server. This error is almost always caused by the Identity Provider's clock being incorrect, which adds incorrect timestamps to the SAML Response.
- Re-sync the Identity Provider server clock with a reliable internet time server. When this issue suddenly occurs in a production environment, it is typically because the last time sync failed, causing the server time to become inaccurate. Repeating the time sync (possibly with a more reliable time server) will quickly remedy this issue.
Was this helpful?
How can we improve it?
Source: https://support.google.com/a/answer/2463723?hl=en
0 Response to "Your Case Information Can Not Be Verified Please Try Again"
Post a Comment