Introduction

Learn about the Default identity domain, how to use multiple domains, disaster recovery and domains, and more.

The introduction contains the following topics:

The Default Identity Domain

Each tenancy includes a Default identity domain in the root compartment.

A Default identity domain:

  • Can't be deactivated or deleted. (Lives with the life cycle of the tenancy.)
  • Can't be hidden from the sign-in page.

The Default identity domain contains the initial tenant Administrator user and Administrators group and a default policy that allows administrators to manage any resource in the tenancy. The Administrators policy and the Administrators group can't be deleted and there must be at least one user in the Administrators group. You can also assign user accounts to predefined administrator roles to delegate administrative responsibilities it the Default domain.

Note

Granting users or groups the identity domain administrator role for domains other than the default domain grants them full administrator permissions to only that domain (not to the tenancy). At least one administrator for the identity domain must be granted the identity domain administrator role directly. This is in addition to any identity domain administrator roles granted by group membership. For more information, see Understanding Administrator Roles.

You can upgrade a domain by changing the domain type. Each identity domain type  is associated with a different set of features and object limits. For information to help you decide which domain type is appropriate for what you want to do, see IAM Identity Domain Types.

Using Multiple Identity Domains

Create and manage multiple identity domains (for example, one domain for development and one for production) each with different identity and security requirements to protect your applications and Oracle Cloud services.

Using multiple identity domains can help you maintain the isolation of administrative control over each identity domain. This is necessary if, for example, security standards prevent development user IDs from existing in the production environment, or require that different administrators have control over different environments.

Each tenancy contains a Default identity domain, the identity domain which comes with your tenancy. Administrators can create as many additional identity domains as their license allows. Administrators can:

  • Create additional identity domains and be the identity domain administrator for them or assign another user to be the administrator.
  • Create additional identity domains and, as part of the identity domain creation process, assign users to be identity domain administrators of the identity domains.
  • Delegate the creation of additional identity domains to other administrators.

An identity domain administrator is assigned to an identity domain during the creation of the identity domain. Although the identity domain administrator identity might have the same username as a user in the Default identity domain, they're different users who might have different privileges in each identity domain, and will have separate passwords.

The identity domain administrator can use the entire feature set of the identity domain. In an identity domain, the identity domain administrator can:

  • Manage users, groups, applications, system configuration, and security settings.
  • Perform delegated administration by assigning users to different administrative roles.
  • Enable and disable Multifactor Authentication (MFA), configure MFA settings, and configure authentication factors.
  • Create self-registration profiles to manage different sets of users, approval policies, and applications.

Recovering Domains

Administrators can't recover a deleted identity domain. See Getting Help and Contacting Support to contact Oracle support to recover a deleted identity domain.

Disaster Recovery and Identity Domains

A disaster can be any event that puts applications at risk, for example failures caused by natural disasters. In regions with cross-region disaster recovery (DR) enabled, identity domains have built-in cross-region DR to minimize data loss. Data for a region is replicated to a nearby region in the event of a disaster. If an entire OCI region becomes unavailable, traffic is routed to the disaster recovery region to speed service recovery and retain as much data as possible. Oracle pairs regions with disaster recovery (DR) regions for you.

See Learn about protecting your cloud topology against disasters to learn more about DR in Oracle Cloud Infrastructure.

If a region outage occurs, the identity domain will experience a brief outage and then recover. After recovered to the DR region:

  • Users in the identity domain are authenticated and authorized as usual.
  • Identity domain URLs don't change. No changes are needed for any applications.
  • Failed-over identity domains don't replicate to replicated regions.
  • Identity domains replicated to other regions might not be in sync with the DR region. For example, any changes to users, groups, and domain settings might not be reflected in the DR region. Inconsistencies are resolved when the identity domain fails back.

Using the Console During Failover

You might not have access to the Console during failover. During this time, you might be able to use the CLI and SDK for both IAM and identity domains to manage identity configurations.

The Console is available if the identity domain home region is available or if the unavailable region isn't the tenancy home region.

The Console isn't available the identity domain home region is unavailable or if the tenancy home region is unavailable.

Accessing the DR Region

Use these steps to confirm that the network can reach the DR region.

  1. Find the DR region identifier in the DR Region Pairings table, See Disaster Recovery Region Pairings.
  2. Use the DR region identifier to look up the public IP addresses assigned to the region. See Public IP Addresses for VCNs and the Oracle Services Network.
  3. Add those public IP addresses to your firewalls to allow traffic from that DR region.

Read-only Failover and Identity Domains

If a region outage occurs, OCI might initiate a failover of that region's identity domains (and IDCS stripes) to a failover region which restores access to those identity domains (and IDCS stripes) in a read-only access mode. Check the outage information for when the region-outage state is enabled & disabled.

If a home region is unavailable, users will not be able to access the OCI Console in any region, even if the identity domains have failed over. CLI and SDK access to regions other than the home region is available.

In read-only access mode:

  1. Resources can't be updated. No updates to any identity domain (or IDCS stripe) resources are allowed. For example, users can't update or delete users, applications, groups, or domain settings. Users have read permissions to all resources.
  2. Users can't change their passwords. If a user is in the force password reset state, they can't reset their password and will not have access until the region outage has been mitigated.
  3. Users with multifactor authentication can sign-in while the identity domain is in read-only mode.
  4. Applications using the identity domain will be able to authenticate and authorize. For example, a custom application will be able to authenticate and authorize calls using the identity domain while in read-only mode.

Disaster Recovery Region Pairings

Use the following table to find the DR region pairings in the Oracle Cloud Infrastructure commercial realm:

See Oracle Cloud Regions—Data Centers for information about available regions.

Region Name Region Identifier Region Location Disaster Recovery Region Name Disaster Recovery Region Identifier
Australia East (Sydney) ap-sydney-1 Sydney, Australia Australia Southeast (Melbourne) ap-melbourne-1
Australia Southeast (Melbourne) ap-melbourne-1 Melbourne, Australia Australia East (Sydney) ap-sydney-1
Brazil East (Sao Paulo) sa-saopaulo-1 Sao Paulo, Brazil Brazil Southeast (Vinhedo) sa-vinhedo-1
Brazil Southeast (Vinhedo) sa-vinhedo-1 Vinhedo, Brazil Brazil East (Sao Paulo) sa-saopaulo-1
Canada Southeast (Montreal) ca-montreal-1 Montreal, Canada Canada Southeast (Toronto) ca-toronto-1
Canada Southeast (Toronto) ca-toronto-1 Toronto, Canada Canada Southeast (Montreal) ca-montreal-1
Germany Central (Frankfurt) eu-frankfurt-1 Frankfurt, Germany Netherlands Northwest (Amsterdam) eu-amsterdam-1
Netherlands Northwest (Amsterdam) eu-amsterdam-1 Amsterdam, Netherlands Germany Central (Frankfurt) eu-frankfurt-1
India South (Hyderabad) ap-hyderabad-1 Hyderabad, India India West (Mumbai) ap-mumbai-1
India West (Mumbai) ap-mumbai-1 Mumbai, India India South (Hyderabad) ap-hyderabad-1
Italy Northwest (Milan) eu-milan-1 Milan, Italy France South (Marseille) eu-marseille-1
Japan Central (Osaka) ap-osaka-1 Osaka, Japan Japan East (Tokyo) ap-tokyo-1
Japan East (Tokyo) ap-tokyo-1 Tokyo, Japan Japan Central (Osaka) ap-osaka-1
South Korea Central (Seoul) ap-seoul-1 Seoul, South Korea South Korea North (Chuncheon) ap-chuncheon-1
South Korea North (Chuncheon) ap-chuncheon-1 Chuncheon, South Korea South Korea Central (Seoul) ap-seoul-1
Switzerland North (Zurich) eu-zurich-1 Zurich, Switzerland Germany Central (Frankfurt) eu-frankfurt-1
UAE Central (Abu Dhabi) me-abudhabi-1 Abu Dhabi, UAE UAE East (Dubai) me-dubai-1
UAE East (Dubai) me-dubai-1 Dubai, UAE UAE Central (Abu Dhabi) me-abudhabi-1
UK South (London) uk-london-1 London, United Kingdom UK West (Newport) uk-cardiff-1
UK West (Newport) uk-cardiff-1 Newport, United Kingdom UK South (London) uk-london-1
US East (Ashburn) us-ashburn-1 Ashburn, VA US West (Phoenix) us-phoenix-1
US West (Phoenix) us-phoenix-1 Phoenix, AZ US East (Ashburn) us-ashburn-1
US West (San Jose) us-sanjose-1 San Jose, CA US West (Phoenix) us-phoenix-1