Database Access and Permission Model for XenDesktop 5

This article describes the SQL Server database access and permission model used by XenDesktop 5.

Background

All runtime access to the central XenDesktop site database is performed by the services running on each controller. These services gain access to the database through their Active Directory machine accounts. This database access is sufficient to allow full day-to-day operation of the site including use of Desktop Studio, Desktop Director, and the service-specific SDKs.

The controller machine accounts and users in the database are granted only the minimum access to the XenDesktop database required for the services to operate.

The use of machine accounts for database access removes the need to securely store SQL logon (SQL authentication) passwords on the controller. It also ensures that only machines that have been configured with appropriate database access at the database server can act as XenDesktop controllers for a particular site.

Use of machine accounts provides a simple and secure model for protecting the critical data in the XenDesktop database. However, the creation and manipulation of the machine account logons at the database server is an inherently privileged operation that falls outside the scope of the permissions granted within the XenDesktop database itself. For this reason, certain key actions on the site are considered privileged administrative operations that require additional database server level permissions not granted to the XenDesktop services themselves; these operations cannot be performed except by a database user with elevated privileges.

The database access performed is summarized in the diagram below:

The normal runtime permissions and administrative permissions used by the XenDesktop site are described separately in the following sections.

Note: Use of SQL logons (SQL authentication) in place of machine account logons for the XenDesktop services is not a supported configuration. The SQL scripts used by Desktop Studio and the SDKs are based on the use of machine account logons. In addition, attempting to use SQL logons (SQL authentication) might lead to the account passwords being trivially exposed through the SDKs.

Database Permission Model

Runtime Permissions

Each XenDesktop service gains access to the database through the local controller’s machine account. All routine Desktop Studio, Desktop Director, and SDK operations go through one of the XenDesktop services and thus no additional machine account logons are required for use of any of those components irrespective of the machine on which they run.

For a controller machine that is not on the same machine as the database server, the detailed database permissions are granted as follows:

The services gain access to the database server through their machine account logon (names of the form ‘DOMAINMACHINE$’). These logons do not need to be members of any server-level roles.

Within the XenDesktop database, the machine logons are mapped one-to-one with a dedicated per-machine user. Each such user has the same name as the logon to which it relates (in other words: ‘DOMAINMACHINE$’).

Each per-machine user is a member of the following XenDesktop-specific database-level roles:

Database Role	Corresponding XenDesktop Service
ADIdentitySchema_ROLE	AD Identity Service
chr_Broker chr_Controller	Broker Service
ConfigurationSchema_ROLE	Central Configuration Service
DesktopUpdateManagerSchema_ROLE	Desktop Update Manager Service
HostingUnitServiceSchema_ROLE	Hosting Management Service
MachinePersonalitySchema_ROLE	Machine Personality Service

Each one of the above roles has the minimum permissions granted to it to allow the corresponding service on the controller to function. These permissions are restricted to execute on stored procedures and read on some tables.

For a controller that is on the same machine as the database server, the model is as above except that the logon and user relate to the local NetworkService account. In this case, both the logon and user names are ‘NT AUTHORITYNETWORK SERVICE’.

Notes:

Administrative Permissions

The permissions required to perform various administrative operations on a XenDesktop 5 database are shown in the table below. Because it is envisaged that these are typically performed by a database administrator, no operation-specific database roles are provided, thus db_owner rights are usually required as shown.

All of these operations can be performed using Desktop Studio, if required. In these cases, a direct connection is made from Desktop Studio to the database server; thus, the Desktop Studio user must either have a database server account that is explicitly a member of the appropriate server roles or be able to provide credentials of an account that is. Such direct database access is only used for the following operations; all other operations go through the underlying XenDesktop services.

Operation	Purpose	Server Roles	Database Roles
Database Creation	Create suitable empty database for use by XenDesktop 5. See note [1] below.	dbcreator
Schema Creation	Create all service-specific database schemas and add first controller to site.	securityadmin	db_owner
Add Controller	Add controller (other than the first) to site.	securityadmin	db_owner
Add Controller (mirror server)	Add controller login to the database server currently in the mirror role of a mirrored XenDesktop database.	securityadmin
Remove Controller	Remove controller from site.	See note [2] below.	db_owner
Schema Update	Apply schema updates/hotfixes.		db_owner

General Notes:

While technically more restrictive, in practice, the securityadmin server role should be treated as equivalent to the sysadmin server role.

Where the above operations are performed using Desktop Studio, the user account must currently explicitly be a member of the sysadmin server role.

The accounts used to perform the above administrative operations are never recorded by the XenDesktop site. An account that was previously used for an operation can subsequently be removed without impacting the site in any way.

Notes:

• When a controller is removed from a site, either directly through Desktop Studio, or using the scripts generated by Desktop Studio or SDK, the controller logon to the database server is not removed. This is to avoid potentially removing a logon being used by non-XenDesktop services on the same machine. The logon must be removed manually if it is no longer required; this requires securityadmin server role membership.

Here’s the link to the original KB article.