Home / OCI

OCIRunbookAdvanced

Sev1: administrators locked out of the OCI Console — sign-on policy, MFA or federation broken

Nobody can sign in to the OCI Console after a sign-on policy, MFA or identity provider change. Use break-glass accounts, API keys and Oracle Support to regain access, then fix the policy safely.

Deepak Bhardwaj3 min read

Applies toOCI IAM with identity domains, federation (SAML/Entra ID/Okta), OCI CLI 3.x

Symptoms

  • Users and admins get sign-in errors, endless MFA prompts, or are redirected to an identity provider that rejects them.
  • Started right after a sign-on policy change, MFA enforcement, IdP certificate rotation or federation change.
  • Running workloads are fine; only human access is broken.

1. Try your break-glass paths in order

  1. Local break-glass admin: a non-federated user in the Default identity domain, with its own MFA factor stored securely. Sign in using the identity domain's direct sign-in, not the federated button.
  2. API key access: an admin user with an API key configured for the OCI CLI is not affected by console sign-on policies.
oci iam region-subscription list   # proves API access works
oci iam domain list --compartment-id $TENANCY \
  --query 'data[].{name:"display-name", url:url, type:type}' --output table
  1. Oracle Support: if no path works, open a Sev1 service request from My Oracle Support (it uses a separate login). Have the tenancy OCID and the cloud account name ready.

Caution

Do not keep trying the same broken sign-in in a loop for the break-glass user. Repeated failures can lock that account too, removing your last working path.

2. Find what changed

With API access, look at the audit log for the last few hours:

oci audit event list --compartment-id $TENANCY \
  --start-time "$(date -u -d '-6 hours' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --query "data[?contains(\"event-type\",'identity')].{t:\"event-time\", type:\"event-type\", who:data.identity.\"principal-name\"}" \
  --output table

Identity domain changes are also recorded in the domain's own audit/reports. Typical culprits:

Change Effect
Sign-on policy rule requiring MFA for all, with no enrolled factor Everyone blocked at the MFA step
Sign-on policy rule restricting by network perimeter Sign-in only from IPs nobody is using
SAML IdP signing certificate rotated in Entra/Okta, not updated in OCI Federated sign-ins fail
Federated IdP set as the only option, local login hidden Break-glass users can't find the local sign-in

3. Fix the sign-on policy

Using the break-glass admin in the console: Identity & Security > Domains > (domain) > Security > Sign-on policies. Then:

  • Move the new restrictive rule below an allow rule for the admin group, or disable it.
  • Make sure the "Default Sign-On Policy" still lets administrators sign in with local credentials plus MFA.
  • For network perimeters, add the current admin egress IPs.

Identity domains also expose a SCIM-style REST API. Changing sign-on policies through it is possible but complex; prefer the console once one admin is in.

4. Fix federation

  • In the IdP (for example Entra ID), download the current SAML signing certificate or metadata.
  • In the OCI identity domain, edit the identity provider and import the new metadata.
  • Test with one user before announcing.

5. Re-enable MFA safely

  • Enforce MFA in stages: admins first (with a confirmed enrolment), then everyone.
  • Keep at least two break-glass users with different factor types (for example a FIDO key and a TOTP app), stored in separate safes.

Prevent it next time

  • Two documented break-glass admin accounts, excluded from the federated and restrictive policy rules, tested quarterly.
  • Change sign-on policies in a test identity domain first.
  • Track IdP certificate expiry dates and rotate in OCI the same day.
  • Keep an admin API key for a service user in a vault for emergencies.

Related fixes