Re: Securing Service Accounts - Good Practices

[krymson () gmail com]

Our industry is funny, no? Even something as limited as this is a huge problem and a big discussion. Enter my long 
email! :)

There are two major parts here:
1) Trying to limit down current service accounts that are domain admins.
2) Ongoing good practices for service accounts.


1) Trying to limit down current service accounts that are domain admins.

a) Some service accounts may have a justified reason for running as domain admin. Altiris, anyone? Just keep that 
possibility in mind. 

b) Unless you know everything the service does or have it documented somewhere, you might be best served by limiting 
the account and seeing what breaks. Yes, this is destructive, and you should get buy-in from people who will care, but 
otherwise you could spend lots of your salary trying to define a service account that you can't possibly define without 
wasting money. It might be painful, but the information gained may be worth the cost of a quick password change and 
small service interruption.

c) If you do change the password, monitor your logs for failed login attempts. This should at least point you in the 
direction of a server/app that is depending on that account and/or the permissions of that account.

d) In fact, change the password if you're not already sure who knows it and has access to it. Or if you don't know 
whether it was securely created in the first place! Don't assume it's not "password."




2) Ongoing good practices for service accounts.

a) Be liberal with your use of service accounts. Try to make one service account per function of your apps or systems. 
This means less exposure, more refined limitations you can put on the account, and better auditing if you happen to log 
what those accounts access and such. It should also mitigate exposure/popping of that account. I know, it could mean 
huge amounts of service accounts, but that's the rub, no? You'll have to find out for yourself that, interestingly, 
troubleshooting will eventually become easier with more refined service accounts. :)

b) When creating a service account, start by giving it no rights. Not even Domain User rights. There should be 
references online about NoRights and Service Account roles in AD that you can set up. Start adding rights and 
permissions as needed until the service account does what it needs to do.

c) Document all service accounts. Make sure to track what the purpose is, what permissions it has, and why it needs 
those permissions. The worst thing you can do is create domain admin accounts with no backing documentation on why 
they're domain admin accounts. They could very well be attacker accounts in that regard!

d) You can't always change service account passwords regularly without possibly affecting lots of things. Therefore, 
always at least use excessively large passwords for service accounts. You don't type them in often at all, so there is 
no reason not to make them 36 chars, usually.

e) Track the passwords in something more secure than a text/doc file, like PasswordSafe. Limit access to service 
passwords only to those admins who need to know.

f) When possible, change the service accuont passwords as often as you can without wasting your time. It all depends on 
how powerful the service account is, how well you know the impact of a password change, and the time wasted in changing 
it. If the account is used everywhere, has a huge password that only 2 people know, and is extremely painful to change, 
you might and to just make the password huge and change it very rarely. This is all up to you and is situational, no 
matter what anyone else says. :)

g) Vendors are NOTORIOUS for being cheap and just saying their systems need to be run under domain admin. That is a 
usually a cop-out for engineers who really don't know what permissions are needed. Make a detailed permissions matrix a 
mandatory deliverable for future vendor relations. It it not unreasonable for you to request that of a vendor. Keep in 
mind, some apps really do need high permissions, but make sure that is documented by the vendor.

h) Name your service accounts descriptively. Make sure the actual logon reflects something about what it is used for. 
In my company we name things kinda like PRSVCWEBIISMailSend. This tells me it is production, a service account, part of 
the web application, and is likely the IIS SMTP account. This is just a fictional example, but does stay very 
descriptive.

i) Keep your service accounts organized in a separate OU in AD. This might be obvious, but don't forget it! :)

j) Document, document, document. Include service request tickets, requestors, reasons, approvers, anything you can in 
the account comments section, and augment that elsewhere, say in the service ticket or change manaegment system. Always 
think about how you would search for that account if you had a question about it (i.e. don't forget to record the 
account name exactly in the entry!).

k) Lastly, make an internal policy about service accounts for your team. This can then be referenced to vendors, 
managers, anyone evaluating products for purchase, or even creators of apps who need server service accounts for the 
internal apps they create. You won't get it right the first time, but once you have a policy written down and updated 
over time, you gain a lot of power.


<- snip ->
I'm interested in obtaining some information either from users personal
recommendations or from authorized sources on the subject in regards to
what are the good practices for creating, managing, and securing service
account created in Active Directory. I will give you a scenario that I
have gotten involved in:

I have been working with a company now for a few years, mostly in a
helpdesk style support role, but have worked my way up within the
company in helping with certain responsibilities pertaining to security
which I enjoy. Getting back to the question at hand, it would appear
that previous administrators with the company when being handed the task
of creating service accounts for several of our applications and
appliances decided to take the easy route (of course, also the most
insecure) and assign domain admin privileges to most of these accounts.
Needless to say, when I learned of this, I was pretty shocked as to why
these accounts would be granted such elevated privileges and have
unfiltered access to Active Directory to perform a role that was not in
need of such rights.

We have been tasked with limiting our domain admin group to only
specific infrastructure individuals who need it and removing the service
accounts from this group. The problem we are foreseeing is once we
remove the service accounts from full access privileges, we are
expecting several routines that they were performing to fail.

The grand question here is what is the best practices/guidelines when
encountering this type of solution. Do we remove each service account,
one by one, waiting to see what, if anything, fails and then decide how
to give rights to that account? What about in the future, when creating
and securing new accounts...what are the best guidelines and practices
to go by?

Thanks
-Dave