Tintri Knowledge Base > 002 Knowledge Article Database > VMstore, Hyper-V and RBAC

VMstore, Hyper-V and RBAC

Applies To


Product(s): All

Product Version(s): 3.1.1 and later



With Hyper-V support in VMstore comes a requirement to support and manage a complex set of user-based security access controls. As much as possible, this management has been rolled into existing VMstore functionality, including the Role-Based Access Control (RBAC) functionality that was added in VMstore v3.0. This article hopes to detail the relationship between relevant Hyper-V functionality and the RBAC functionality in VMstore.

VMstore RBAC Roles

The VMStore contains a set of (currently four) statically-defined roles. Whilst detailed elsewhere, a quick summary of these roles is as follows:

  1. Super Admin -- members of Active Directory groups mapped to this role may perform all VMstore management tasks through the UI or REST API
  2. Storage Admin -- members of Active Directory groups mapped to this role may perform all VMstore management tasks except for those that deal with security, such as adding and modifying users or role mappings.
  3. Read-Only Users -- members of Active Directory groups mapped to this role may perform VMstore operations that don't modify anything and may not view security-related information.
  4. Service Account -- members of Active Directory groups mapped to this role may perform the same VMstore management operations as those in the Super Admins group, but not interactively through the UI -- only by API.

Users that do not belong to any group that is assigned a VMstore role will not be allowed to perform any operation at all.

For users that are members of multiple groups that each have an assigned role, the role with the highest privilege will apply.


SCVMM uses the SMI-S protocol to manage shares and security on the VMstore. SMI-S authentication happens with SCVMM passing the username and password of a run-as account that exists in Active Directory. On the VMstore side, the SMI-S provider employs the same access control mechanism that the REST API does, so all of the same role-mapping rules apply.

The user account used with SMI-S must belong to an Active Directory group that has been mapped to a role within the VMstore. To get the most out of the SMI-S functionality, this group would be assigned the Service Account role listed above.

Where SCVMM is performing SMI-S operations and warns about credentials or access controls, checking the role mappings would be the first step. Bear in mind too that SCVMM may access VMstore using the SMB protocol when hosting a library share. In the SMB case, see the section below on SMB and RBAC.


The SMB protocol (and Hyper-V's use of it) includes support for user-based access control at the share level, the directory level and the file level. There are also a set of user-based privileges that apply to NAS appliances like VMstore. This section details those in relation to VMstore RBAC.


Users, groups and computers in the SMB implementation on VMstore are identified by a Security ID (SID) just as they are on Windows systems. In order to use the existing RBAC functionality, each VMstore has been assigned a SID. These are as follows:

  1. Super Admins -- S-1-5-32-544 (This is the same well-known SID as BUILTIN\Administrators on all Windows systems)
  2. Storage Admins -- S-1-5-32-998
  3. Read-Only Users -- S-1-5-32-999
  4. Service Account -- S-1-5-32-997

These SIDs are all self-contained within VMstore and should not have any direct impact on the end user, but the details do have some indirect effects on other aspects of the Windows security model.

SMB Privileges

Windows systems have a set of privileges or capabilities that can be assigned to a given user or group that allow them to perform special tasks within the system. For Microsoft systems, these are documented by Microsoft, but include the ability to take ownership of files and the ability to backup or restore files or directories regardless of the file security permissions.

Some of these privileges apply to VMstore's SMB implementation too and have been implemented as a way to maintain compatibility with some applications that rely on this extended functionality. The privileges supported by VMstore today are:

  • SeBackupPrivilege -- the ability to backup files regardless of permissions
  • SeRestorePrivilege -- the ability to restore files regardless of permissions
  • SeAuditPrivilege -- the ability to set audit control lists on files
  • SeTakeOwnershipPrivilege -- the ability to take ownership of a file regardless of permissions

As with the BUILTIN\Administrators local group on a Windows system, the Super Admins role on VMstore comes with all four of these privileges. Therefore, any Active Directory user that is a member of an Active Directory group that is assigned the VMstore Super Admins role will be granted these privileges when accessing VMstore over SMB. This is required for certain backup applications to work for example.

No other role is currently assigned any of these privileges and they cannot currently be manually assigned to a role.

SMB Share Permissions

Shares created by SCVMM over SMI-S will have the share-level permissions set by SCVMM. These can be viewed in the VMstore UI under the Hyper-V Shares settings tab and may be modified using SCVMM.

The default share on VMstore (called hyperv) comes pre-created and shares out the root of the SMB filesystem. The set of permissions at this share level are:

  1. Super Admins -- Full Control
  2. Service Account -- Full Control

Note that this only restricts which users may connect to this share and file permissions (see below) still apply in a most-restrictive fashion. If a user is assigned the Service Account role, they will be able to map to the share, but will only be able to read and modify files if the file permissions allow it.

SMB Directory and File Permissions

All files and directories under the SMB filesystem space have a security descriptor that contains a set of permissions. Under normal operation these will be set specifically by Hyper-V and SCVMM when created or updated. In cases where no permissions are set, the default set apply. That default set consists of:

  1. Super Admins role gets full control
  2. Service Account role gets read, execute and create
  3. Creator Owner special SMB SID gets full control
Last modified



This page has no classifications.