February 17, 2006 at 9:57 am
Too many people use EM to #look# at the production database.
Without gettting into a debate about security, is there any way to prevent Enterprise manager being able to connect without affecting anything else?
Cheers.
February 17, 2006 at 12:33 pm
Don't install it on "too many people"'s machines.
A.J.
DBA with an attitude
February 17, 2006 at 3:01 pm
select spid from master..sysprocesses where program_name = 'MS SQLEM'
kill those spids.
I'll warn you before though, if you get spids 50,51,52 from the above query, there is no guarantee that 3 seconds later those spids will still be held by those EM processes.
February 17, 2006 at 7:00 pm
This
"...Without gettting into a debate about security, is there any way to prevent..."
struck me as a somewhat entertaining juxtaposition of desires -- almost as a desire to talk about how to secure something without talking about security
February 18, 2006 at 5:43 pm
Indeed. Imposing the security I want is going to be a big job. I have inherited a system that is somewhat out of (firm) control. You know the ones - 20 odd developers writing inline sql, all running under administrator privs. GOK whats going on.
Security is being addressed, but as I said that is not what I wish to discuss here. My problem is with the way folk casually pop open a proc or table in EM - I fear this tool, especially in the hands of web monkeys... hence the question.
February 20, 2006 at 7:45 am
I don't think you can prevent the connections, but you could secure the production systems so that the developers do not have alter/create rights for database objects. This would mean you would have to provide development systems in which they could work, but that is how it should be anyway.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
February 20, 2006 at 11:23 am
You should be able to remove all of the registered servers from the client machines by editing the registry on each machine. Then you can set permissions on the appropriate keys, preventing them from re-registering the servers. I suppose that a group policy object could be used to accomplish some of this, but perhaps not. I'm not sure.
EM uses the following area to store registrations (on my computer, anyway):
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\80\Tools\SQLEW\Registered Servers X so I would imagine that you could add a properly-crafted "deny" on that key to prevent new registrations. I don't have time to try it, but it just might work.
Another option would be to hide behind them and beat them with a sturdy object every time they do something that is not allowed. Good luck with this and let us know how it turns out.
hth jg
March 14, 2006 at 3:09 am
I have the same problem with too many people are using EM.
I now hide behind them and beat them with a sturdy object every time they do something that is not allowed.
But Wednesday is my free day. I want to know who I have to beat on Thursday.
Is there a possibility to log the using of EM
Thanks
Ton
March 14, 2006 at 6:26 am
Hi
Here U need to check one thing are they all using the sa account to get connected to SQL server thru EM or what??If they are using the sa account then probably you need to change the sa password and create a separate loginid's for them with proper rights and then even if they connecte thru the em then no probs as they will not be able to do much harm since they wont have much rights..
March 15, 2006 at 11:48 pm
Hi,
Is there any procedure runs each minute to prevent unauthorised users from accessing the EM by identifing their system name/I.P.Address? Any ideas?
Ramaa
March 16, 2006 at 6:11 am
You can sort of limit the usefulness of EM by making some changes on the databases :-
think carefully about this first , and test thoroughly and document 100% .
Assuming all your users are not dbo's or sysadmins .. remove public permissions from syscomments, sysusers, sysdatabases etc. etc. Taking out the public rights adds a certain level of security - syscomments is very good - stops users looking at procs etc.
You should restrict public rights as part of a security policy.
more info at http://www.sqlsecurity.com/
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply