July 24, 2008 at 4:22 pm
Comments posted to this topic are about the item Service Accounts
July 24, 2008 at 10:41 pm
yeah I do something similar, my standard method is to randomly type characters (letters, numbers and shift character) until I fill up a line of text in notepad, usually around 60-80 chars. Should be fairly secure 😛
July 24, 2008 at 10:54 pm
KeePass is a handy tool for generating (and storing) complicated passwords. It's free, multiplatform and opensource. I have it on my main PC and my windows mobile phone. It can also be run directly from USB key.
July 25, 2008 at 12:40 am
hi,
I usually use same domain account for every Sql Server in environment, but separate service account for Sql Server & Agent service. Both accounts have different generated strong passwords. I need that passwords for every new server build, so that's the only reason I need to store them in safe place like key pass.
I think that I should add that in most of the installations both service accounts don’t have administrator rights on box.
I do not see any other reason; did you see any weak approach in this?
July 25, 2008 at 1:33 am
Lazarusek (7/25/2008)
hi,...
I do not see any other reason; did you see any weak approach in this?
I think the problem with that approach is that if someone exploits one of your sql instances they have exploited all of them since they can openquery to any server they know and will be doing so as the service account (sa).
With seperate domain accounts for each server if one is exploited the expoit goes no further than that particular instance, any access on other sql servers in the domain will have been specifically granted by you as a remote_login as part of that application's requirements.
July 25, 2008 at 1:53 am
Agree - keep each service in each instance with it's own account and unique password - a bit more work when installing, but I think it's worth to make a best effort.
July 25, 2008 at 4:44 am
Steve,
Most places I've been try and minimize the number of service accounts, so typically they would use a sqlservice account for a couple of production servers and a separate account for dev and a separate account for test.
I've also worked for places where they use the same service account for IIS, SQL, COM+... bad idea when someone types in the wrong password somewhere when setting up a service and you have to track it down when all your SQL boxes are having issues.
When I think back it's rare I've needed the password again after setting up SQL server. Interesting concept of not keeping the password.
We also use keypass, it's a neat little utility...
Mark
July 25, 2008 at 6:27 am
Nick Beagley (7/24/2008)
KeePass is a handy tool for generating (and storing) complicated passwords. It's free, multiplatform and opensource. I have it on my main PC and my windows mobile phone. It can also be run directly from USB key.
I use KeyPass too. One database for personal stuff and one for work. Great program IMHO.
Standard disclaimer about not having any affiliation with KeyPass. 😉
We keep the passwords because we sometimes need to test access to network resources and a easy way to do that is to log-on as the service account.
We also use Outlook distribution groups so we have to set them up using the Exchange profile for the SQL Server agent account and that means we have to log-on as the agent.
July 25, 2008 at 8:21 am
I'm about to change the service accounts setup, and I'm thinking about using GUID's as passwords. These should be hard to remember 🙂
I'll store them in a password agent in case I need to reinstall the server.
July 25, 2008 at 9:18 am
I make the service account passwords long and random so hard to break but I do record them. Reasons being
If you do ever need to change the password you need to know the current one to do it
If you ever have to reinstall the sql instance you can do so with same service account quickly and easily, thus entirely re-producing your environment. That could be useful if you had jobs running under service account or this instance was taking part in mirroring\log shipping and was paired with another instance running under same account. Its rare but it happens.
---------------------------------------------------------------------
July 25, 2008 at 9:24 am
george sibbald (7/25/2008)
...If you do ever need to change the password you need to know the current one to do it...
If you use the admin tools, you don't need the current password to change the password.
July 25, 2008 at 9:27 am
We have not used service account for a time and other times have used them a ton. We tend to keep them around but under wraps. We have needed them two or five times.
I use to administer an installation of DB2 and had to keep the service account handy in those days. Cannot remember why but from time to time I had to use it.
Miles...
Not all gray hairs are Dinosaurs!
July 25, 2008 at 9:37 am
Agreed - keepass generate&save is the way to go.
July 25, 2008 at 10:06 am
Thanks for the info about keepass. I hadn't heard of it before, and I had resorted to keeping a password protected Excel spreadsheet of my passwords for various sites (just too many variations being required now and too many places where I am accessing on-line secure sites).
July 25, 2008 at 2:07 pm
Passwords are a double edged sword. Sure, they're great if they are used properly. But, used as a weapon, they can be deadly.
It took San Francisco for a "loop" when their employee (now confined with a $5M bail) invented some great passwords which CISCO Systems couldn't even crack.
I would say, yes; use them properly.
- wlt.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply