Managing vCloud Resource Accounts

Using dedicated resource accounts to authenticate server and network services has been a best practice for as long as I’ve been in IT. This guideline adds security, interoperability, and governance to your deployed applications, independent of standard user (or admin) accounts. We understand why it’s good to follow these guidelines but if you’re anything like me, maintaining all the resource accounts, passwords, and the services they run can become a bit challenging over time. Rather than create an account and unique password per service, some admins use the same one for everything – windows/linux services, logins, UI’s, connectors, you name it. Although this adds a bit of convenience, it’s a BAD idea from a security perspective. Here’s the real challenge – keeping track of all those accounts, where they are plugged in, and the password cycle they’re on. This can become quite the headache; especially considering an expired or changed password can result in a significant service outage…another reason to avoid a single service account (i.e. single point of failure).

I recently had a customer run into a very similar problem. This customer has 5 independent vCloud implementations across the enterprise, each environment with a single resource account used for the entire stack.