Attempting to sign in to Adobe products, services, or mobile apps with a Federated ID (SSO) results in one of the following error messages.
After successfully configuring SSO within the Adobe Admin Console, ensure that you clicked Download Metadata and have saved the SAML XML Metadata file to your computer. Your identity provider requires this file to enable single sign-on. You must import the XML configuration details properly into your identity provider (IdP). This is required for SAML integration with your IdP and will make sure that the data is configured properly.
The following are some common configuration issues:
- Certificate is in a format besides PEM.
- Certificate has an extension besides .cer. .pem and .cert does not work.
- Certificate is encrypted.
- The certificate is in a single-line format. Multi-line is required.
- Certificate Revocation Verification is turned on (not supported currently).
- IdP issuer in the SAML is not the same as was specified in the Admin Console (for example, spelling error, missing characters, https vs http).
If you have questions as to how to use the SAML XML Metadata file to configure your IdP, reach out to your IdP directly for instructions, which vary per IdP.
Some examples for specific IdPs (not a comprehensive list—any SAML 2 compliant IdP works):
Okta: Manually take the required information within the XML file and input it into the proper UI fields to configure the data properly.
Ping Federate: Upload the XML file or input the data into the proper UI fields.
Microsoft ADFS: Your certificate must be in PEM format, but the default for ADFS is DER format. You can convert the certificate using the openssl command, available on OS X, Windows, or Linux as follows:
openssl x509 -in certificate.cer -out certificate.pem -outform PEM
After performing the above step, rename the certificate .cer.
Also ensure that the correct certificate is used if you have more than one; it must be the same one that is going to be signing the requests. (For example, if the "token signing" certificate is signing the requests, that is the certificate to use.) Certificate Revocation Verification must be off.
If you have configured your IdP to the best of your knowledge, try one or more of the following depending on the error received.
Issues with single sign-on are often caused by very basic errors that are easy to overlook. In particular, check the following:
- The user is assigned to a product configuration with an entitlement.
- The user's first name, last name, and email address are being sent in SAML exactly as they appear in the enterprise dashboard and are present in the SAML with the correct labeling.
- Check all entries in Admin Console and your identity provider for spelling or syntax errors.
- The Creative Cloud Desktop application has been updated to the latest version.
- The user is logging in to the correct place (CC Desktop app, CC application, or adobe.com)
This error typically occurs after user authentication has succeeded and Okta has successfully forwarded the authentication response to Adobe.
In the Adobe Admin Console, validate the following:
On the Identity tab:
- Ensure that the associated domain has been activated.
On the Products tab:
- Ensure that the user is associated to the correct product nickname and in the domain you claimed to be configured as Federated ID.
- Ensure that the product nickname has the correct entitlement(s) assigned to it.
On the Users tab:
- Ensure that the user name of the user is in the form of a complete email address.
Possible causes for this error:
- The first name, last name, or email address being sent in the SAML assertion does not match the information entered in the Admin Console.
- The user isn't associated to the right product, or the product is not associated with the correct entitlement.
- The SAML user name is coming across as something other than an email address. All users must be in the domain you claimed as part of the setup process.
How to resolve:
- Verify the dashboard configuration for the user: user information and product configuration.
- Run a SAML trace and validate that the information being sent matches the dashboard, and then correct any inconsistencies.
The error "another user is currently logged in" occurs when the attributes sent in the SAML assertion do not match the email address that was used to start the login process.
Check the attributes in the SAML assertion and make sure that they are an exact match to the ID the user is attempting to use, and also an exact match with the Admin Console.
The error "failed to make a call as the system principle" (followed by a random code) or "user creation failed" indicates a problem with the SAML attributes. Make sure that the case of the attribute names is correct (case sensitive, naming): FirstName, LastName, Email. For example, ending the attribute as "email" instead of "Email" can cause these errors.
These errors can also occur if the SAML Assertion does not contain the user’s email in the Subject > NameId element (when using SAML Tracer, it should have the format emailAddress and the actual email as text as value).
If you need assistance from Adobe support, please include a SAML trace.
Error "The Issuer in the SAML response did not match the issuer configured for the identity provider"
IDP Issuer in the SAML Assertion is different from what has been configured in the Inbound SAML. Look for typos (such as http vs https). When checking the IDP Issuer string with the customer SAML system, you're looking for an EXACT match to the string they provided. This issue comes up sometimes because a slash was missing at the end.
If you need assistance with this error, provide a SAML trace and values you entered in the Adobe dashboard.
Error "The digital signature in the SAML response did not validate with the identity provider's certificate"
The certificate file is most likely incorrect and needs to be re-uploaded. This issue generally happens after a change has been made and the admin references the incorrect cert file. Also check format type (needs to be PEM format for ADFS).
Windows-based IdP Server:
1. Ensure the system clock is synchronised with an accurate time server
Check the accuracy system clock against your time server with this command; the "Phase Offset" value should be a small fraction of a second:
w32tm /query /status /verbose
You can cause an immediate resynchronisation the system clock with the Time Server with the following command:
If the system clock is set correctly and you are still seeing the above error, you may need to adjust the time-skew setting to increase the tolerance of the difference between clocks between the server and client.
2. Increase the allowed difference in system clock between servers
From a Powershell window with administrative rights, set the allowed skew value to 2 minutes. Check whether you are able to log in, and then either increase or decrease the value depending on the result.
Determine the current time-skew setting for the relevant Relying Party Trust with the following command:
Get-ADFSRelyingPartyTrust | Format-List -property Identifier,Name,NotBeforeSkew
The Relying Party Trust is identified by the URL shown in the "Identifier" field of the output of the previous command for that particular configuration. This URL is also shown in the ADFS Managment utility in the properties window for the relevant Relying Party Trust on the "Identifiers" tab in the field "Relying Party Trusts", as shown in the screenshot below.
Set the time skew to 2 minutes with the following command, substituting the Identifier address accordingly:
Set-ADFSRelyingPartyTrust –TargetIdentifier 'https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx' –NotBeforeSkew 2
UNIX-based IdP Server
Ensure that the system clock is set correctly either using the ntpd service, or manually with the ntpdate command from a root shell or with sudo as shown below (note that if the time is offset by more than 0.5 seconds, the change will not happen immediately, but it will slowly correct the system clock). Ensure that the timezone is also set correctly.
# ntpdate -u pool.ntp.org
Check the attributes because they need to match the following case exactly: FirstName, LastName, Email. This error message can mean that one of the attributes has the wrong case, such as "email" instead of "Email." Also check the recipient value—it should reference the ACS string.
This error occurs when the application does not support Federated login and must be logged into as an Adobe ID. Framemaker, RoboHelp, and Captivate are examples of applications with this requirement.
Check the login workflow. If you're able to access the sign-in page on another machine or network but not internally, the problem could be a block agent string. Also, run a SAML trace and confirm that First Name, Last Name, and Username as a properly formatted email address are in the SAML subject.
Error 400 bad request / Error "The status of the SAML request was not successful" / SAML certification validation failed
Validate that the proper SAML assertion is being sent:
- Validate that the identity provider passes the following attributes (case-sensitive) in the SAML assertion: FirstName, LastName, Email. If these attributes are not configured in the IdP to be sent over as part of the SAML 2.0 Connector configuration, the authentication will not work.
- Not having a NameID element in the subject. Validate that the Subject element contains a NameId element. It must be equal to the Email attribute, which should be the email address of the user that you want to authenticate.
- Spelling errors, especially easily overlooked ones like https vs http.
- Validate that the correct certificate was provided. IDPs must be configured to use uncompressed SAML request/responses. The Okta Inbound SAML Protocol works only with the Uncompressed settings (not Compressed settings).
A utility such as SAML Tracer for Firefox can help unpack the assertion and display it for inspection. If you need assistance from Adobe support, you will be asked for this file.
The following working example may help in properly formatting your SAML assertion:
With Microsoft ADFS:
- Every Active Directory account must have an email address listed in Active Directory to successfully log in (event log: The SAML response does not have NameId in the assertion). Check this first.
- Access the dashboard.
- Click the Identity tab and the domain.
- Click Edit Configuration.
- Locate IDP Binding. Switch to HTTP-POST and then save.
- Retest the login experience.
- If it works but you prefer the prior setting, simply switch back to HTTP-REDIRECT and re-upload the metadata into ADFS.
With other IdPs:
- Encountering error 400 means that a successful login was rejected by your IdP.
- Check your IdP logs for the source of the error.
- Correct the issue and try again.
See the step-by-step guide to configuring Microsoft ADFS.
If a Mac client has a blank window in Creative Cloud, make sure that the "Creative Cloud" user agent is trusted.
See the step-by-step guide to configuring Microsoft Azure.
See the step-by-step guide to configuring OneLogin.
See the step-by-step guide to configuring Okta.
See the step-by-step guide to configuring Centrify.