Open the AD FS Management application on your server, and within the folder AD FS > Service > Endpoints, select the Federation Metadata.
This article does not apply to SSO setups using Google federation or Microsoft Azure Sync.
Refer to the following articles if your organization has set up SSO via any of these identity providers:
After successfully configuring SSO within the Adobe Admin Console, ensure that you clicked Download Adobe Metadata file and have saved the SAML XML Metadata file to your computer. Your identity provider requires this file to enable single sign-on. 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.
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.
Issues with single sign-on are often caused by basic errors that are easy to overlook. In particular, check the following:
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:
On the Products tab:
On the Users tab:
Possible causes for this error:
How to resolve:
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 and ensure that the user's email address to log in matches the following:
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.
This issue occurs when your directory's certificate has expired. To update the certificate, you must download the certificate or metadata from Identity provider and upload it in the Adobe Admin Console.
For example, follow the steps below if your IdP is Microsoft AD FS:
Open the AD FS Management application on your server, and within the folder AD FS > Service > Endpoints, select the Federation Metadata.
Use a browser to navigate to the URL provided against Federation Metadata and download the file. For example, https://<your AD FS hostname>/FederationMetadata/2007-06/FederationMetadata.xml.
Accept any warnings if prompted.
Sign in to your Adobe Admin Console and navigate to Settings > Identity > Directories. Select the directory to update and click Configure on the SAML provider card.
Then, upload the IdP metadata file and Save.
1. Ensure that the system clock is synchronized 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 resynchronization the system clock with the Time Server with the following command:
w32tm /resync
If the system clock is set correctly and you are still seeing the above error, you may must 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 Management 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
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
This works with identity providers such as Shibboleth.
This error occurs when the application does not support Federated login and must be logged into as an Adobe ID. FrameMaker, RoboHelp, and Adobe 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.
Validate that the proper SAML assertion is being sent:
A utility such as SAML Tracer for Firefox can help unpack the assertion and display it for inspection. If you need assistance from Adobe Customer Care, you will be asked for this file. For details, see how to perform a SAML trace.
The following working example may help in properly formatting your SAML assertion:
Prevziať
With Microsoft ADFS:
With other IdPs:
Prihláste sa do svojho účtu