February 23, 2010 at 9:29 am
I'd like to open up a discussion about the use of Administrative accounts for DBA's... Does anyone else out there have their network adminstrators now trying to implement additional security?
Our usual domain accounts (no elevated rights) will no longer be able to access any of the SQL Servers, either by RDP or with SSMS. All of our network drives will still be mapped using our normal windows accounts.
Any time we need to do anything SQL related we'll need to 'run as'. If we want to do any kind of release into any environment we'll need to map a drive to the location of the source code (that includes releasing rdl files in SSRS). If we want to do any of the day to day activities of a DBA, we have to use our admin account, which in effect will mean we keep SSMS open all day running under the elevated credentials.
I can't believe that I'm part of the only DBA team who have had to deal with this, but I'd really welcome views from other DBA's as to how they have dealt with working under a tied down environment.
Thanks
Judith
February 23, 2010 at 9:48 am
Mainly, it means you won't be able to do all traditional/normal/required DBA functions without help from the admins.
If, for example, you need to restart the SQL service after a failure, you won't be able to (no RDP). That means more midnight calls to admins will be a definite possibility.
That kind of things has major implications for DR scenarios. Will you be able to control failover/failback situations?
And so on.
Yes, it can be done that way. It's usually not, because it means you, as the DBA, cannot be fully responsible for the databases and their server. (You can't rationally be held responsible for handling situations that you don't have necessary security access for.)
You'll need to work out a list of the scenarios that your limited rights impact, what the impact will be, and what will be needed from the admins in order to handle those scenarios. Then you'll need an SLA statement from them on that subject. It would be best if senior management (CIO at least) signs off on the fact that the DBA(s) won't be held responsible for those situations, the system admins will. (Creation of that list and the request for an SLA may change people's minds on the subject once they realize they might be blamed for "database stuff". Depends on the corporate culture on the blame/responsibility spectrum.)
As for leaving SSMS logged in all day, that's pretty usual. That's what screen savers with login requirements are for. That and locking your workstation if you step away from it. That's no big deal.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 23, 2010 at 11:41 am
It actually sounds like standard Secure Computing/administration requirements. It's back to the age-old observation that the #1 way to get elevation of privilege attacks is to try to "hijack" privileged acocunts which are used as the "main" login on a PC all day.
Assuming your "elevated" login can do all of the things you need to do, it's really going to come down to a simple "transition" pain. It just separates the acocunt you get your e-mail in (i.e. your "local" account) from the one you do administrative work in. And yes - it IS a pain in the butt for a while, but it does make sense.
The split does in fact make it harder to jump credentials along the way. Not much of a consolation, but when it comes down to it, in a few weeks - you won't even notice it.
Wait until they start setting up expiring admin connections (i.e. you have to re-log your admin connections every x or they invalidate themselves.)
----------------------------------------------------------------------------------
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?
February 23, 2010 at 6:14 pm
This was the case when I worked in a large (Fortune 1000) company. we had two accounts, and were restricted from doing things with our regular accounts. It's a pain, but it can work.
I added my mail account to my admin account so I could work. There were times I'd do "too much" on the privileged account, but it prevented issues with things like DR or deployments, as Gus has noted.
February 23, 2010 at 7:40 pm
I have had the opportunity to work in the three types of environments described.
1. 1 account with admin access to Database servers
2. No admin access to database servers - just to SQL server (no restart of services etc)
3. 2 Accounts, 1 admin and 1 normal
It takes time to get used to each of the types of environments. Having two accounts makes sense to me.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
February 23, 2010 at 10:11 pm
I would say one domain account for all SQL Server Services, But don't login using this account for day to day activities use, Use this account only if you need to login to box like applying patches etc. use another group account say Domain\DBAs for day to day activities, add all DBAs to this group. Believe me Server Admins don't like too many domain accounts on servers.
EnjoY!
February 25, 2010 at 2:31 pm
I am a big fan of not allowing an everyday ID to have elevated access to production servers. And, conversely, not allowing the production iD to have rights to a development or acceptance box. Separating the ID's reduces the risk that unauthorized, or untested changes are made to production. And, I'm sure we have all tried to run something against a production box when we really meant to use the development box.
March 1, 2010 at 10:44 am
In the environment where I had separate accounts, it was mainly for security from viruses. We didn't want some trojan or virus to have elevated rights, so the idea was mail, web browsing, was separate from accessing servers.
These days with VMs, I might be tempted to build a VM just to log in with an elevated account, separate from all the other work I do.
April 4, 2010 at 3:21 pm
Steve Jones - Editor (3/1/2010)
In the environment where I had separate accounts, it was mainly for security from viruses. We didn't want some trojan or virus to have elevated rights, so the idea was mail, web browsing, was separate from accessing servers.These days with VMs, I might be tempted to build a VM just to log in with an elevated account, separate from all the other work I do.
I guess something like that's probably the right way to go: in the environment I used to work in the ideal I wanted was an elevated privileges account where I could stop and start in-house staging/production SQL servers, apply updates, run SSMS, and initiate RDP connection to production servers on customer sites (which would require a separate login into the customer domain, of course) but could not browse the web or get email or use FTP or NNTP. And a less elevated account that would give me web, and email, FTP, VS, and full SQL access to development and test environments. What I got (because no-one had time to sort it) was a single elevated account with full access to everything in house and the ability to initiate RDP connections, which was considerably less secure because web, FTP, and Email are dangerous. By running high quality AV and malware detection, plus an extremely good antispyware product that included some registry monitoring, plus our own registry monitoring stuff, and some additional protective stuff on desktops we survived without disaster, but I think we were lucky.
Tom
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply