Home » RDBMS Server » Security » Database connection restriction
icon9.gif  Database connection restriction [message #150476] Thu, 08 December 2005 01:43 Go to next message
daniellin
Messages: 2
Registered: November 2005
Location: Namibia
Junior Member
Hi All Oracle Experts,

We have the problem with the database connection restriction for our users. The problem is as follow:

When the user login to the forms:
“http://172.16.32.14:7779/forms90/f90servlet?form=stmain.fmx” on the database SID DEV, the user can actually login with the database SID PRD. This causes the security issue for the database connection. The database SID PRD is connected to the live database, and DEV is being used as the test environment in the Test server. Therefore, when the users connect to DEV, they should not have the right to connect to PRD. If the user validates the data, it will apply to the PRD Database. We do not want this to happen.

The steps which we have taken:
-----------------------------------

1.We made the changes on the tnsnames.ora files on the database and application side of DEV.
2.We delete the lines which consist of prd, so it will not find the PRD connection at tnsnames.ora file
3.We restart the Oracle application and database services on the database DEV.

After we made these changes, the problem is still exist. May anyone help me to solve this problem? What could be the cause of this problem?

Our Oracle version is "Oracle 9i Database Release 2 (9.2.0.1.0) + Patchset 9.2.0.4".

Thanks

Daniel Lin
Re: Database connection restriction [message #150745 is a reply to message #150476] Fri, 09 December 2005 07:03 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
I do not understand what your problem is.
Please rephrase.
Your databases are in a seperate server. Right?
Your applications/users are in seperate machines. Right?
Your PROD database has a listener.
Your DEV database shares the same listener as PROD.

All you have to do is
in your CLIENT machines create two seperate tnsentries, PROD and DEV.
if the connection is like
scott/tiger@PROD -> connection is made to prod
scott/tiger@DEV -> connection is made to dev
icon7.gif  Re: Database connection restriction [message #150749 is a reply to message #150476] Fri, 09 December 2005 07:28 Go to previous messageGo to next message
daniellin
Messages: 2
Registered: November 2005
Location: Namibia
Junior Member
Hi Manesh,

Thank you for your reply.

"Your databases are in a seperate server. Right?"
Yes. We have database server and application server which are separate servers.

"Your applications/users are in seperate machines. Right?"
Yes. Our users use standalone pc to acess the database.

"Your PROD database has a listener."
Yes. that's true

"Your DEV database shares the same listener as PROD."
No, DEV database doesn't share the same listener as PROD. It has it own listener and tnsnames.ora. DEV is located at the Test server which is different than PROD (Live Server). The test server is connected to the database server.

On the client side, the tnsnames entries contain both the DEV and PROD entries. The thing we want to avoid is when the user connect to DEV Database, the users should not be able to jump to PROD database. This means the users working on the Test server should not have the access to the Live database server.

Any suggestion will be appreciated. Thanks

Re: Database connection restriction [message #150751 is a reply to message #150749] Fri, 09 December 2005 07:37 Go to previous message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator

Then do not provide tnsentries to connect to PROD!!. I still do not understand
Every client ( sql*plus, forms/reports or any 3rd party tool) has its own tnsnames.ora
Make sure none of them have entries to PROD.


Previous Topic: To check all privilege available
Next Topic: How to detect which firewall and antivirus exists in server in windows?
Goto Forum:
  


Current Time: Thu Mar 28 16:48:30 CDT 2024