Introduction
Learn about the Default identity domain, how to use several 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.
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.
Limits on Identity Domains
Each identity domain type is associated with a different set of features and object limits.
See IAM Identity Domain Types for object limits, rate limits, and meters for each identity domain type.
For a list of applicable limits and instructions for requesting a limit increase, see Service Limits. To set compartment-specific limits on a resource or resource family, administrators can use compartment quotas.
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.
Accessing the DR Region
Use these steps to confirm that the network can reach the DR region.
- Find the DR region identifier in the DR Region Pairings table, See Disaster Recovery Region Pairings.
- 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.
- 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 can't 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:
- 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.
- Users can't change their passwords. If a user is in the force password reset state, they can't reset their password and don't have access until the region outage has been mitigated.
- Users with multifactor authentication can sign-in while the identity domain is in read-only mode.
- Applications using the identity domain can authenticate and authorize. For example, a custom application can 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 |
Managing High Availability for Sign-in to the Console
Maximize High Availability for the Console by replicating identity domains in other regions. Replicating identity domains lets users sign in to the Console when the home region is unavailable.
The system detects when the home region is unavailable and redirects the sign in request to a replicated region. Users that sign in through a replicated region have only READ access to identity resources, however they can manage all workloads in that region. For example:
- Users can view or list global IAM resources, such as policies.
- Users can view or list domain resources, such as users, groups, applications, and more.
- Users can't change, update, or create identity domain resources until the home region becomes available.
- Users can manage their OCI resource in the subscribed region, such as create compute instances, access object buckets, and more.
When the home region recovers, the Console notifies the user with a message. Users can continue the using the existing session or they can sign out and then sign-in to the Console for complete access in OCI.
To enable high-availability for the Console we recommend that you subscribe to more than one region for an identity domain.
High Availability Console sign in automatically activates when:
- The home region subscribes to at least one alternate region. See Subscribing to an Infrastructure Region
- The home region is replicated by at least one alternate region. See Replicating an Identity Domain to Multiple Regions.
Tenancies created after Aug. 15 2024 support high availability for Console sign in. For all other tenancies, the planned roll out for this capability will be in phases starting Dec. 1 2024.