220-1102 Question 348
Single answerSingle sign-on (SSO)A company uses a cloud identity provider to give employees single sign-on (SSO) access to a CRM application and a ticketing portal. After a password reset, several users report they can sign in to their laptops and email, but when they click the CRM tile from the company portal, they are repeatedly prompted to sign in again. Other cloud apps still open normally from the same portal. Which action should the technician take FIRST to restore the SSO experience for the affected application?
- A
Verify that the CRM application's federation/trust configuration with the identity provider is still valid and that its SSO certificate or metadata has not expired or changed
- B
Clear the users' browser cache and cookies on every affected system because SSO failures are usually caused by local browser data
- C
Disable multifactor authentication for the affected users so the identity provider stops requesting another credential prompt
- D
Create local CRM application passwords for each affected user so they can bypass the identity provider when launching the app
Show answer and explanation
Correct answer: A
Explanation
Single sign-on allows users to authenticate once with a central identity provider and then access multiple integrated applications without entering credentials again for each one. When users can still access other SSO-enabled services, the technician should focus on the specific application that is failing rather than assuming a user password problem or endpoint issue. In real environments, common causes include expired SAML signing certificates, outdated federation metadata, incorrect assertion consumer service URLs, invalid claim mappings, or a broken trust relationship between the application and the identity provider. This aligns with standard vendor guidance from enterprise identity platforms such as Microsoft Entra ID, Okta, Google Workspace, and other SAML/OIDC providers: if authentication works broadly but fails for one integrated service, verify the app integration configuration first. Clearing browser data can be a secondary step if the issue appears isolated to one device, but it is less likely when several users experience the same app-specific failure.
- A. Correct.
This is correct. In an SSO environment, if users can authenticate to the identity provider and access other federated apps, the identity source is generally working. A repeated sign-in prompt for only one application strongly suggests an application-specific SSO issue, such as expired SAML signing certificates, invalid federation metadata, a broken trust relationship, or a misconfigured redirect/claim mapping. Checking the CRM app's federation/trust settings is the best first troubleshooting step because it targets the failing part of the sign-on flow.
- B. Incorrect.
This is incorrect. Clearing cache and cookies can help with some sign-in issues, especially if stale session data is causing a loop, but it is not the best first step here because multiple users are affected and only one SSO-connected application is failing while others work. That pattern points to a central configuration problem with the application rather than a local browser issue on every endpoint.
- C. Incorrect.
This is incorrect. Multifactor authentication is not the same as SSO. MFA adds verification steps, while SSO allows one authentication event to grant access to multiple applications. Disabling MFA would reduce security and would not address an application-specific SSO trust or federation failure. A second prompt for credentials in one app does not automatically mean MFA is the cause.
- D. Incorrect.
This is incorrect. Creating separate local application passwords would work against the purpose of SSO and create additional account-management and security problems. Best practice is to restore the federated sign-in path, not bypass it with per-application credentials unless there is a documented break-glass procedure approved by the organization.