DatabaseVerse: Journey into the World of Databases

If you manage several Oracle GoldenGate deployments, local users eventually become one more thing to maintain.

• Create the user here.
• Create it again in another deployment.
• Give it the correct role.
• Remember to remove it everywhere when access is no longer required.

And hopefully nobody has documented the password in a TXT file, Excel spreadsheet, or some other wonderfully insecure place. (I know someone reading this has done it. Don’t lie to me ;D )

Fortunately, Oracle GoldenGate Microservices can delegate authentication to an external Identity Provider, including Microsoft Entra ID.

I had wanted to document this integration for a while, especially after running into a few Entra ID-related authentication issues in a real production environment.

The tricky part in that kind of environment is that GoldenGate and Entra ID are usually managed by different teams. As the GoldenGate guy, you don’t necessarily have access to the Entra ID side, so troubleshooting sometimes becomes a conversation of “can you check this?” followed by “looks fine from our side.”

So instead of simply following the Oracle documentation and stopping when the login worked, I created my own Entra ID lab to see how the whole thing fits together.

And, more importantly, what happens when one of the pieces doesn’t.

In this article, we’ll configure the integration from scratch, test the GoldenGate role mappings, and then deliberately break a few things.

Because getting a nice green SUCCESS from the OGG Authorization Profile validation isn’t enough. Trust me.

An error you already know how to troubleshoot is probably more useful.

What Are We Actually Configuring?

Oracle GoldenGate has four main authorization roles:

• Security
• Administrator
• Operator
• User

For this implementation, we’ll create four Entra ID security groups and map them to the corresponding GoldenGate roles.

For example:

Microsoft Entra ID                Oracle GoldenGate
OGG_Security          --------->  Security
OGG_Administrator     --------->  Administrator
OGG_Operator          --------->  Operator
OGG_User              --------->  User

A user authenticates through Entra ID, and GoldenGate uses the group information returned for that user to determine what they are allowed to do.

That distinction will become useful later when we start troubleshooting. A user can successfully authenticate and still end up with the wrong GoldenGate permissions.

For now, let’s build it.

My Lab

For this test I am using:

• Oracle GoldenGate 26ai Microservices Architecture running in containers (using my own image, but that’s a story for another article)
• Microsoft Entra ID
• A dedicated Entra ID application for GoldenGate
• Four test users
• Four security groups

My GoldenGate deployment isn’t running in Azure btw, and it doesn’t need to be. It simply needs secure connectivity to the Microsoft endpoints involved in the authentication flow.

Conceptually, our lab looks like this:

+---------------------------+
| Microsoft Azure           |
|                           |
| Microsoft Entra ID        |
| - Users                   |
| - Groups                  |
| - App Registration        |
+-------------+-------------+
              |
              | HTTPS / OpenID Connect
              |
              v
+---------------------------+
| Oracle GoldenGate 26ai    |
|                           |
| Authorization Profile     |
| GoldenGate Deployment     |
+---------------------------+

Nothing particularly strange so far.

Creating the Entra ID Groups

Let’s start with the easy part. I created four security groups:

OGG_Security
OGG_Administrator
OGG_Operator
OGG_User

I also created four test accounts so I can assign each one to a group

For example:

ogg.security@databaseverse.onmicrosoft.com
    -> OGG_Security
    
ogg.admin@databaseverse.onmicrosoft.com
    -> OGG_Administrator
ogg.operator@databaseverse.onmicrosoft.com
    -> OGG_Operator
ogg.user@databaseverse.onmicrosoft.com
    -> OGG_User

Using several users isn’t strictly required, but it makes the final test much more useful.

I don’t only want to prove that Entra ID lets me log into GoldenGate.

I also want to prove that ogg.user cannot suddenly do things it shouldn’t be allowed to do.

That would be a slightly more exciting result than we are aiming for.

Creating the GoldenGate Application

Now we need an Entra ID application representing GoldenGate.

Go to: Enterprise applications → New application → Create your own application

Select: Register an application to integrate with Microsoft Entra ID

For this lab, I am creating a single-tenant application called:

OracleGoldenGate

Now, let’s move to Enterprise applications → OracleGoldenGate → Users and groups

and assign the four groups created earlier.

That last part matters.

Creating a group and assigning a user to it does not automatically make that group part of this application.

Client ID, Tenant ID and Client Secret

Next, open: Microsoft Entra ID → App registrations → OracleGoldenGate

From the overview page, we need:

• Application (client) ID
• Directory (tenant) ID

The Tenant ID will later be used in the OpenID Connect Discovery URI:

https://login.microsoftonline.com/<TENANT_ID>/v2.0/.well-known/openid-configuration

We’ll use that when configuring GoldenGate.

Now create a client secret from:

Certificates & secrets → Client secrets → New client secret

Copy the Value.

Not the Secret ID.

Also make a note of the expiration date, especially if this is a real environment.

This secret is going to become one of those things that everybody forgets exists until the day it expires, so we’ll come back to it in the operational section.

Configuring the Group Claim

GoldenGate needs Entra ID to include the user’s application groups in the token.

Go to: Token configuration → Add groups claim

and select: Groups assigned to the application

Now the groups we assigned earlier can be returned as part of the authentication flow and later mapped to GoldenGate roles.

At this point we have:

User
  |
  v
Entra ID
  |
  +--> Application Groups
  |
  v
Token
  |
  v
GoldenGate Role Mapping

That is really the important idea behind the integration.

Creating the GoldenGate Service Application Role

GoldenGate also requires an application role for service-to-service authorization.

Go to: App registrations → OracleGoldenGate → App roles → Create app role and configure:

Allowed member types: Applications
Value: urn:ogg:serviceToService

Then go to: API permissions → Add a permission → APIs my organization uses

Select the GoldenGate application and add:

urn:ogg:serviceToService

under Application permissions.

Grant Admin consent.

Microsoft Graph Permissions

Now comes one of the more interesting parts.

Oracle’s current documentation instructs us to add this Microsoft Graph application permission:

Application.ReadWrite.All

Go to:

APP Registration → API permissions → Add a permission → Microsoft Graph → Application permissions

Search for it, add it, and grant Admin consent.

If we are simply following the documentation, we could move on now.

But this permission deserves a closer look.

Do We Really Need Application.ReadWrite.All?

Application.ReadWrite.All is a powerful permission.

And in a real corporate environment, asking the Entra ID team for it will probably result in a reasonable question:

Why does GoldenGate need write access to all applications?

That question came up during a real implementation.

During troubleshooting with Oracle Support, Application.Read.All was discussed as sufficient for this use case.

That’s quite a difference. Application.ReadWrite.All allows the application to read and write application objects, while Application.Read.All is read-only.

Rather than treating either answer as gospel, I’m going to test it.

First we’ll make the integration work exactly as documented.

Then we’ll replace the Graph permission with the more restrictive one from the SR and verify:

• Authorization Profile validation
• Entra ID login
• Group-to-role mapping

That should tell us what GoldenGate actually requires in practice.

And if a less privileged permission works, that is considerably more useful than simply saying “the documentation says so.”

Updating the Application Manifest

There are also a few changes required in the Application Manifest.

Go to: App registrations → OracleGoldenGate → Manifest

Oracle requires cloud_displayname in the optional claims for:

accessToken
idToken
saml2Token

and the requested access token version must be:

2

I normally take a copy of the manifest before editing it. Anyway, let’s make the changes.

Save the changes when you’re done.

Configuring the Redirect URI

If Application Authentication is used, we also need a redirect URI.

Go to: App registrations → OracleGoldenGate → Authentication → Add a platform → Web

The GoldenGate callback path is:

/services/v2/authorization

For example:

https://goldengate.example.com/services/v2/authorization

The important part is that this URI must match the address involved in the actual browser authentication flow.

That matters especially when GoldenGate sits behind a reverse proxy.

For example:

Browser
   |
   | https://ogg.example.com
   v
NGINX
   |
   | https://ogg01.internal:9011
   v
GoldenGate

The browser knows ogg.example.com.

GoldenGate may know itself as ogg01.internal:9011.

Entra ID only cares that the redirect URI is the one it expects.

For the Service Manager deployment, you should add the path /services/v2/authorization for the Service Manager.

For each Microservices deployment, you also need the callback path for the Administration Service. If you’re using a reverse proxy like I am, it will look something like this: /services/<DEPLOYMENT_NAME>/adminsrvr/v2/authorization

GoldenGate Must Trust the Microsoft Certificates

We’re almost ready to configure GoldenGate. Almost.

Because first GoldenGate needs to trust the TLS certificate chain used by the Microsoft endpoints.

Oracle’s documentation says to download the Azure Root CA certificates. My immediate question was the obvious one: which one?

Microsoft’s CA page contains a rather impressive collection of certificates, but fortunately Oracle gives us an important clue: Root Certificate Authorities only. At the time of writing, Microsoft lists seven certificates in that section. The subordinate CAs listed further down the page are not required for this step.

I downloaded the root certificates, converted them from CRT to PEM with OpenSSL, and imported them as trusted CA certificates in the GoldenGate Service Manager.

Not particularly exciting, but certificate problems have an unfortunate habit of becoming exciting later.

openssl x509 \
  -in <certificate>.crt \
  -out <certificate>.pem \
  -outform pem

So you can do something like this:

Create a working directory:

mkdir -p ~/azure-root-ca
cd ~/azure-root-ca  

Download the seven root CAs

curl -LO https://cacerts.digicert.com/DigiCertGlobalRootCA.crt
curl -LO https://cacerts.digicert.com/DigiCertGlobalRootG2.crt
curl -LO https://cacerts.digicert.com/DigiCertGlobalRootG3.crt
curl -LO https://cacerts.digicert.com/DigiCertTLSECCP384RootG5.crt
curl -LO https://cacerts.digicert.com/DigiCertTLSRSA4096RootG5.crt
curl -L \
  'https://www.microsoft.com/pkiops/certs/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crt' \
  -o MicrosoftECCRootCertificateAuthority2017.crt
curl -L \
  'https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt' \
  -o MicrosoftRSARootCertificateAuthority2017.crt

Convert them to PEM

openssl x509 \
  -in DigiCertGlobalRootCA.crt \
  -out DigiCertGlobalRootCA.pem \
  -outform PEM
openssl x509 \
  -in DigiCertGlobalRootG2.crt \
  -out DigiCertGlobalRootG2.pem \
  -outform PEM
openssl x509 \
  -in DigiCertGlobalRootG3.crt \
  -out DigiCertGlobalRootG3.pem \
  -outform PEM
openssl x509 \
  -in DigiCertTLSECCP384RootG5.crt \
  -out DigiCertTLSECCP384RootG5.pem \
  -outform PEM
openssl x509 \
  -in DigiCertTLSRSA4096RootG5.crt \
  -out DigiCertTLSRSA4096RootG5.pem \
  -outform PEM
openssl x509 \
  -in MicrosoftECCRootCertificateAuthority2017.crt \
  -out MicrosoftECCRootCertificateAuthority2017.pem \
  -outform PEM
openssl x509 \
  -in MicrosoftRSARootCertificateAuthority2017.crt \
  -out MicrosoftRSARootCertificateAuthority2017.pem \
  -outform PEM

You should have:

ls -lrt *.pem
-rw-r--r--@ 1 fsarcos  staff  1338 Aug 21 17:24 DigiCertGlobalRootCA.pem
-rw-r--r--@ 1 fsarcos  staff  1294 Aug 21 17:24 DigiCertGlobalRootG2.pem
-rw-r--r--@ 1 fsarcos  staff   839 Aug 21 17:24 DigiCertGlobalRootG3.pem
-rw-r--r--@ 1 fsarcos  staff   790 Aug 21 17:24 DigiCertTLSECCP384RootG5.pem
-rw-r--r--@ 1 fsarcos  staff  1931 Aug 21 17:24 DigiCertTLSRSA4096RootG5.pem
-rw-r--r--@ 1 fsarcos  staff   875 Aug 21 17:24 MicrosoftECCRootCertificateAuthority2017.pem
-rw-r--r--@ 1 fsarcos  staff  2021 Aug 21 17:24 MicrosoftRSARootCertificateAuthority2017.pem

Then from Service Manager:

Certificate Management → CA Certificates → + and upload the certificate and configure it as Shared.

This is one of those small prerequisites that is easy to forget because it isn’t part of the Entra ID application itself.

But if this piece is wrong, GoldenGate won’t even get far enough for your beautifully configured Graph permissions to matter.

Creating the GoldenGate Authorization Profile

Now we finally have what GoldenGate needs.

From Service Manager, go to: Authorization Profile → + and select: Microsoft Entra ID

Configure the profile with:

Tenant Discovery URI

https://login.microsoftonline.com/<TENANT_ID>/v2.0/.well-known/openid-configuration

Client ID

Use the Application (client) ID.

Client Secret

Use the secret Value.

Group Mapping

Security       -> OGG_Security
Administrator  -> OGG_Administrator
Operator       -> OGG_Operator
User           -> OGG_User

The group values are case-sensitive, so this:

OGG_Administrator

and this:

ogg_administrator

are not equivalent. Remember that one.

We’ll make use of it later.

Validate First, Enable Later

GoldenGate gives us the option to enable the profile immediately.

I wouldn’t. First, validate it.

If everything is correct, GoldenGate should report that the validation succeeded.

Only then enable the Authorization Profile.

This is one of the few times where clicking the green button first is actually the sensible option.

One thing I noticed during testing is that the behavior isn’t exactly the same everywhere.

When I enabled the profile in Service Manager, I could use it immediately. For the individual deployments, however, I had to restart them before the change took effect.

So if you’re doing this on a deployment with running processes, plan accordingly. Don’t discover the restart requirement with Extracts and Replicats happily running.

Important: Once the external Authorization Profile becomes the default, you won’t be able to log in using the local user anymore.

There is a way back if you lock yourself out. We’ll deliberately do that later too.

Can We Actually Log In?

Now let’s test it.

Log out and authenticate using the Entra ID test account assigned to:

OGG_User

Great.

But the login itself isn’t our final test.

Let’s try an operation this user should not be allowed to perform.

This user is read-only, so I shouldn’t be able to stop or start a deployment. And, as expected, those options aren’t even available:

Good.

One important detail here: so far, I have enabled the Authorization Profile only in Service Manager.

If I try to access the GoldenGate deployment itself, I’m still presented with the local login screen.

In other words, enabling external authentication in Service Manager does not automatically enable it for every deployment. You need to configure and enable it where you actually want to use it.

So keep in mind that you need to enable it in Service Manager for administration purposes and separately in every deployment where you want to use it. The configuration isn’t shared.

Now repeat the test with:

OGG_Security

This account should have the corresponding superpowers.

Now I am happier.

We have demonstrated that:

Authentication works.
Authorization works.

That tells us considerably more than simply seeing the Authorization Profile marked as enabled.

Everything Works. Let’s Break It.

At this point the integration is working.

Which makes it the perfect time to start changing things.

There are several failure modes worth understanding, especially because the error shown in GoldenGate doesn’t always tell you which layer is actually responsible.

Failure #1: Microsoft Graph Permissions

Let’s start by removing the expected Microsoft Graph permission or removing Admin consent.

Now validate the Authorization Profile again.

Severity:
INFO
Title:
Could not get Application information from Identity Provider for profile 'entraID' in deployment 'ServiceManager'.
Cause:
Request to IDP for application information could not be completed.
Action:
Check logs for further information.

In the Service Manager log we can see something like this as well:

What Happened?

The important detail here is that GoldenGate is not only checking whether it can reach Entra ID.

As part of the Authorization Profile validation, GoldenGate queries Microsoft Graph to retrieve information about the Entra ID application. That is why a Microsoft Graph application permission is required in the first place.

Because this is an Application permission, GoldenGate is accessing Microsoft Graph as the application itself, without a signed-in user. These permissions require Admin consent in Entra ID.

Without that consent, GoldenGate can still reach the tenant and the OpenID Connect discovery endpoint, but it cannot retrieve the application information it needs from Microsoft Graph. That explains the error we saw:

Could not get Application information from Identity Provider

So the Graph permission and its Admin consent are not just there to make Entra ID happy. They are actually used by GoldenGate during the Authorization Profile validation.

But there is still another question: does GoldenGate really need write access to application objects?

Now let’s repeat the test with the more restrictive permission discussed in the Oracle SR. I’ll replace Application.ReadWrite.All with Application.Read.All, grant Admin consent again, and run the same validation.

Let’s try the validation again!

And it works.

The Authorization Profile validates successfully with Application.Read.All. More importantly, we’ll also verify that authentication and role mapping continue to work.

At least for the configuration tested here, GoldenGate doesn’t need Application.ReadWrite.All. The read-only Application.Read.All permission is sufficient.

Failure #2: Certificate Trust

Next, let’s remove the Microsoft root CA certificates from GoldenGate and validate again.

Messages
Severity:
INFO
Title:
The Identity Provider described by profile 'entraID' in deployment 'ServiceManager' presented a server certificate that failed validation.
Cause:
The server certificate presented by the Identity Provider failed validation. The specified URI might be incorect or the certificate chain provided by the Identity Provider did not contain any trusted CA certificate.
Action:
Check that the specified URI is correct and upload at least one Certificate Authority certificate from the Identity Provider''s certificate chain to the shared truststore.
Severity:
ERROR
Title:
The remote peer submitted a certificate that failed validation.
Cause:
Certificate validation failed.
Action:
Review the accompanying messages for additional details.
Severity:
ERROR
Title:
Invalid certificate details: Server Peer submitted Invalid Certificate: Server Peer certificate info - Version: NZTTVERSION_X509v3 Issuer Name: CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US Subject Name: CN=stamp2.login.microsoftonline.com,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US Serial Number: 01:80:a4:a4:1a:88:3a:0a:57:c5:70:76:ea:e3:0b:4c Valid From: 14-08-2026 00:00:00Z Valid To: 22-11-2026 23:59:59Z List of trusted certificates:
Cause:
The certificate failed one or more verification actions.
Action:
Review the accompanying messages for additional details and consult the provided details to determine the cause or causes of the verification failures.

This may look like an identity problem, but we haven’t even reached authentication yet.

The TLS connection itself cannot be trusted.

Before changing anything in Entra ID, test the discovery endpoint from the GoldenGate environment:

curl -v \
https://login.microsoftonline.com/<TENANT_ID>/v2.0/.well-known/openid-configuration

You can also inspect the certificate chain:

openssl s_client \
-connect login.microsoftonline.com:443 \
-showcerts

For this kind of problem, my troubleshooting order is simple:

Can GoldenGate reach Microsoft?

If yes, does it trust Microsoft?

Only then do I start changing authentication settings.

That order can save a surprising amount of time.

Failure #3: Wrong Group Mapping

Now let’s make the group mapping slightly wrong.

Change:

OGG_User

to:

ogg_user

and authenticate again.

Interesting. Instead of getting into GoldenGate, I end up back in the authentication flow.

At first glance, this looks like an Entra ID authentication problem. But the Service Manager log tells a different story:

2026-08-26T09:28:49.646+0000 INFO | Got a response with status '200'. (Thread 12)
2026-08-26T09:28:49.646+0000 INFO | Highest role for user is 'Any'. (Thread 12)
2026-08-26T09:28:49.646+0000 ERROR| Invalid or incorrect Auth Code received (Thread 12)

Entra ID has authenticated the user. The problem is what happens afterward.

GoldenGate receives the identity, but because ogg_user doesn’t match the configured Entra ID group OGG_User, it cannot map the user to the expected GoldenGate role.

This is exactly why “I can authenticate with Entra ID” and “my GoldenGate authorization is configured correctly” are not the same thing.

If users authenticate but have unexpected privileges, check:

• Entra ID group membership
• Enterprise Application assignment
• Group claims
• GoldenGate role mappings
• Case differences

Failure #4: Redirect URI Mismatch

Let’s make another small change.

Suppose users access GoldenGate through:

https://ogg.example.com

but Entra ID contains:

https://ogg01.internal:9011/services/v2/authorization

instead of:

https://ogg.example.com/services/v2/authorization

Sorry, but we’re having trouble signing you in.
AADSTS50011: The redirect URI 'https://ogg-lab.database-verse.com/services/v2/authorization' specified in the request does not match the redirect URIs configured for the application 'xxxx'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

This is particularly easy to encounter when GoldenGate sits behind NGINX, a load balancer or another reverse proxy.

The important thing is to follow the URL used by the browser authentication flow, not simply the address GoldenGate uses internally.

Failure #5: Client Secret Expiration

This failure probably won’t happen today, but we can delete the secret to simulate it.

Which is exactly why it deserves mentioning.

The client secret has an expiration date.

The project finishes.

Everything works.

Months pass.

Then authentication suddenly stops. It should probably look something like this:

Messages
Severity:
INFO
Title:
Using Authorization Profile 'entraID' from deployment 'ServiceManager', the request to obtain an access token from the Identity Provider failed.
Cause:
As part of the connection and configuration test, a request was made to the Identity Provider to obtain an access token. This request failed.
Action:
Some possible ways to resolve this are: - Confirm that the Authorization Profile''s information about the client application is correct (client id, client secret, and/or identity domain). - Contact your Identity Provider administrator to make sure the application is enabled and configured correctly. - Check accompanying messages for more information.

If that happens, check:

App registrations → OracleGoldenGate → Certificates & secrets

If the secret has expired, create a new one and update the GoldenGate Authorization Profile with the new Value.

This is probably also a good moment to discover whether anybody documented who owns the secret rotation.

Hopefully the answer isn’t “the person who left six months ago.”

Failure #6: A User Belongs to More Than One Group

Oh yes, this can happen. Let’s see what GoldenGate does.

I’ve added ogg_security to both OGG_Security and OGG_User. Let’s see which one wins.

2026-08-26T09:43:56.586+0000 INFO | Sending Authorization Token Request. (Thread 9)
2026-08-26T09:43:56.586+0000 INFO | Sending request to URI 'https://login.microsoftonline.com/xxx/oauth2/v2.0/token'. (Thread 9)
2026-08-26T09:43:57.064+0000 INFO | Got a response with status '200'. (Thread 9)
2026-08-26T09:43:57.072+0000 INFO | Highest role for user is 'Security'. (Thread 9)

There we have it. GoldenGate selects the highest role associated with the user’s group memberships.

That’s convenient, but it’s also something to be very careful with. If somebody who is supposed to have only the User role is accidentally added to OGG_Security as well, GoldenGate isn’t going to average the permissions and meet you somewhere in the middle. That user gets Security.

Failure #7: The Authorization Profile Is Enabled… and Now It’s Broken

And this one actually happened to me.

Some changes were made on the Entra ID side and suddenly the integration stopped working. The external Authorization Profile was still the default, which meant I couldn’t simply log in with the local GoldenGate account and fix it from the UI.

So… how do you disable the Authorization Profile when the Authorization Profile is the thing preventing you from logging in?

One recovery option is to modify global.dat. Before touching it, stop the relevant GoldenGate services and take a backup of the file. This is not the place for adventurous editing.

You will find that file here:

• $SERVICE_MANAGER_HOME/var/lib/conf/global.dat
• $OGG_DEPLOYMENT_HOME/var/lib/conf/global.dat

Here’s an example:

With the services stopped, change isDefault to false for the Entra ID Authorization Profile and set it to true for the local credentials profile. Then start the services again.

And we’re back to the local login:

A Few Things I Would Plan for Production

Once the lab works, there are a few operational details I wouldn’t leave to chance.

Client Secret Rotation

Document:

• Who owns the secret
• When it expires
• How it will be rotated
• Where GoldenGate must be updated
• How authentication will be tested afterward

“Future us will remember” remains an unreliable strategy.

Treat Entra ID Groups as Privileged Access

As the multiple-group test showed earlier, group membership is privilege assignment. Treat changes to these groups the same way you would treat changes to privileged GoldenGate accounts.

OGG_Administrator

Adding someone to OGG_Administrator is effectively granting them GoldenGate administrative privileges.

The Entra ID group is now part of your GoldenGate security model.

Treat it accordingly.

External Authentication Adds Dependencies

Your login now depends on more than GoldenGate itself.

Network connectivity, DNS, TLS trust, Entra ID, application configuration and the GoldenGate Authorization Profile all participate in the authentication path.

That is not necessarily a problem, but it matters when something breaks.

Have an Emergency Access Strategy

Before enabling external authentication in production, think about what happens if Entra ID is unreachable or the configuration is broken.

The wrong moment to ask:

How do we log into GoldenGate now?

is after you have already locked yourself out.

How that emergency access should be implemented depends on your organization’s security policies, but it should definitely be decided beforehand.

How I Would Troubleshoot This

After working through the configuration and failures, this is the order I would follow:

Can GoldenGate resolve and reach Entra ID?
              |
              v
Does TLS validation work?
              |
              v
Does the OpenID discovery endpoint respond?
              |
              v
Are Client ID and Client Secret correct?
              |
              v
Are the required permissions configured?
              |
              v
Was Admin consent granted?
              |
              v
Does the Authorization Profile validate?
              |
              v
Can the user authenticate?
              |
              v
Does the user receive the expected OGG role?

The important part is troubleshooting from the bottom of the stack upward.

If HTTPS is broken, there is little value in spending an hour changing group mappings.

And changing several layers at the same time is a very effective way of fixing the issue while learning absolutely nothing about what caused it.

Wrapping Up

Integrating Oracle GoldenGate with Microsoft Entra ID isn’t particularly difficult once you understand how the pieces connect.

Entra ID authenticates the user and provides the group information.

GoldenGate maps those groups to its own roles:

Security
Administrator
Operator
User

The configuration itself involves quite a few components, but the interesting part for me is what happens when one of them is wrong.

A missing permission, an untrusted certificate, the wrong group name, or a mismatched redirect URI can all look like an authentication problem, but they fail at completely different layers.

That’s why I wanted to go a little further than simply configuring the Authorization Profile and taking a screenshot when it turned green.

Getting it working is useful.

Knowing where to look when it stops working is better.