|
|
|
|
|
|
|
Re: SQL Developer - Disable "save password" functionality [message #495401 is a reply to message #495387] |
Fri, 18 February 2011 13:24 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
ThomasG
Messages: 3212 Registered: April 2005 Location: Heilbronn, Germany
|
Senior Member |
|
|
Michel Cadot wrote on Fri, 18 February 2011 18:10Anyway, there is no reason to install a GUI on a server, it should be ONLY on a client workstation.
Regards
Michel
What is this "Client Workstation" you speak off?
We have FOUR "Client Workstations" in a company of 1500 people for dire strait emergencies (like complete power loss to all redundant data centres), the rest is working on provisioned terminal servers sessions and thin clients.
We don't use SQL*Developer here, but some similar tools. Those tools store passwords in the user registry. What we have done is installed the software, created all the needed accounts for the users in that install, then blocked write access for the the users to that registry keys. Although how to to it *exactly* in your environment might be better answered in a OS specific forum.
|
|
|
Re: SQL Developer - Disable "save password" functionality [message #495692 is a reply to message #495394] |
Tue, 22 February 2011 00:53 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
Frank
Messages: 7901 Registered: March 2000
|
Senior Member |
|
|
firefly wrote on Fri, 18 February 2011 18:37That's essentially what I'm asking. How do I disable this settings...is there a setting/switch in the installation perhaps to disable this setting? If you don't know that's OK too, as I can always raise an SR
Thanks,
F
I must say that the answers (except for ThomasG's) clearly show the total lack of understanding typically displayed by tunnelvisioned DBAs.
Firefly comes to the Client Tools forum, a forum dedicated to ask questions about client tools, which include GUI tools and NOT just and only sqlplus, and he gets whacked. His question is a very valid one, even displaying the fact that he gave security a good thought.
The fact that one person (an admin) can change a setting does not automatically mean that every other person can change it back.
Alas, firefly, I don't know the answer either. You might want to look into making the xml file which stores the connections read-only, but that would mean that users also cannot add connections.
Good luck and don't let the grumpy old folks get you down!
|
|
|
Re: SQL Developer - Disable "save password" functionality [message #495747 is a reply to message #495692] |
Tue, 22 February 2011 03:14 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
firefly
Messages: 53 Registered: March 2009 Location: Europe
|
Member |
|
|
Hi Frank.
Yes, the ONLY reason I am interested in this is from a security perspective. We are actually arranging for a support vendor to be able to remotly diagnose issues. For this they have asked for a query tool to be able to have a read only view of the data. We are OK with this but don't want anyone else (e.g. our helpdesk) logging onto this PC or server and being able to query the data...hence why I would prefer to diable the storing of passwords. I'll raise an SR and revert with the details. The other option I can see is thata the password for the vendor company is reset everyime they dial-in, but this is a bit more admin.
Thanks,
Firefly.
|
|
|
Re: SQL Developer - Disable "save password" functionality [message #495749 is a reply to message #495747] |
Tue, 22 February 2011 03:20 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
Roachcoach
Messages: 1576 Registered: May 2010 Location: UK
|
Senior Member |
|
|
It may be an idea to come at this from other security angles rather than just storing the password.
Accept that they can store a password for a connection, then give that user nothing but create session and create a [series of] password protected role[s] they need to activate to actually view any data. As an example.
|
|
|
|
|
|
|