Note: There is an updated version of this article, which applies to the next generation of TimeXtender.
For TimeXtender to ingests data from sources and write data to the target data storages it must have the proper permissions. This is done by configuring users accounts within a security group and then providing that security group the necessary permissions below.
Accounts
User Accounts
Identify and/or create the following user accounts. For Cloud deployment, Azure Active Directory (AAD), is recommended. If utilizing Azure Analysis Services then Azure Active Directory is required. For On-Premise deployments, Active Directory (AD) is recommended, but not required.
- One user account for each TimeXtender developer (you may already have these in place).
- One Service Account must be created for each “non-development” environment. These will be used to run the TimeXtender Scheduler Service, TimeXtender Server Service, and the TimeXtender ODX Server Service.
Security Group
Since you will need to provide the same permissions to any users working on TimeXtender as well as the service accounts running TimeXtender services, will make it easier create and manager permissions for all users at once using a Security Group.
Create an Active Directory (AD) Security Group called TXDevelopers (or similar) and add the user accounts identified above.
Permissions
Application Server
The Security group created above needs to have Local or Domain Administrator on the Application Server to start and stop the TimeXtender services.
Project Repository
The project repository is a SQL Database (in Azure on On-Prem) that stores the metadata used for TimeXtender projects. If you choose to use Windows or Active Directory Authentication for connecting to your project repository, one of the below permissions must be applied to the project repository database.
SQL Server(On-Premise) or Azure SQL Managed Instance Repository
sysadmin or dbOwner. Note that if using dbOwner instead of sysAdmin, a user account with at least dbCreator rights must log in and create the database.
Azure SQL Database Repository
Server admin, Azure Active Directory admin or dbmanager role in the master database. If hosting the project repository in Azure SQL DB then a SQL account is required. If using contained database users, then use the db_owner role.
Source Databases
If you choose to use Windows or Active Directory Authentication for connecting to your SQL data sources, the "Log on As" user for the ODX Server Service must have READ permissions on each SQL data source. Alternatively, SQL authentication may also be used, in which case, the permission does not need to be provided to the user or security group.
Target Data Platforms
Configure the below permissions for the Target data platforms in your chosen environment architecture.
SQL Server (On-Premise) or Azure SQL Managed Instance
The following permissions are needed when using SQL Server or Azure SQL Managed Instance as a Target Database or Project Repository:
- sysadmin or dbOwner. Note that if using dbOwner instead of sysAdmin, a user account with at least dbCreator rights must log in and create the database.
- SQL Server Integration Services (if applicable) – db_ssisadmin on msdb system database.
- SQL Server Analysis Services (if applicable) – server administrator.
Azure SQL Database
The following permissions are needed when using Azure SQL DB as a Target Database or Repository:
- Server admin, Azure Active Directory admin or dbmanager role in the master database. If hosting the project repository in Azure SQL DB then a SQL account is required. If using contained database users, then use the db_owner role.
See the following article for more information on Azure SQL Database logins: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-manage-logins
Azure Analysis Services
The following permissions are needed when using Azure Analysis Services you need you need an App Registration (Service Principle) with the Analysis Services Administrator role on the server.
Azure Data Lake
To use Azure Data Lake as the ODX Storage you need an App Registration (Service Principle) with the Owner role on the Storage Account
Azure Data Factory
To use Azure Data Factory for data movement you need an App Registration (Service Principle) with the Data Factory Contributor role on the Azure Resource.
Azure Synapse Analytics - Dedicated SQL Pool
To use a Dedicated SQL Pool as the Targe Storage for the MDW you need the following:
- Create SQL Server Login in the Master Database
USE MASTER
CREATE LOGIN <LOGINNAME> WITH PASSWORD = 'STRONGPASSWORD'; - Create User in the desired Data Warehouse
USE <Insert Database Name Here>
CREATE USER <USERNAME> FROM LOGIN <LOGINNAME>; - Assign user the db_owner permission in the Data Warehouse
EXEC sp_addrolemember 'db_owner', '<USERNAME>'
2 Comments