Advanced Troubleshooting
Domain 3: Advanced Troubleshooting
This domain tests diagnosis with evidence: System Log queries, reports, SSO traces, provisioning errors, MFA failures, and API rate limits. Expect 'user cannot access app' scenarios where the answer is a policy, assignment, network zone, or assertion mismatch.
Core rules
- Start with the System Log. Filter by actor, target, event type, and outcome. Useful event families include
user.session.start,user.authentication.auth_via_mfa,policy.evaluate_sign_on,app.auth.saml,group.user_membership.add, and provisioning events. A failure outcome plus reason string often identifies the cause. - For SAML, check ACS URL, audience/entity ID, NameID format, signing certificate, attribute statements, and clock skew. A valid IdP metadata file does not guarantee the app's ACS URL matches.
- For OIDC, check redirect URI, client ID/secret, scopes, and claim mapping. Redirect URI mismatch is a common failure.
- For provisioning, check app credentials, SCIM endpoint, attribute mappings, and group push errors. A disabled provisioning integration looks like an assignment problem.
- For API 429 errors, inspect rate-limit headers and back off; do not retry in a tight loop.
Worked example
A user reports no app tile. Confirm group membership and app assignment. Check the app's authentication policy and network zone. Search the System Log for the user and app: if policy.evaluate_sign_on denies, fix the rule order; if app.auth.saml fails, compare the assertion's Audience and ACS URL with the app config. If no event appears, the user never reached Okta-check the IdP or bookmark.
Traps
Do not assume a missing tile means the app is down. Do not ignore group rule membership. Do not debug SAML by only checking the certificate. Do not retry 429s aggressively. Do not overlook staged users who cannot authenticate.