220-1102 Question 374
Single answerSSOA company uses a cloud identity provider to give employees single sign-on (SSO) access to email, file storage, and a customer management portal. After signing in to Windows in the morning, users can open the email and file storage apps without entering credentials again, but they are repeatedly prompted to sign in when opening the customer management portal. The portal vendor confirms the application supports SAML-based federation. Which action is the BEST next step for the technician to restore SSO for that portal?
- A
Verify that the customer management portal is correctly configured as a federated application in the identity provider and that the SAML trust/certificate settings are valid
- B
Clear the browser cache and cookies on each affected workstation so the portal can reuse stored local credentials
- C
Disable multifactor authentication for the portal so the SSO token is not interrupted by additional prompts
- D
Reset each user's Windows password and have them sign in again so the portal can synchronize their credentials
Show answer and explanation
Correct answer: A
Explanation
Single sign-on allows a user to authenticate once with a central identity source and then access multiple applications without reentering credentials for each service. In a real support scenario, if SSO works for several applications but fails for only one, the best next step is to investigate that application's federation or trust configuration. For SAML, technicians should verify the application is properly configured in the identity provider, confirm the assertion consumer service (ACS) URL and entity ID match, and check whether the signing certificate or metadata has expired or changed. This follows standard identity and access management troubleshooting practices used by major vendors such as Microsoft Entra ID, Okta, Google Workspace, and other SAML-compatible identity providers. Clearing browser data may occasionally resolve local session problems, but it is not the best first step when the failure is isolated to one federated application.
- A. Correct.
This is correct. If other applications are successfully using SSO but one specific portal is not, the most likely issue is with that application's federation configuration rather than the users' primary sign-in. For SAML-based SSO, the service provider and identity provider must have matching settings such as entity IDs, reply/ACS URLs, claims, and signing certificates. A broken or expired certificate, incorrect trust relationship, or misconfigured SAML app integration commonly causes repeated login prompts.
- B. Incorrect.
This is incorrect. Clearing browser cache and cookies may help with a local session or stale authentication issue, but the scenario points to a single application failing while other SSO-integrated applications work correctly. That pattern suggests an application federation configuration problem, not a client-side browser storage problem. This option reflects the common misconception that all repeated sign-in prompts are browser issues.
- C. Incorrect.
This is incorrect. Multifactor authentication can be part of an SSO workflow and does not inherently break SSO. Disabling MFA would reduce security and does not address the likely root cause of one SAML-integrated application failing while others continue to work. This distractor targets the misunderstanding that SSO means users should never see any additional authentication challenge.
- D. Incorrect.
This is incorrect. Resetting Windows passwords is unnecessary when users can already authenticate successfully to other SSO-enabled services. In SSO, the user signs in once to a central identity provider, and properly integrated applications rely on federated tokens rather than separate synchronized passwords. This option confuses password synchronization with federation-based SSO.