October 15, 2007 at 7:50 am
Hi,
I have an issue. My fellow programmer once tried to change some code like commenting few lines in SPs and changing codes in Views etc thru EM in SQL 2000. The changes made thru EM (by double clicking on that file) does not update the DATE MODIFIED field. This has been very tough to find the culprit as the name of the user also does not get updated. The problem is, we know who does that.. but cannot prove. Is there any way to find or track the changes made thru EM?
October 15, 2007 at 12:23 pm
One way to proactively do this is using SQL profiler. You can put a lot of filters on it, such as application (EM) or user, etc... The only problem is you need to have it turned on and then catch the person in the act. The other issue is it could be a lot of data to parse if you aren't good about filtering. Hope that helps.
Eric
October 15, 2007 at 12:55 pm
There are a variety of 3rd party utilities out there that do some sort of auditing or another. Basically they are still just using a profiler trace although they tweak it quite a bit, and provide a nice front end so that you can more easily find what you are looking for.
It might not be a bad idea to demo a few tools and see if they can help you in the meantime.
-Luke.
October 15, 2007 at 1:29 pm
What date modified? I was under the impression the only date tracked on a stored proc is the date it was created. That only gets updated when you drop/create the proc, but not during an ALTER process. Or were you discussing a column on a table?
Also - if someone is making changes ad-hoc, isn't that a workflow/permissions process? Sounds like someone isn't following procedure. If they can't follow procedure, then perhaps they shouldn't have access to updating the server?
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 15, 2007 at 1:40 pm
if you even suspect someone is making changes without permissions, you should simply change the password(s) (probably for sa..developers connecting on production as sa a possiblity?)
then create a new role, add only the permissions they need, and give them a new login to that role...call it a security improvement to keep people's feelsing from being hurt, but it locks them out of the server. don't give them db_owner rights, just data reader ;if they need to test, they can have full rights on the development server.
Lowell
October 15, 2007 at 7:40 pm
Lovely 😉
October 15, 2007 at 9:35 pm
You can create trigger on the syscolumns while cleaning up or tighten up your access rights on your database server.
October 16, 2007 at 12:12 am
I can tell you haven't actually tried doing that... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 16, 2007 at 2:49 am
If the mission is to find some sort of 'evidence' of a certain action, then providing the db is not in simple recovery mode, the transaction log contains records of the alter/change.
All you need then is a tool to read the log, and the log itself.
/Kenneth
October 16, 2007 at 10:24 am
Hey All,
Thanks for all of the suggestions. I could not remove the permissions to the user as he seems to be a higher authority and I or either my team members do not have the right to hide or infact deny the access to him to the production server. Anyways.. Thank you for all the suggestions. We encrypted the scripts (original) and re-run the script and he was unable to do changes to the code therein. We just covered up 😉
Thanks again 🙂
October 16, 2007 at 10:30 am
lol encrypting is a good answer. way to go!
Lowell
October 16, 2007 at 10:50 am
Ahh - that explains it. That's one of my rules of thumb - "when dealing with a dangerous manager, make up a highly obscure technical reason, and use it to prevent them from making changes without going through you". Works every time!
"Ahh - but our secure web only deals with signed/encrypted/ procedures".
"Our rollout process now requires code to be checked into VSS to work. We don't manually touch anything anymore".
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 16, 2007 at 10:21 pm
Matt Miller (10/16/2007)
Ahh - that explains it. That's one of my rules of thumb - "when dealing with a dangerous manager, make up a highly obscure technical reason, and use it to prevent them from making changes without going through you". Works every time!"Ahh - but our secure web only deals with signed/encrypted/ procedures".
"Our rollout process now requires code to be checked into VSS to work. We don't manually touch anything anymore".
Heh... the way I fixed all of that was "Our specs say that only DBA's can promote code... you're not a DBA and I'm enforcing the specs according to company policy... take it up with HR and the security staff." 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 16, 2007 at 11:00 pm
Create a trace job which will secretly populate some secret table with data from master.dbo.sysprocesses where program_name = 'MS SQLEM '
Schedule it to run every minute or two.
Then at the end of the day you will have complete report about every bloody bastard who was trying to access the server using EM, including HostName, LoginName, net_address, etc.
You may add some script to save result of "dbcc inputbuffer(@SPID)" for each process inserted into the table. It will give you the text of the last command started from that connection.
Don't forget to remove records having your name in it before you pass it to the big boss.
😛
_____________
Code for TallyGenerator
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply