What breaks

Sequence first. "Nobody can sign in after the SSO change." Check in this order. One. Can you still reach the administrator sign-in route? Two. Does the username the provider asserts match what the domain expects? Three. Was the configuration tested before activation? Four. Is the identity provider itself reachable? Five. Are the affected users assigned to the application at the provider end? Six. Is a sign-on policy involved? Question one first, always — because the answer determines whether you are fixing a problem or opening a support case. Then eight cases. One. "We activated an untested configuration and locked ourselves out." The failure this module exists to prevent. Recoverable through support. Slowly. And visibly. Two. "Username mismatch." Attribute mapping. The most common single cause. Three. "Web works, Excel does not." Client testing skipped. Four. "Automation failed silently overnight." Service account authentication after the change. Five. "Sign-out does not sign out."…

In this module: Module 8 · Single Sign-On and Federation

1. 1What SSO changes
2. 2The sign-in experience under SSO
3. 3Configuring an external identity provider
4. 4Completing configuration in the console
5. 5Multiple identity providers in one domain
6. 6SSO across domains in one cloud account
7. 7SSO across different cloud accounts
8. 8Logout URL and credential management
9. 9Making clients work after SSO
10. 10What breaksFree preview
11. 11Lab: federate without locking yourself out