What are some best practices to manage service accounts?

In our environment, we do not have a way to manage service accounts. Should they be managed to where each application has it's own service account? Should the service account have a generic password? How should we share this amongst our team so that if anyone need to know the password for these account, they have a way of accessing it? Should we go with a password manager program? If so, which one out there is good?
joukiejoukAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

NinjaStyle82Systems AdministratorCommented:
What Kanti linked is for Managed Service Accounts, which is a really cool windows feature, and definitely the most secure way to use a service account. However this is not always applicable.

What we do, and i think mileage will vary based on who you ask, is create an account for a specific service with least amount of privilege required to do their tasks. We then use a password protected Access database to store service account passwords on a locked down share on our file server. I understand that people will take issue with this, as it is in a way keys to the castle, and is not entirely secure. It does however give the flexibility to change the passwords and not use a well known admin password for these services that can get out easily.

The thing is you need to sometime juggle security with manageability. If you can afford to randomly generate passwords monthly, then store them in an encrypted file, on an encrypted drive, in a safe in a secure room, that would be ideal. No one does that.
Will SzymkowskiSenior Solution ArchitectCommented:
Managed Service Accounts have limitations. Managed Service Accounts are basically a computer object in active direcotry that you can use as a service account. Most applications do not play nice with these types of service accounts.

If you want more info on Managed Service Accounts i suggest you look at the Active Direcotory Team Blog for additional details.
http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx

How I would proceed with this is the following...
- Create an OU called Special Accounts or Service Accounts (in your active directory environment)
- Create individual service accounts for each APPLICATION that requires one
- Have each service account prefixed withe "svc_" i.e. svc_sharepoint (this is so that you can easily identify between regular accounts and services accounts
- Create a detailed description as to what the service account does/use
- On each service account go to the properties and select Logon Hours and only allow the service account to logon/run during specific hours when needed
- If you have 2008 Forest/Domain functional level setup a PSO / Fine Grained Password Policy for all your services account with a 15+ character password pointing to a Group or the OU where all of the service accounts reside
- purchase something like Password Manager Pro (great product) which acts as a password vault. This software has full auditing and SSL encryption. You can also assign passwords to different users for viewing and it also has automatic password update if needed as well.

Password Manager Pro
https://www.manageengine.com/products/passwordmanagerpro/

The steps above ensure flexibility a long with security around service accounts.

Will.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

McKnifeCommented:
I advise you to become aware what that password handling is about and why you would even want to care.
Normally, services run as the system account "system". The account has a password (vastly long and complex) managed by the computer itself, so every 30 days, the pw is changed. On domain joined computers, this is an active directory account even, so it can interact with the network.
Normally, there is no need to use anything but "system". In well-secured environments, you might consider not to use the (highly privileged) system account, because if some hacker is able to attack a service and gain control of it, he has full system access at once. So the idea of managed service accounts came up. These change their passwords automatically as well, but are not as strong as "system". So this IS the best practice for secured environments.

Will has written "Most applications do not play nice with these types of service accounts." - I hope he will explain, I am not aware of that and I am pretty sure that "most" is a little exaggerated.
NinjaStyle82Systems AdministratorCommented:
Managed service accounts, local system account and domain service accounts are entirely different concepts and serve different purposes. A domain service account is required when an application needs domain permission either to see users, computers, groups, etc. In some cases they even need permission to modify these things. When Read is the only required permission, a normal domain user account will suffice. In some cases you can use the local system account for the required domain permission, like in SCCM, where you can make the SCCM server itself a domain admin.

If the server is not running Windows usually the only option is an actual domain account.

Managed service accounts are really only applicable when they have been designed to support this type of account. Some Microsoft products support it, most things don't.
McKnifeCommented:
"Managed service accounts are really only applicable when they have been designed to support this type of account. Some Microsoft products support it, most things don't." - sounds interesting. Have you got examples of instances where service accounts cannot be used and also an explanation why? I wonder why assigning required permissions/privileges to these accounts wouldn't suffice in any case.
NinjaStyle82Systems AdministratorCommented:
McKnife, not sure why you are arguing with me about something entirely different from the question, but here you go.

Managed Service Accounts are literally for windows services, they do not work for any application that does not run as a service. or for that matter is not running Windows (like a Linux appliance for example).

This link states that MSAs are not supported on Task Scheduler and SQL for example:
https://technet.microsoft.com/en-us/library/ff641729(v=ws.10).aspx#BKMK_Supported_technologies

This link says this about the limitations of MSAs:
http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx

The supportability of an MSA is determined by the component, not Windows – Just because you can configure an MSA on a service doesn’t mean that the folks who make that service support the configuration.
McKnifeCommented:
Not arguing. I thought we were talking about services here, not some kind of runas to work interatively with different credentials. joukiejouk, how about it, where are you using those?
joukiejoukAuthor Commented:
Can one service account be used to run another application on another server? Here is my scenario. We are staging a new EPO server from McAfee. We have our current EPO environment using a manage service account. For the new server we must use a service account to run the EPO application. Can we use the same manage service account that we are currently using for our current EPO environment? Will that cause any conflicts? Is that best practice?
NinjaStyle82Systems AdministratorCommented:
You can't use the same MSA on two servers. However if you are using server 2012 R2 you can use the new group MSAs.

See for more info:

https://technet.microsoft.com/en-us/library/Hh831782.aspx

If that's not an option you can just make a second MSA for the other server.
joukiejoukAuthor Commented:
The currently managed service account is in a domain and is not a local service account. The current managed service account is a member of domain admins. That said, can it still be used for the second server to run ePO application or will there be conflicts?
NinjaStyle82Systems AdministratorCommented:
managed service accounts are by definition a member of the domain. if it is in fact a MSA, and not a regular user account, it can only be used on one computer. this was only changed in Server 2012 with gMSA (group managed service accounts).

If the account that is currently signing in to the service is "domain\account$" then it is a MSA, if not, it is likely just a regular user account with a regular password. if its a regular account you can use it on multiple computers without a problem.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.