Ditch the Duplicate Logins: Let Your Team into Oracle Cloud with Their Microsoft Credentials

Introduction Of Microsoft AD with Oracle Cloud Infrastructure

If you're managing both a Microsoft Active Directory on-premises and an Oracle Cloud (OCI) tenancy, you're probably dealing with a common headache: user complaints about yet another password to remember.

What if you could fix that? What if your team could access OCI by just clicking a button and using the exact same username and password they use to log into their computers every morning?

Admin Control:

You grant and revoke access to OCI from one central place: your Active Directory. Add a user to the "OCI-Devs" AD group? They instantly get developer access in the cloud. Remove them? Their access is gone on the next login.

Stronger Security:

You leverage the security you've already built—like complex password policies and multi-factor authentication (MFA)—at your front door for your cloud environment. No more weak, separately managed cloud passwords.

Crystal-Clear Auditing:

Every OCI login is directly tied to a specific AD user. Need to know who did what for an audit? The trail is clean and undeniable.

The Simple Analogy: The Club VIP List

Think of it like this:

• Oracle Cloud (OCI) is an exclusive club.

• Your OCI admin is the club owner.

• Active Directory is your company's HR database of employees.

• AD FS is your company's trusted security team that checks IDs.

A user shows up. Check with your security team. Your team verifies their ID and says, "Yep, this is Sarah, she's in the Marketing group." The bouncer then checks your rules: "Marketing group gets access to the dance floor and the bar," and lets Sarah in accordingly. She never had to show the club a separate ID.

The Game Plan: Connecting the Dots

Phase 1: Prepare your AD

Before you touch OCI, get your own house in order.

• Pick Your Groups: Decide which AD groups should have access to OCI .

• Grab Your ID Card Template: From your AD FS server, you need to export the FederationMetadata.xml file. This file is like your company's official, verifiable ID card template that you'll show to OCI to prove who you are.

Phase 2: Tell OCI to Trust Your Company (The Handshake)

Now, go into OCI and establish the trust.

• In the OCI Console, navigate to Identity & Security > Federation.

• Click Add Identity Provider.

• Give a clear name.

• Select SAML 2.0 and upload the Metadata File.

• Click Add. Boom, trust established. OCI will now provide a link to its metadata file. Download that—you'll need it for the next step.

Phase 3: Your AD FS to Trust OCI

Now, go back to your AD FS server and complete trust.

• Open the AD FS Management console.

• Add a New Party Trust.

• Select the option to import data using the file or URL that OCI just gave you.

• Click through the wizard. You've now told AD FS that OCI is a trusted destination it can issue passes to.

Phase 4: Decide What Info to Share (The VIP Pass)

This is the crucial part. You need to write the rules for what gets written on the digital "VIP pass" (SAML token) that AD FS hands to each user. You need two main rules:

• Rule 1: The User's Name Tag (Name ID)

  • Why: This is the non-negotiable unique identifier. OCI uses it to know exactly who is logging in. No Name ID, no entry.

  • Setup: Create a rule to "Transform an Incoming Claim."

    • Incoming claim type: Windows account name

    • Outgoing claim type: Name ID

    • Outgoing format: Persistent Identifier

    • Select "Pass through all claim values"

• Rule 2: The User's Access Level (Group Claims)

  • Why: This tells OCI what permissions the user should have. Heads up: If a user is in more than 100 AD groups, OCI will reject the login. You must filter.

  • Setup: Create a rule to "Send Group Membership as a Claim."

    • Filter it! Only send groups that start with your OCI- prefix. This keeps the pass clean and avoids the 100-group limit.

Phase 5: Set Permissions in OCI (The Club Rules)

The pass is useless if the bouncer doesn't know what to do with it.

• Find your Identity Provider and click Edit Group Mappings.

• Map each relevant AD group (e.g., OCI-Platform-Admins) to a corresponding group you've created in OCI IAM (e.g., Federated-Admins).

• Write IAM Policies that grant power to these OCI groups.

Example Policy: Allow group Federated-Admins to manage all resources in tenancy
Example Policy: Allow group Federated-Devs to use virtual-network-family in compartment Project-A

Conclusion

The process for your users is now dead simple:

1. They go to https://cloud.oracle.com

2. They click on Single Sign-On.

3. They type in your Tenancy Name.

4. They get whisked away to your company's Microsoft login page.

5. They sign in normally and land right in the OCI console. Magic!