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. All was well until there was a sudden need to change passwords for all resource accounts. Being a new implementation, the customer had no idea 1) what services have account dependencies and 2) where account updates need to be preformed. They had a right to be confused — neither of us could find a comprehensive reference to this information (sure, we could have documented everything during build-out, but we all know how that goes). And that brings me to the objective of this post…it’s not to suggest ways to manage your accounts and passwords, but rather to provide a reference to where passwords edits would need to be made in the vCloud stack.
The VMware vCloud stack is all about interoperability and uses several points of authentication to communicate with various components in the solution. Per best practice, I recommend creating dedicated service accounts for each major component. In an enterprise vCloud deployment this may include vCloud Director, vCloud Request Manager, vShield Manager, vCenter Chargeback, vCenter Operations, vCenter Orchestrator, vCloud Connector, and the core vSphere components. Even if you choose to use a single service account for the entire stack (vs. per component), there are a dozen or so locations that would require an edit once that account’s password is changed. I keep a [password-protected] cheat sheet of all my resource accounts, passwords, and expirations…with reminders set appropriately. I’ve seen others use password lockers, vaults, and even smartphone apps for reference. All good methods…just make sure they are well secured.
The following is a list of vCloud components, their relationship to other services in the stack, and the account/password location(s) that would need to be updated if/when you make resource account changes…
vCloud Director: vCenter
Location: vCD -> Manage & Manager -> vCenters -> vCenter Properties (right-click on vCenter)
vCloud Director: Active Directory / LDAP Connector
Location: vCD -> Administration -> LDAP
vCloud Director: SMTP Settings
Location: vCD -> Administration -> Email
vCloud Request Manager: Active Directory
Location: vRM Admin -> Integration -> Sources -> Cloud Director (this might actually be using the vCD local admin account)
vCloud Request Manager: vCloud Director
Location: vRM Admin -> Integration -> Sources -> Active Directory
vShield Manager: vCenter
Location: vCenter -> Home -> vShield (under “Solutions and Applications”) -> Settings & Reports -> Configuration tab