One of the things I like best about VMworld and other events is the constant interaction with the IT community. In doing so, I had one conversation with a Veeam customer that was a good story to share. Basically, his situation was this: an on-demand virtual lab was used to safely test and then adjust the permissions of a catch-all service account.
We’ve all done it, simply assigning too many permissions an account to “make it work” when it comes to provisioning a new system seems like a quick way out of a jam. But, when we have to come back and clean up any over-permissioned accounts; we may be a little weary when it comes to determining the impact of the service account. Before I explain how the virtual lab was used for correcting the service account, let me take a quick moment to explain what the virtual lab is. Veeam Backup & Replication version 5 introduced vPower, which, simply put, allows virtual machines to be run directly from the backup file. We can use this for Instant VM Recovery for the quickest recovery times. And with the help of additional functionality – an automatically managed, isolated “virtual lab” environment – we can leverage vPower to do things like SureBackup verification of backup jobs, item-level recovery (including leveraging the U-AIR wizards) and an on-demand sandbox for situations such as this service account remediation. For the virtual lab capability, the diagram shows how it exists in a generic setting:
There are few things to note. First of all, the virtual lab functionality keeps these virtual machines isolated from production. This is critical in order to not interfere with the production virtual machines as well as other systems within the environment. Secondly, the backup file is kept as read-only during this operation. This is to ensure that the integrity of the backup file is maintained. From a CPU, network and memory perspective, the virtual lab is running from the production vSphere cluster (on a designated host). From a storage perspective, the Veeam backup repository (or backup file) is presented as a virtual NFS datastore. From there, the individual VMs are enumerated, able to be powered on and are placed on a private network (again for isolation).
This is where my conversation with the VMware administrator comes back in. He explained to me how, once these virtual machines are powered on in the isolated environment, he was able to remediate the permissions model of a service account with too many permissions. He did this in the safe area presented by the vPower virtual lab. Further, by including a domain controller in the backup job and virtual lab, he very easily made additional changes to this multi-tiered application. By using the isolated virtual lab, it was very easy for him to go through granular changes in the permissions assigned to the service account, document those changes, test the application and be able to confidently implement the security changes into production.
Do you have a vPower story to share? If so, share it below or let me know: Rick.Vanover@Veeam.com.