multiple tnsnames.ora files

multiple tnsnames.ora files

Post by Terry Dykstr » Sun, 18 Mar 2001 01:54:20



I use different tnsnames files.  As dba/developer I access many more
databases than our users.  I just set the tnsadmin variable for those people
to point to a production tnsnames.ora and mine points somewhere else.

--
Terry Dykstra
Canadian Forest Oil Ltd.



> > I have seen many articles on maintaining multiple tnsnames.ora files so
> that
> > individual groups can use each file which only points to the databases
> they
> > need to see. This seems like a great idea. Why give a global file to
> people
> > with pointers to databases they don't use so they will be curious to go
> > snooping?

> > I wanted to see if others out there are doing this and does it work?
Some
> > say it is not easy to manage but I say "would you rather risk someone
> > breaking into the database because you made a global file available that
> > tells everyone how to find all of your databases?"

> > Does anyone NOT recommend this? Any ideas welcome!

> > Thanks,
> > Paul

> This is a definitely a very bad idea. Imagine (I have been in this
situation
> several times) an organisation with 50+ developers, where literally
> *everyone* has his own tnsnames.ora. If they would only know how to
maintain
> it that would be fine, but in both cases a DBA distributed the file, and
as
> his sucessor I was forced to visit about every computer to maintain it.
> There were also frequent problems with people who accidentally deleted
their
> tnsnames.ora and were incapable of resolving that problem.
> Avoiding snooping is simply a matter of setting appropiate passwords. If
you
> never change the system password from manager into something else you
> shouldn't complain about people snooping into your databases.
> In short: your idea is just plain stupid, sorry to say so.

> Regards,

> Sybrand Bakker, Oracle DBA

> Sybrand

 
 
 

multiple tnsnames.ora files

Post by Paul » Sun, 18 Mar 2001 12:33:24


It's good to see some people brave enough to try something like this....and
this isn't rocket science! If the correct security is set on users'
workstations, then no one should have to worry about users deleting their
tnsnames.ora file accidentally! And if there were some type of problem with
a tnsnames.ora file on a desktop.....why visit each desktop? This is 2001
man! Use some type of software distribution tool!


> I use different tnsnames files.  As dba/developer I access many more
> databases than our users.  I just set the tnsadmin variable for those
people
> to point to a production tnsnames.ora and mine points somewhere else.

> --
> Terry Dykstra
> Canadian Forest Oil Ltd.




> > > I have seen many articles on maintaining multiple tnsnames.ora files
so
> > that
> > > individual groups can use each file which only points to the databases
> > they
> > > need to see. This seems like a great idea. Why give a global file to
> > people
> > > with pointers to databases they don't use so they will be curious to
go
> > > snooping?

> > > I wanted to see if others out there are doing this and does it work?
> Some
> > > say it is not easy to manage but I say "would you rather risk someone
> > > breaking into the database because you made a global file available
that
> > > tells everyone how to find all of your databases?"

> > > Does anyone NOT recommend this? Any ideas welcome!

> > > Thanks,
> > > Paul

> > This is a definitely a very bad idea. Imagine (I have been in this
> situation
> > several times) an organisation with 50+ developers, where literally
> > *everyone* has his own tnsnames.ora. If they would only know how to
> maintain
> > it that would be fine, but in both cases a DBA distributed the file, and
> as
> > his sucessor I was forced to visit about every computer to maintain it.
> > There were also frequent problems with people who accidentally deleted
> their
> > tnsnames.ora and were incapable of resolving that problem.
> > Avoiding snooping is simply a matter of setting appropiate passwords. If
> you
> > never change the system password from manager into something else you
> > shouldn't complain about people snooping into your databases.
> > In short: your idea is just plain stupid, sorry to say so.

> > Regards,

> > Sybrand Bakker, Oracle DBA

> > Sybrand


 
 
 

multiple tnsnames.ora files

Post by Paul » Sat, 17 Mar 2001 12:44:27


I have seen many articles on maintaining multiple tnsnames.ora files so that
individual groups can use each file which only points to the databases they
need to see. This seems like a great idea. Why give a global file to people
with pointers to databases they don't use so they will be curious to go
snooping?

I wanted to see if others out there are doing this and does it work? Some
say it is not easy to manage but I say "would you rather risk someone
breaking into the database because you made a global file available that
tells everyone how to find all of your databases?"

Does anyone NOT recommend this? Any ideas welcome!

Thanks,
Paul

 
 
 

multiple tnsnames.ora files

Post by Sybrand Bakke » Sat, 17 Mar 2001 15:01:45



Quote:> I have seen many articles on maintaining multiple tnsnames.ora files so
that
> individual groups can use each file which only points to the databases
they
> need to see. This seems like a great idea. Why give a global file to
people
> with pointers to databases they don't use so they will be curious to go
> snooping?

> I wanted to see if others out there are doing this and does it work? Some
> say it is not easy to manage but I say "would you rather risk someone
> breaking into the database because you made a global file available that
> tells everyone how to find all of your databases?"

> Does anyone NOT recommend this? Any ideas welcome!

> Thanks,
> Paul

This is a definitely a very bad idea. Imagine (I have been in this situation
several times) an organisation with 50+ developers, where literally
*everyone* has his own tnsnames.ora. If they would only know how to maintain
it that would be fine, but in both cases a DBA distributed the file, and as
his sucessor I was forced to visit about every computer to maintain it.
There were also frequent problems with people who accidentally deleted their
tnsnames.ora and were incapable of resolving that problem.
Avoiding snooping is simply a matter of setting appropiate passwords. If you
never change the system password from manager into something else you
shouldn't complain about people snooping into your databases.
In short: your idea is just plain stupid, sorry to say so.

Regards,

Sybrand Bakker, Oracle DBA

Sybrand

 
 
 

multiple tnsnames.ora files

Post by Nuno Sou » Sat, 17 Mar 2001 19:53:26



>I have seen many articles on maintaining multiple tnsnames.ora files so that
>individual groups can use each file which only points to the databases they
>need to see. This seems like a great idea. Why give a global file to people
>with pointers to databases they don't use so they will be curious to go
>snooping?

It's not a great idea, but you can try to put the files in each shared
folder in a file server, then share them appropriately to each user
group using the same share "drive" from the clients. You maintain the
files in the file server.  I did this with a site where we needed to
have an alias for development and another for production and the site
security went spazzo when I got both aliases in a single file.  It
happens...

Cheers
Nuno Souto

http://www.users.bigpond.net.au/the_Den/index.html

 
 
 

multiple tnsnames.ora files

Post by rob » Sat, 17 Mar 2001 17:59:28


Maybe you could try something like this.

On a NT server ('ntserver01') create directory structure like:
c:\sqlnetconfigfiles\developers
c:\sqlnetconfigfiles\production
c:\sqlnetconfigfiles\dba

create shares for these dirs
developer$
production$
dba$
and give permissions to the users that are allowed to read these files.

On the clients create mapped network drives:
For a developer this would be:
developers$ on 'ntserver01'  (F:)

Put a TNS_ADMIN entry in the registry
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME<n> key value (F:).

This way you can maintain centralised sets of config files.
This makes changing sql*net config files very easy, you only have to change
on one place.
Disadvantages are :
depending on the number of users it can be a lot of work
if the mapped network drive can't be reached for some reason users can't
connect.

Regards,
Rob.

 
 
 

multiple tnsnames.ora files

Post by Paul » Sat, 17 Mar 2001 23:20:46


It's not my idea, it's the idea stated from several popular writers of
Oracle books. Obviously people are doing it and it isn't stupid. Maybe in
your situation it would be difficult. What I'm saying is, setting passwords
and keeping unique tnsnames.ora files is a great security combo (among other
things). Setting passwords alone is not very secure either....in most
environments passwords are never set to expire and people using the same
password across multiple databases. How secure is that? I say if you can
figure out a way to manage the tnsnames.ora files, every little bit helps!

I find most DBA's are whiners when it comes to security. But if an exposure
to a critical database got into the media, it could be the demise of some
companies. With that in mind, I think DBA's should start trying to secure
things a little more with a little less whining and lax security. Database
systems are some of the most insecure systems I have ever seen in every
environment I have been in. It's time for someone to step up to the plate
and say "that's it, no more!".




> > I have seen many articles on maintaining multiple tnsnames.ora files so
> that
> > individual groups can use each file which only points to the databases
> they
> > need to see. This seems like a great idea. Why give a global file to
> people
> > with pointers to databases they don't use so they will be curious to go
> > snooping?

> > I wanted to see if others out there are doing this and does it work?
Some
> > say it is not easy to manage but I say "would you rather risk someone
> > breaking into the database because you made a global file available that
> > tells everyone how to find all of your databases?"

> > Does anyone NOT recommend this? Any ideas welcome!

> > Thanks,
> > Paul

> This is a definitely a very bad idea. Imagine (I have been in this
situation
> several times) an organisation with 50+ developers, where literally
> *everyone* has his own tnsnames.ora. If they would only know how to
maintain
> it that would be fine, but in both cases a DBA distributed the file, and
as
> his sucessor I was forced to visit about every computer to maintain it.
> There were also frequent problems with people who accidentally deleted
their
> tnsnames.ora and were incapable of resolving that problem.
> Avoiding snooping is simply a matter of setting appropiate passwords. If
you
> never change the system password from manager into something else you
> shouldn't complain about people snooping into your databases.
> In short: your idea is just plain stupid, sorry to say so.

> Regards,

> Sybrand Bakker, Oracle DBA

> Sybrand

 
 
 

multiple tnsnames.ora files

Post by Erwin Dondor » Sun, 18 Mar 2001 00:36:53



> I have seen many articles on maintaining multiple tnsnames.ora files so that
> individual groups can use each file which only points to the databases they
> need to see. This seems like a great idea. Why give a global file to people
> with pointers to databases they don't use so they will be curious to go
> snooping?

> I wanted to see if others out there are doing this and does it work? Some
> say it is not easy to manage but I say "would you rather risk someone
> breaking into the database because you made a global file available that
> tells everyone how to find all of your databases?"

> Does anyone NOT recommend this? Any ideas welcome!

I would reccommend NOT to have several tnsnames.ora files.
It is a nightmare to maintain and it does not give you any security.
(as "Security through Obscurity" is never a safe principle)
Anyone can just add some records to a tnsnames.ora file, or set up
a client that looks at a different tnsnames.ora files. And besides you
can also just type:

Where (DESCRIPTION=...) is exactly the text from a tnsnames definitions.
In this case you don't even need the tnsnames.ora file any more.

Erwin

 
 
 

multiple tnsnames.ora files

Post by Brian Peaslan » Wed, 21 Mar 2001 00:43:46


Quote:> your situation it would be difficult. What I'm saying is, setting passwords
> and keeping unique tnsnames.ora files is a great security combo (among other
> things). Setting passwords alone is not very secure either....in most
> environments passwords are never set to expire and people using the same
> password across multiple databases. How secure is that? I say if you can
> figure out a way to manage the tnsnames.ora files, every little bit helps!

I'd have to disagree with "setting passwords and keeping unique
tnsnames.ora files is a great security combo". All the TNSNAMES file
does is point me to a server. The multitude of hackers out there don't
even know anything about my databases and the entries in my TNSNAMES
file, but that doesn't stop them from attempting to hack into my
databases (or yours). Unique TNSNAMES files does absolutely nothing to
stop persistent hacks. It only stops the lazy hacks. That's it....

The two best methods for implementing security are firewalls and a good
password policy. How complex are your passwords? Do you change them
often? How has access to the passwords? These are the only things that
are going to safegaurd your database. Either that or put you database on
a machine that is not connected to any network (but that's a highly
unrealistic solution).

Quote:> I find most DBA's are whiners when it comes to security. But if an exposure
> to a critical database got into the media, it could be the demise of some
> companies. With that in mind, I think DBA's should start trying to secure
> things a little more with a little less whining and lax security. Database
> systems are some of the most insecure systems I have ever seen in every
> environment I have been in. It's time for someone to step up to the plate
> and say "that's it, no more!".

Are you speaking for yourself or for the majority of people who visit
these newsgroups? Most DBAs I know take security very, VERY seriously
and they don't whine about it. If they do any whining, it that there
isn't enough security due to the business rules that must be imposed.

HTH,
Brian

 
 
 

1. Multiple tnsnames.ora files

We have a problem in that some of our users require access to an unusual
instance in addition to the usual set. We do not wish to add the details
of the unusual instance to the system tnsnames file for reasons that
include security and duration of use.

The manuals imply that user locals files can be used in addition to system
level ones but refer readers to the OS-dependent manuals for details. The
manuals for Win95/NT do not mention the subject, but we believe it can be
done by using multiple Oracle_home values in some way.

Has anyone tried this, if so how does it work and what drawbacks have you
experienced.

The alternative is to use a names server and a local file but none of us
has any experience with Oracle Names and people are reluctant to use it if
alternatives can be found.

2. Expressing Set Model Theory using FOR XML EXPLICIT

3. Multiple tnsnames.ora files possible?

4. Incremental searches on SQL / Large Interbase tables

5. multiple tnsnames.ora files

6. Installing SQL 7.0

7. case insensitive in SQL Server

8. sample file of tnsnames.ora,listener.ora,sqlnet.ora please

9. tnsnames.ora, sqlnet.ora, listner.ora

10. One tnsnames.ora for multiple oracle homes

11. Multiple tnsnames.ora?