Oracle Communities

Oracle Analytics and AI

Child Item

OAC built-in ATP conn.with Resource Principal to ATP-S private endpoint via PAC fails with ORA-25704

Hello,

We are testing the built-in Oracle Autonomous Transaction Processing connection in Oracle Analytics Cloud, with Connect Using = Resource Principal, through PAC to an ATP-S private endpoint.

This is not a generic IAM or PAC setup question. It is specifically about the OAC built-in ATP connection using Resource Principal toward a private ATP-S endpoint.

This is how the environment has been implemented.

OAC / IAM side

Following Oracle Support guidance, we created a dynamic group for the OAC instance using a matching rule based on the OAC resource OCID:

resource.id = '<OAC instance OCID>'

We tested the IAM policies for that dynamic group, including:

use database-connections in tenancy
manage autonomous-database-family in the target compartment

ATP-S side

Following Oracle Support guidance, on ATP-S we enabled IAM external authentication and created a globally authenticated database user mapped directly to the OAC instance OCID:

IDENTIFIED GLOBALLY AS 'IAM_PRINCIPAL_OCID=<OAC instance OCID>'

So this is not a generic shared-schema implementation with IAM_GROUP_NAME. It is the direct OAC instance mapping approach that Oracle Support explicitly asked us to test for OAC Resource Principal.

What works

Standard username/password connection from the same OAC instance to the same ATP-S database works.
IAM-based database authentication from external clients to the same ATP-S private endpoint also works.

This confirms that PAC, DNS/network reachability, ATP-S IAM external authentication, and DB-side principal mapping are working.

What fails

The failure is specific to the OAC built-in ATP connection when Connect Using = Resource Principal.

We tested both:

TLS
Mutual TLS

Both fail with the same backend error reported by Oracle Support:

ORA-25704: Current configuration does not use SSL_SERVER_DN_MATCH=TRUE. Token based authentication requires SSL_SERVER_DN_MATCH=TRUE with server authentication.

Relevant Oracle references

ORA-25704 documentation:
https://docs.oracle.com/en/error-help/db/ora-25704/
ADB IAM authentication documentation:
https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/iam-access-database.html

Oracle documents that ORA-25704 means token-based authentication is being attempted without client-side SSL_SERVER_DN_MATCH=TRUE. Oracle also documents that token-based access to Autonomous Database requires TCPS/TLS, and that for private endpoint access the connect string must use a host FQDN rather than an IP address. In the token-based model, the client application or tool requests the database token and passes it to the database client API.

In this OAC flow, the customer does not manually construct the underlying database client configuration for the built-in ATP connection. Therefore, the key question is whether OAC correctly applies the required DN-matching behavior when Resource Principal is used against an ATP-S private endpoint. Oracle’s OAC documentation confirms this is the built-in connection model used to create Oracle Autonomous Transaction Processing connections in OAC.

Question to the community

Has anyone successfully implemented the OAC built-in ATP connection with Connect Using = Resource Principal through PAC to an ATP-S private endpoint?

If yes, can you confirm:

whether this configuration is currently supported in practice,
whether you implemented it with resource.id dynamic group + IAM_PRINCIPAL_OCID database user mapping,
whether any extra prerequisite is required beyond that,
and whether ORA-25704 in this exact path points to a known OAC limitation or defect?

Thank you.

Find more posts tagged with

Connection

OAC

Oracle Analytics Cloud

Accepted answers

All comments

Alessandro_Moccia

Update based on Oracle Support SR:

Oracle Support has now indicated that, based on their current internal understanding, this may be a product limitation / expected-use scenario for Public DB rather than a confirmed bug. Final confirmation is still pending.

At the same time, the public OAC documentation I reviewed does not clearly state that the built-in ATP connection with Resource Principal is public-endpoint-only when PAC/private ATP-S is used.

So I am still very interested in any confirmed field experience from the community on this exact path:

OAC built-in ATP connection → Resource Principal → PAC → ATP-S private endpoint

If anyone has this working in practice, I would appreciate details on the exact implementation and whether any additional prerequisite was required.

GayathriAnand-Oracle

Resource Principal connection type is only supported for connections with SSL_SERVER_DN_MATCH=TRUE.

This is also mentioned in these ADB docs:

https://docs.oracle.com/en/error-help/db/ora-25704/?r=26ai

https://docs.oracle.com/en/database/oracle/oracle-database/26/netrf/database-net-services-reference.pdf?source=%3Aow%3Ams%3Apt%3A%3A

So you need to modify the sqlnet.ora on ADB side to set SSL_SERVER_DN_MATCH=TRUE and then test the token based connection from OAC. We will document same in SR as well and also create doc bug for same.

Thanks

Gayathri

Alessandro_Moccia

Hi @GayathriAnand-Oracle,

thank you. I need one clarification on your statement "modify the sqlnet.ora on ADB side to set SSL_SERVER_DN_MATCH=TRUE".

According to the Oracle Database Net Services Reference, SSL_SERVER_DN_MATCH is a client-side DN-matching parameter, and Oracle explicitly describes it as a check performed by the client using the client sqlnet.ora file or the connect string. The same reference also states that for OCI IAM authentication, SSL_SERVER_DN_MATCH must be set to YES.

In this scenario, OAC is the client and ADB-S is the server. Therefore, could you please clarify exactly what must be changed by the customer?

1. Is there any customer-side configuration to change on ADB-S?

2. Or is this something Oracle must correct in the OAC built-in ATP connection path / connect descriptor generation?

3. If the change is not customer-managed, please confirm that this requires Oracle-side product/service action.

Thank you.

GayathriAnand-Oracle

Typically the wallet file that is downloaded from ADB has the sqlnet.ora and tnsnames.ora with SSL_SERVER_DN_MATCH setting correct. So i would assume the change should happen on the wallet side of ADB?

Alessandro_Moccia

Hi @GayathriAnand-Oracle

Thank you for the clarification.

In this specific case, that remediation is not customer-applicable.

When the OAC built-in ATP connection is created with Connect Using = Resource Principal, the OAC wizard does not expose any wallet upload field. The wallet upload option is available only in the Basic username/password path.

With Resource Principal selected, OAC handles the wallet and the connection configuration internally. The customer cannot upload, replace, or modify the wallet zip file in this connection flow.

Therefore, if SSL_SERVER_DN_MATCH must be set correctly for this path, that has to be handled internally by OAC — either through the wallet it retrieves automatically or through the connect descriptor / connection properties it builds internally for Resource Principal connections.

Could you please confirm whether this requires an OAC product-side fix, and whether there is a bug reference, documentation bug reference, or planned fix for it?

Thank you,
Alessandro

GayathriAnand-Oracle

What i meant was that the ADW connection details shows the tns descriptor which has the SSL_SERVER_DN_MATCH parameter. For my public ADB this value shows as true and my resource principal connection works fine. So similarly if your ADW connection strings has the SSL_SERVER_DN_MATCH parameter as true the connection will work from OAC. See screenshot below:

Alessandro_Moccia

Hi @GayathriAnand-Oracle

thank you, this clarification is very helpful.

We checked the ADB connection details and found the following difference:

Public endpoint connection descriptor: ssl_server_dn_match=yes
Private endpoint connection descriptor: ssl_server_dn_match=no

This appears to be the key difference between the working and non-working paths.

In our environment, Basic connectivity works because in that customer-managed path we can download the wallet and explicitly set SSL_SERVER_DN_MATCH=YES in sqlnet.ora / tnsnames.ora before use.

For the OAC built-in ATP connection with Connect Using = Resource Principal, the customer cannot upload or modify the wallet, nor override the internal connect descriptor used by OAC. That path is fully handled internally by OAC.

Given that Oracle documents that token-based authentication requires SSL_SERVER_DN_MATCH=TRUE, and that for OCI IAM authentication SSL_SERVER_DN_MATCH must be set to YES, could you please confirm the following:

Does OAC Resource Principal use the ADB connection descriptor as-is for private endpoint connections?
If yes, is the private endpoint value ssl_server_dn_match=no the reason this path fails with ORA-25704?
If so, should the fix be:
- on the ADB-generated private endpoint connection descriptor side, or
- on the OAC side by overriding this setting for Resource Principal connections?

If available, please also share the bug / doc-bug reference and planned fix.

Thank you,
Alessandro

GayathriAnand-Oracle

Please see below

Does OAC Resource Principal use the ADB connection descriptor as-is for private endpoint connections? Yes
If yes, is the private endpoint value ssl_server_dn_match=no the reason this path fails with ORA-25704? Yes

There is nothing on OAC side we can fix/modify. We just use the connection details as is from ADB. You may want to follow-up with ADB team on how to change the connection details for adb to make it use SSL_SERVER_DN_MATCH=TRUE.

Thanks

Gayathri

Alessandro_Moccia

Hi @GayathriAnand-Oracle

thank you for the clarification.

Based on the additional confirmation received from the OAC team, the current situation is now clear:

OAC uses the ADB private-endpoint connection descriptor as-is for Resource Principal connections.
The private-endpoint descriptor contains ssl_server_dn_match=no.
Oracle Net documentation states that for OCI IAM authentication, SSL_SERVER_DN_MATCH must be set to YES.

So the issue is now clearly identified, but the proposed remediation is still not customer-actionable in the OAC Resource Principal path.

In this flow, the customer cannot edit or upload the wallet / connect descriptor used internally by OAC. Therefore, asking the customer to “make/verify these settings” does not map to an exposed customer-managed step for the OAC built-in ATP connection with Resource Principal.

Please therefore coordinate internally with the appropriate Oracle product team(s) and provide one of the following:

a supported customer-actionable remediation for this exact OAC Resource Principal path,
or a product fix / enhancement on the Oracle side,
or an explicit statement that this combination is currently unsupported / limited by design.

At present, the issue appears to be caused by the ADB private-endpoint connection details used as-is by OAC, with no customer ability to override them in the Resource Principal flow.

Please confirm the next internal owner and the planned next step.

Thank you,
Alessandro