In your case I would create the application user as a “no authentication” user. See here for details. Then create a proxy user on the database which is allowed to be your application user. I.e. your application connects as follows:
username[application_user]/proxy_user_password@connect-string
E.g.
alter user cbleile1 no authentication;

sqlplus tdm1[cbleile1]/tdm1pwd@pdb1_cman

The application user does not need to have a failed connection profile anymore, because you always get an ORA-1017 when trying to connect even with the correct password. So to accidently connect to your application user you have to use that specific syntax for the proxy user and I doubt that it happens “accidently”.

Regards
Clemens

You only need CMAN here (no AVDF), but we kind of use the behavior of TDM to meet our requirements. I.e. with CMAN you filter on client-ip and target service through rules. With TDM you get the additional possibility to define a link between a service and a db-user, because service pdb1 in the wallet has user tdm1 assigned only. And tdm1 got the proxy-user right to become “only” cbleile1 on the DB. The nice thing is that you still have to provide the password for cbleile1 when connecting, but you actually connect with the proxy-user tdm1, which has its password in the wallet. So TDM provides this link now between service (pdb1) and proxy-user (tdm1) and final user (cbleile1). As a client you need to know the password of cbleile1. A different client cannot connect to cbleile1, because it is not allowed to connect to service pdb1 (in CMAN) and hence cannot use the proxy-user tdm1. However, it can use service pdb1_2, which uses DB-service pdb1 in the wallet as well. So there’s not need to create new services on the DB.

Hi, yes, if you use a wrong password then your account gets locked after your defined 5 attempts. That behavior is actually difficult to change In my view you should allow more “failed logon attempts” and rely on the delays the failed attempt cause for the next failed attempt. The failed attempts should be audited of course. See also MOS Note “High ‘library cache lock’ Wait Time Due to Invalid Login Attempts (Doc ID 1309738.1)” which might be interesting for you in this context.
Regards
Clemens

Thanks for the info, you are correct, it has to be ncdb1 and (HOST = 19c-dg1). Those 2 typos have been corrected. Concerning “pdb1_2 service must be running on the server”: pdb1_2 is not a service running on the server, on the cman server it is an entry in the wallet, which tells it under what user it has to connect to the DB and in cman’s tnsnames,ora telling it where to connect. I.e. the client 12cr2Client requests to connect to service pdb1_2. According the rule “(src=12cr2Client)(dst=19c-dg1)(srv=pdb1_2)(act=accept)” that is allowed. The CMAN checks its wallet for entry pdb1_2 which points to proxy user tdm2 on the DB and its tnsnames.ora with entry pdb1_2 with the connect string to the DB.
I.e. the service in the client tnsnames.ora is resolved on the cman-server as a combination of wallet entry pdb1_2 and tnsnames alias pdb1_2. On the db-server only service pdb1 is known.
Regards
Clemens

Hi, that’s correct. I adjusted the Blog accordingly.
Thanks and regards
Clemens