5 · Oracle Database@Azure identity and access
These are original revision notes for the identity-and-access course video. They summarize the ideas in our own words rather than reproducing the video.
Core message
Identity for Oracle Database@Azure spans two clouds, so access is split across both. Azure RBAC governs who can buy the service through the Marketplace and who manages the Azure-side service resources. OCI groups govern who manages the databases themselves inside OCI. Six groups are created in Azure: two map directly to Azure roles, and the other four carry no Azure role — they are replicated into OCI when you set up the optional identity federation.
Buying the service — Azure RBAC and Marketplace permissions
Purchasing Oracle Database@Azure goes through Azure Marketplace, and Azure RBAC decides who is allowed to do it. The service is sold as a private offer, so two distinct actions need permission: accepting the offer and purchasing or subscribing to it. The exact roles depend on the commercial agreement.
| Agreement type | Permissions to accept the private offer | Permissions to purchase or subscribe |
|---|---|---|
| Microsoft Customer Agreement (MCA) | Billing account owner or contributor | Subscription owner or contributor |
| Enterprise Agreement (EA) | Enterprise administrator | Subscription owner or contributor |
Beyond the per-user roles, the tenant's Marketplace purchase policy also has to allow paid acquisitions. It can be set to one of three values, and only the first lets users buy this service:
- Free + Paid — users can acquire both free and paid Marketplace applications (the setting needed here).
- Free — users can acquire only free Marketplace applications.
- No — users cannot acquire Marketplace applications at all.
Two Azure roles for the service
After the service is onboarded, two Azure roles control who manages the Azure-side resources. Each one is paired with a group that is created in Azure.
- Oracle Database@Azure Exadata Infrastructure Administrator — manage all Oracle Exadata Database Service resources in Azure. This is the broad, infrastructure-level role.
- Oracle Database@Azure VM Cluster Administrator — administer VM cluster resources in Azure. This is the narrower, cluster-level role.
Six groups created in Azure
Six groups are provisioned in Azure (Microsoft Entra ID). The first two are mapped to the two Azure roles above. The remaining four have no Azure role — instead they are replicated into OCI during the optional identity federation, where they receive their permissions.
| Azure group | Azure RBAC role | What the role does |
|---|---|---|
| odbaa-exa-infra-administrators | Exadata Infrastructure Administrator | Manage all Oracle Exadata Database Service resources in Azure |
| odbaa-vm-cluster-administrators | VM Cluster Administrator | Administer VM cluster resources in Azure |
| odbaa-db-family-administrators | Not applicable | Replicated into OCI during the optional identity federation |
| odbaa-db-family-readers | Not applicable | Replicated into OCI during the optional identity federation |
| odbaa-exa-cdb-administrators | Not applicable | Replicated into OCI during the optional identity federation |
| odbaa-exa-pdb-administrators | Not applicable | Replicated into OCI during the optional identity federation |
Four groups in OCI
The four federated groups land in the OCI tenancy, where they map to the database management actions. This is where database-level administration actually lives — Azure manages the service, OCI manages the databases.
| OCI group | What members can do |
|---|---|
| odbaa-db-family-administrators | Manage database family actions |
| odbaa-db-family-readers | Read database family actions |
| odbaa-exa-cdb-administrators | Manage Oracle Container Database (CDB) actions |
| odbaa-exa-pdb-administrators | Manage Oracle Pluggable Database (PDB) actions |
Customer value
- Access stays Azure-led for the parts customers expect to run in Azure — purchasing through the Marketplace and managing the service resources — using familiar Azure RBAC roles.
- The split between Azure roles and OCI groups maps cleanly onto a real division of duties: platform teams manage the Azure-side service, database teams manage the databases in OCI.
- The four database groups are created once in Azure and replicated automatically, so customers don't hand-build the same identities twice.
- Least-privilege is built into the model — readers, CDB administrators, and PDB administrators are separated rather than collapsed into one broad role.
Risks and constraints to remember
- The accept and purchase steps need different permissions, and those permissions differ between MCA and EA — confirm the right person holds the right role before the commercial step, or it stalls.
- If the Marketplace purchase policy is set to Free or No, the purchase is blocked regardless of a user's RBAC role; it must be Free + Paid.
- The four database groups only gain their permissions in OCI through the optional identity federation — skip federation and those groups do nothing useful.
- The two Azure roles cover the Azure-side service, not the databases; database administration is governed entirely by the OCI groups.
- These are platform behaviors that can change — validate current permissions, role names, and group names against Microsoft Learn before guiding a customer.
Terms to remember
- Azure RBAC and the Azure Marketplace private offer
- Accept vs. purchase or subscribe permissions
- Microsoft Customer Agreement (MCA) and Enterprise Agreement (EA)
- Billing account owner or contributor; enterprise administrator; subscription owner or contributor
- Marketplace purchase policy (Free + Paid / Free / No)
- Exadata Infrastructure Administrator and VM Cluster Administrator roles
- odbaa-exa-infra-administrators and odbaa-vm-cluster-administrators (Azure-role groups)
- odbaa-db-family-administrators, odbaa-db-family-readers, odbaa-exa-cdb-administrators, odbaa-exa-pdb-administrators (federated OCI groups)
- Optional identity federation
- Oracle Container Database (CDB) and Oracle Pluggable Database (PDB)
Think of identity in two halves. Azure controls buying and running the service: who can accept and purchase the Marketplace private offer (that depends on whether you're on an MCA or an EA), and who administers the Azure-side resources through two roles — Exadata Infrastructure Administrator and VM Cluster Administrator. OCI controls the databases: four groups created in Azure are replicated into OCI through the optional identity federation, and that's where read, database-family, container-database, and pluggable-database administration actually happen. Plan least-privilege deliberately across both halves.