The ADFS sign-in page shows "An error occurred" rather than a sign-in prompt

This usually means that either the FotoWeb or the ADFS side is incorrectly configured. Additional information about the error can be seen using Windows Event Viewer on the ADFS server, under "Applications and Services Log" → "AD FS" → Admin. If the error information is not helpful for identifying the problem, we recommend the following next steps:

• Submit a ticket to Fotoware support for further assistance
• If you have in-depth knowledge about the SAML 2.0 protocol, decode the SAML request to see if it is valid.

Note: The SAML request is part of the URL of the sign-in page. SAML requests do not contain any personally identifying information or other sensitive data, so it should be safe to send the URL to Fotoware support for further analysis.

After sign-in via ADFS, FotoWeb shows an error message: "We are sorry, but we could not log you on"

Possible causes for this:

• No groups were configured to which to add the user

If the cause of the error cannot be identified, please ontact Fotoware support for further assistance. The following information may be useful:

• Any FotoWeb server logs generated during the sign-in attempt

The payload of the SAML response:

Important: SAML responses may contain personal information about the user logging in, and they may be replayed to gain access to FotoWeb. Please send SAML responses only to parties you trust. For your own security and the privacy of your users, please try to reproduce the problem with a test account before capturing the SAML response.

If you have in-depth knowledge about the SAML 2.0 protocol, you may decode the SAML response yourself. The remainder of this section describes typical error scenarios that may be identified in this way.

MSIS7102: Requested Authentication Method is not supported on the STS

If this error is shown in the event viewer when a user reaches the ADFS sign-in page, and no sign-in prompt is shown to the user, try the following on the ADFS server:

• Open ADFS Management console.
• Select "Authentication Policies"
  • Under "Primary Authentication" → "Global Settings", click "Edit".
  • Enable "Forms Authentication" on the internet or intranet, depending on where users are failing to log on from.

It is up to the ADFS administrator to decide whether to use Windows authentication (local intranet only) or forms authentication or even multi-factor authentication or other methods.

By default, on a new ADFS installation, Windows Authentication is the only method enabled on the local intranet. Therefore, this errors occurs if Windows authentication fails for the current user (e.g., when using Firefox, which does not support Windows authentication without additional configuration).

User cannot be logged in (Internal error in authentication provider), but SAML response contains no error

This can happen if the user doesn't have one of the following attributes:

• First name
• Last name
• E-mail address
• Windows account name (Every user has one, just listing it for completeness)

Edit the user properties in Active Directory to resolve this problem.

The web application proxy configuration wizard fails with "Could not establish trust relationship for the SSL/TLS secure channel"

This means that the TLS certificate of the ADFS server is not trusted on the web application proxy server. For example, this can happen if the certificate was enrolled from an enterprise root CA of the organization's domain, and the web application proxy server is not a member of the domain (which is a very common scenario). To make the certificate trusted, you have to add both the TLS certificate of the ADFS server and the root certificate of the enterprise root CA to the trusted root CA certificates on the web application proxy server. To debug the trust relationship, open the URL of the ADFS server in a browser on the web application proxy server, e.g., https://adfs-server-name.yourdomain.org/adfs/ls. If you get a certificate error, then view the certificate and its certificate path. This should show which certificates are missing and need to be imported. Alternatively, add the web application proxy server to the domain, or use a certificate signed by a public CA.

The ADFS service (adfssrv) does not start or is stuck in "Starting" after reboot of the ADFS server

This can happen with Windows Server 2012 R2 (and maybe newer versions) when using a group-managed service account (Gmsa) for running the ADFS service. The following workaround can be used:

1. Open regedit and go to HKLM\System\ControlSet001\Services\adfssrv
2. Change the attribute Start to 3 (manual).
3. Reboot the ADFS server.
4. Open the Service Manager (services.msc).
5. Set the "Microsoft Key Distribution Service" to start automatically.
6. Set the "Active Directory Federation Services" to "Automatic (Delayed)".
7. Reboot the system or manually start the services mentioned above.