Table of Contents
SRM Permissions
Summary: How to setup SRM permissions to safely work with VMware Site Recovery Manager 5.1.
Date: Around 2012
Refactor: 29 April 2025: Checked links and formatting.
Using Site Recovery Manager brings you great power… and with great power comes great responsibility. With a click on a button you can recover your protected datacenter to your recovery site. But that also increases the chance an accident might happen. To prevent accidents you should implement an access control procedure. I work in an environment where all administrators know each other and are well trained. Usually everybody has full access. For SRM we decided that should change.
Current Situation
First about permissions in Site Recovery Manager 5.1. SRM is not Multisite SSO for vCenter 5.1 enabled, so it has it's own logon and permissions configuration. Short after the installation, for installing and configuring purposes, I set the same permissions in SRM as were in use in vCenter. Also, a service account was added for scripting purposes:
Account or Group | Role / Permission |
---|---|
DOMAIN\Domain Admins | Administrator |
DOMAIN\Server Administrators | Administrator |
DOMAIN\SRV-VCENTER | Administrator |
Note that these settings were configured on both the protected as the recovery site, with the name of the service account as the only exception.
Desired Situation
The problem with the configuration above is that everybody can do everything, all the time. We decided to create two new roles:
- Administrator - NO SRM RECOVERY
- SRM FULL Administrator
The first one would be a clone of the administrator role, except for the removal of the recovery permission, and the second one would have full permissions on SRM, including the recovery permission.
We would also create a new group, which would remain without members, until a disaster recovery occurs. Then the necessary admin accounts would be added to this group:
- DOMAIN\SRM-FAILOVER
Creating Roles
To create the required roles log in to the vSphere Client and follow these steps:
- Go to Home → Roles.
- Right click Administrator and select “Clone”. Rename the new role to “Administrator - NO SRM RECOVERY”
- Right click the new role “Administrator - NO SRM RECOVERY” and select “Edit Role”
- Go to All Privileges → Site Recovery Manager → Recovery Plan → unselect Recovery:
- Then right click the role SRM Administrator and select “Clone”. Rename the new role to “SRM FULL Administrator”
- Right click the new role “SRM FULL Administrator” and select “Edit Role”
- Go to All Privileges → Site Recovery Manager → Select all sub permissions:
Now fill in the permissions as layed out below:
Account or Group | Role / Permission |
---|---|
DOMAIN\Domain Admins | Administrator - NO SRM RECOVERY |
DOMAIN\Server Administrators | Administrator - NO SRM RECOVERY |
DOMAIN\SRM-FAILOVER | SRM FULL Administrator |
DOMAIN\SRV-VCENTER | Administrator |
Again, this should be configured on both sites.
Also note that this setup only protects you from accidental recoveries. Not only is it quite easy to add accounts to the group, editing the roles is also a privilege that is not disabled by this setup.
Also note that group memberships are not updated dynamically in the vSphere Client. Make sure you log out and back in to the vSphere client to make sure you changes take effect.
Test Permissions
First, make sure the DOMAIN\SRM-FAILOVER group is empty. Then login to the vSphere client with an account that is member of the Domain Admins or Server Administrators. Select a recovery plan and click “Recovery”. If everything is setup correctly you'll get this error:
Permission to perform this operation was denied.
If you would add your admin account to the DOMAIN\SRM-FAILOVER group and would logout and back in again you would see this window (be careful!):
Be sure to remove your admin account from DOMAIN\SRM-FAILOVER again and log out from the vSphere client.