Managed ODP.Net: No LDAP server detected or confgiured

I'm trying to use the managed ODP.NET libraries to connect to an Oracle database in PowerShell (so not able to use an app.config file). When specifying the TnsAdmin property of the connection object to a location containing the tnsnames.ora, sqlnet.ora, and ldap.ora files, I get the error 'network naming: no LDAP server detected or configured'. If I set the TNS_ADMIN environment variable to the same location, the connection succeeds and can be queried without issue, regardless of whether the TnsAdmin property of the connection is set. I'm trying to avoid this, because a) minimising server configuration and b) other software on the machine breaks if the TNS_ADMIN environment variable is set (so I have to operate the different software under different user contexts).

I can't set the Tns_Admin attribute of the connection string, I get an error saying the attribute is invalid, even though documentation states it's only unavailable in the Unmanaged Driver.

I'm connecting to 19c databases using v19.3.0 of the Oracle.ManagedDataAccess.dll on both Windows 11/Server 2016 machines, with the same results on both. Being able to succeed when the environment variable is set implies that there's nothing wrong with the .ora files, but that the connection object is ignoring the ldap.ora file when loading via the TnsAdmin property. This appears to be the case in the documentation screencapped above that states it's only looking for sqlnet.ora and tnsnames.ora files. Is there anything that can be done about this behaviour? There doesn't seem to be anywhere to set the ldap information on the connection.

I have tried the proposed solution in this answer of removing LDAP from sqlnet.ora, but only get a connection timeout, presumably because the connection cannot find the LDAP server.

This could be difficult, because as far as I know the TNS_ADMIN environment variable takes precedence over all other settings. For the ODP.Net Managed Driver you can define the TNS_ADMIN also in the machine.config or user.config file. Other drivers do not use it, thus it should not affect any other application. See Determining location of relevant tnsnames.ora file

You could also resolve the alias by yourself, see ODP.NET Managed library does resolve alias, but 32-bit library does but I think this would be rather a dirty workaround.