May 13, 2008 at 8:58 pm
Ok this is ugly...we are a small company, we have gone through a lot of turnover (not in IT but in the company in general) one of our IT members is almost to the point of stalking another employee.
The IT member is reviewing files, emails, logs of two employees a blatant violation of company policy
The IT director has been alerted of the situation and the director is not going to go through ‘proper channels’ to resolve this. The person who is a network admin is too valuable.
Yes this will get ugly...as the DBA I need to cover my *** big time. Did I mention he is a domain admin?
We have audit on all successful and failed logins. Half of our databases are mixed mode, so the plus is for the critical you need to have a database logon ID which this person does not have, YET may have access to the 'sa' password which is in our disaster recovery layout.
I am thinking of doing profiler trace on all databases to check for anything funny. I cannot simply drop groups that as a windows user he may be part of (i.e. BlackBerry server) that will raise suspicion.
Looking for some ideas..
May 13, 2008 at 9:41 pm
jsheldon (5/13/2008)
Ok this is ugly...we are a small company, we have gone through a lot of turnover (not in IT but in the company in general) one of our IT members is almost to the point of stalking another employee.The IT member is reviewing files, emails, logs of two employees a blatant violation of company policy
The IT director has been alerted of the situation and the director is not going to go through ‘proper channels’ to resolve this. The person who is a network admin is too valuable.
Yes this will get ugly...as the DBA I need to cover my *** big time. Did I mention he is a domain admin?
We have audit on all successful and failed logins. Half of our databases are mixed mode, so the plus is for the critical you need to have a database logon ID which this person does not have, YET may have access to the 'sa' password which is in our disaster recovery layout.
I am thinking of doing profiler trace on all databases to check for anything funny. I cannot simply drop groups that as a windows user he may be part of (i.e. BlackBerry server) that will raise suspicion.
Looking for some ideas..
I'm not quite sure I follow - your boss is NOT going to get rid of this person? or isn't going to go through normal channels to get this guy separated?
Sounds to me that you have someone unstable on the team, so the bosss refusing to do something about it puts all of you at risk. Let's just say that "valuable" becomes "liability" when "half-cracked" turns into "fully unhinged".
As to protecting your server - that's going to be a challenge. Even if you were to change the SA password (which I would do), if he has access to the accounts starting/stopping the service, which means he will have access to resetting sa any old time he wants. Coming up with some creative excuse to have separate backups for yourself would be nice but it's not like that wouldn't get noticed.
If nothing else - find a way to have a separate AD backup, as well as your critical data somehow. I'd also discretely work on identifying what it would take to lock this person out entirely from everything (network/VPN/E-mail, etc...); plan an outage (where you go off-wire for a while while you plug up the holes).
You know what the ONLY long-term fix to this is. If your mgmt doesn't want to help, then you're in an unwinnable scenario (i.e. possibly plan on a discrete departure).
By the way - if Stalkie Stalkerton is half as paranoid as you think he is - he's probably aware of this board and your involvement with it, and could find this info at any time......
----------------------------------------------------------------------------------
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?
May 13, 2008 at 11:01 pm
"Disater Planning" comes in many forms... this is one of them. You need to make backups that the "IT Member" has no knowledge of and no access to. Backups should be "point in time" and done on a very regular basis.
Once that's all set up, you need to remind the IT Director that (s)he could go to jail under the current stalking laws because (s)he refused to take action.
In the meantime, you need to document everything you know about the problem and the actions you tried to take to resolve the problem including dates and times that you spoke to the IT Director about the problem and what the just of the conversations are because when this idiot and the IT Director get taken out, they're going to try to take people out with them. Protect yourself... document everything having to do with this and be very accurate. Include names of witnesses that may have overheard any conversation.
I also suggest that you see a lawyer before you talk to anyone about this problem again (especially your IT Director who could fire you for, no matter how well justified, bugging him/her)... you can't guess about this. I've seen too many good people get taken out just because they had knowledge of a situation like this... and did nothing.
--Jeff Moden
May 14, 2008 at 12:20 am
Technical advice only here, cause I have no knowledge of USA laws.
Have you considered enabling C2 or Common Criteria logging? They'll both produce a lot of data but they will show you, in detail, who did what to your server, when. Save the traces to a DVD or external drive locked away.
Is anythng supposed to use the sa account? If not, and you're running SQL 2005 SP2 or higher, you can implement a login trigger to prevent any connections using sa. It's not foolproof, but it's not that easy to circumvent.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 14, 2008 at 7:09 am
So, ignoring all the rest; you're trying to prevent a Domain Administrator accessing "your" SQL Server?
Forget it.
It's a contradiction in terms, not to mention you are trying to fix a staff problem with server configuration.
It's not going to happen.
May 14, 2008 at 8:16 am
Thanks all for the replies and I will look into C2 logging...sa is used for our Financial ERP so I cannot disable this. I doubt the person knows what boards I am part but thanks for the heads up.
I realize this is less technical and more office politics. It really is 'he said, she said' luckily I have another mentor who I can confide in about this situation and ask their assessment about any risk to the databases.
Though as the last reply stated...restricting a domain admin...next to impossible.
I will look into creating seperate backups but it cannot be off the network (then I would be breaking our company policy)
May 14, 2008 at 11:28 am
It really is 'he said, she said'
If you perceived it as "almost stalking", so will others... don't forget to protect your self.;)
--Jeff Moden
May 15, 2008 at 7:57 am
First if that person does not need access to SQL then add their nt account to SQl and do a deny access on them. Even if they are in a group they wont be able to use their own credentials. As far as the SA account if they know the password you cant stop them but if you do as Gail mentioned then you will be able to have a record of them using that account. If there are specific tables you think they are looking at, set some triggers up for those tables. Our domain admins have no access to our SQL servers at all. I think you can get what you need but it will take a little work.
May 15, 2008 at 8:02 am
Wow, this is a dangerous situation for you, your boss and the company you work for. As such I believe you have few options.
1. Document everything and escalate your concerns - terrible as a career move, but maybe good for the company and the stalkees
2. Document everything and wait for the penny to drop - you're fairly protected but no one else is, including the company
3. Document everything and find yourself a better (and more ethical) boss by finding yourself a better company - safest for you professionally but be prepared to be the fall guy in absentia if your stalker screws up data
You'll note I don't think you really have any technical options.
Good luck!
May 15, 2008 at 9:25 am
Thanks again to all...
On most of these items especially creating triggers, that project alone could take me over 3 months to do and plus most of our software is vendor bought...so alterations to schema is not the road I really choose to go down.
i can at least strip the group Domain admins (if there is from any database server)
Again we are small, IT shop of 8 so as you can imagine you trade hats alot. Furthermore this isn't my manager, even though we are small we have a dual-directorship (don't ask) what I could do is address my concerns with my boss (who doesn't know) and not sure where this will lead...
Found out that after the meeting with the stalker, that this will not go to HR. There are people outside our department that know of this situation.
I already have my resume out there as I just feel helpless in this situation.
May 15, 2008 at 9:27 am
There's some good advice above, and documenting is #1.
document your concerns, get your IT director a copy and ask him to sign off. I'd also contact an HR person or your director's boss. You need to be sure that you don't have "two Lone Rangers" operating here.
Be sure you have good backups, and that you're not the only one that knows of them. I've often found that a good backup for "secret" infromation is the CFO or senior accounting person. They can keep secrets, and they can hold the information, even if it's a sealed envelope. I used to give my admin passwords to them, sealed in an envelope, my sig across the flap. Every update required him to give me the old, sealed envelope back to destroy.
You can't operate alone here. If you're concerned about access, use Profiler, filter as best you can, and drop the logs somewhere, even on removable disks (CD-Rs) that you can take offsite or give to the CFO to hold.
The big thing is to protect yourself and that means two factor (or two person) auditing of everything. Don't become the third Lone Ranger yourself.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
May 15, 2008 at 9:29 am
in SQl it is the Builtin admins account that should be removed also.
May 15, 2008 at 9:40 am
I always document to the hilt, now getting the CFO involved..that's funny..considering in the place I work we report directly under the CFO (we have no CIO) and thus our COO keeps trying to break us from the CFO's grasp.
Then the CFO pleads with the CEO to keep us and the CEO caves (dizzy with all the acronyms...)
My place of work is like a soap opera, however I am running out of popcorn and I don't like the ending... 😉
Domain Admins never were a user to any databases (from our ERP down to Citrix) the blackberry server (4 dbs behind the scenes) had Domain Admin group as a logon, I made it public and denied access to the SQL engine
the erp is locked down tight and has been, (that is my #1 priority) yet now I have to change the sa passwords without announcing the reason for the change....
In a small environment that is tricky
May 15, 2008 at 11:42 am
jsheldon (5/15/2008)
Domain Admins never were a user to any databases (from our ERP down to Citrix) the blackberry server (4 dbs behind the scenes) had Domain Admin group as a logon, I made it public and denied access to the SQL engine
Make sure you take BuiltIn\Administrators out of the login list on all servers, after making sure that you have a sysadmin login available.
There are still ways for a local admin to gain access, but it will leave evidence - a couple of service restarts.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 15, 2008 at 11:59 am
Again thanks...Built-in Admin are not part of our security user IDs (and never have) most is locked down
I have changed sa but really what is stopping the person from going to AD, changing my password, then logging into SQL, change 'sa' then do damage
I know you are all wanting to know but it is erratic behavior, more than one person is documenting this and if the manager doesn't watch out and step in two people will be gone..
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply