Suggested answer

The scope of the symptom is the diagnostic, and it points squarely at that user's data rather than at configuration. Configuration failures are democratic — they break everyone at once.

My sequence is: open Login History and find the failed attempt, because it records the specific single sign-on error and the source IP. Then look at the user record for the identifier the configuration relies on — usually the Federation ID. The recurring causes are a blank Federation ID, a duplicate value shared with another user, a case mismatch (it is treated as case-sensitive), a user who is inactive or has lost their licence, and login hours or IP ranges on the profile that happen to bite this person.

If that does not resolve it, I capture the actual assertion and run it through the SAML Assertion Validator, which tells me the subject value the identity provider is really sending — often different from what the directory team believes it is sending.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.