Authorizing Microsoft Entra ID Users for Oracle Databases on Exadata Dedicated Infrastructure

Modern enterprises increasingly require centralized identity management and seamless single sign-on (SSO) across cloud platforms. Oracle addresses this need by enabling Microsoft Entra ID (MS‑EI) integration for Oracle Databases running on Oracle Exadata Database Service on Dedicated Infrastructure.

This blog walks through how MS‑EI authentication and authorization works, key prerequisites, networking and TLS requirements, and the supported authentication flows - from a DBA and cloud architect perspective.

Why Integrate Microsoft Entra ID with Oracle Exadata?

By integrating Oracle Database with Microsoft Entra ID (formerly Azure AD), organizations can:

• Centrally manage database users and access policies in MS‑EI
• Enable SSO-based database authentication
• Eliminate local database passwords
• Use modern OAuth2 token-based authentication
• Align Oracle access controls with enterprise identity governance

This integration is supported for:

• On‑premises Oracle Databases
• Oracle Databases on OCI DBaaS platforms
• Oracle Exadata Database Service on Dedicated Infrastructure

For simplicity, we are referring to all these environments as Oracle Database.

How MS‑EI Authentication Works with Oracle Databases

At a high level, authentication works as follows:

1. Microsoft Entra ID acts as the central identity provider
2. Users or applications authenticate with MS‑EI using SSO
3. MS‑EI issues an OAuth2 access token
4. The token is sent to the Oracle Database
5. Oracle validates the token and maps it to database roles or schemas

This allows users and applications to log in without database credentials, relying entirely on MS‑EI identity and role assignments.

Application Registration and Role Mapping

To enable this integration, an administrator performs the following in Microsoft Entra ID:

1. Register the Oracle Database as an Application

• Create an app registration representing the Oracle Exadata database
• This allows Oracle to request MS‑EI public signing keys

2. Define Application Roles

• App roles are created in the MS‑EI app registration
• These roles are assigned to:
• MS‑EI users
• MS‑EI groups
• Service principals (applications)

3. Map MS‑EI Roles to Oracle Database Objects

• MS‑EI app roles map to:
• Global database schemas, or
• Global database roles

Important rules:

• A global schema can be mapped directly to an MS‑EI user
• Guest users and service principals must use app roles
• Global database roles can only be mapped via MS‑EI app roles

Supported MS‑EI Authentication Flows

Oracle Exadata Database Service supports multiple Microsoft Entra ID OAuth2 flows:

Interactive Flow (Authorization Code)

• Used when a browser is available
• Supports MFA
• Common for human users

Client Credentials Flow

• Application authenticates as itself
• Ideal for connection pools and background services

 On-Behalf-Of (OBO) Flow

• Application requests a token on behalf of a logged-in user
• Useful for middle-tier applications

ROPC (Username/Password)

• Supported only for test and development
• Not recommended for production

Supported MS‑EI Principals

Oracle Database accepts tokens issued for:

• MS‑EI users (native directory users)
• Guest users
• Service principals (application identities)

Token Handling and Security Considerations

• MS‑EI issues OAuth2 bearer tokens with expiration
• Tokens are scoped specifically for database access
• Assigned app roles are embedded into the token
• Database client drivers validate token format and expiry

Using Tokens with Database Tools

Existing tools such as SQL*Plus can be configured to:

• Read tokens from a secure file location
• Or retrieve tokens directly from MS‑EI

Tokens can be retrieved using:

• Azure CLI
• Microsoft PowerShell

File System Security

Because tokens grant database access:

• Token files must be tightly secured
• Only minimal read/write permissions should exist
• Avoid shared or world-readable directories

Prerequisites for MS‑EI Authentication

Before configuring MS‑EI integration, ensure the following:

Database Requirements

• Oracle Database 19.18 or later
• TLS-only connectivity (port 2484)
• Database registered with MS‑EI

Network Requirements

• Outbound connectivity from database to MS‑EI
• Ability to fetch MS‑EI public keys
• Proxy configuration if required

Note:
On Exadata Dedicated Infrastructure, proxy and network settings can only be updated before activation. After activation, changes require a Service Request (SR) with Oracle Support.

Networking Configuration in OCI

To allow MS‑EI authentication, configure the following in OCI:

1. Create a Service Gateway

• Enable private connectivity from the VCN to external services

2. Configure Route Rules

For each database subnet:

• Destination: 0.0.0.0/0
• Target Type: NAT Gateway

3. Configure Egress Security Rules

Allow outbound HTTPS:

• Protocol: TCP
• Source Port: 443
• Destination: 0.0.0.0/0

These settings allow the database to securely communicate with MS‑EI endpoints.

TLS Configuration for MS‑EI Tokens

A TLS connection is mandatory when passing MS‑EI tokens from the client to the database.

Wallet Location

The TLS wallet must be stored under:

WALLET_ROOT/<PDB_GUID>/tls

TLS Configuration Options

Certificate Choices

• Self-signed certificates
• Free and common for internal use
• Root certificate must be trusted by clients
• CA-signed certificates
• Easier for clients
• Usually involves cost

TLS Modes

• One-way TLS
• Server presents certificate
• No client certificate required
• Mutual TLS (mTLS)
• Both client and server authenticate
• Optional for MS‑EI but supported

Client Wallet Options

• Client wallet required for mTLS
• Optional for one-way TLS if root certificate is trusted

Final Thoughts

Integrating Microsoft Entra ID with Oracle Exadata Database Service on Dedicated Infrastructure delivers a modern, secure, and scalable authentication framework. It enables centralized identity governance, OAuth2 token-based access, and seamless SSO aligning Oracle databases with enterprise cloud identity standards.

For organizations running hybrid or multi-cloud architectures, this integration significantly enhances security posture, operational simplicity, and user experience.