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.
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).
- Ensure that each TimeXtender developer also has access to the relevant instances in the TimeXtender Portal.
- One Service Account must be created on the Application Server. This will be used to run the TimeXtender Execution Service and the TimeXtender ODX Server Service.
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.
The Security group created above needs to have Local or Domain Administrator on the Application Server to start and stop the TimeXtender services.
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:
- 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 Analysis Services (if applicable) – server administrator.
Azure SQL Database
The following permissions are needed when using Azure SQL DB as a Target Database:
- Server admin, Azure Active Directory admin or dbmanager role in the master database. If using contained database users, then use the db_owner role.
See this article for more information on Azure SQL Database 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 Target Storage for the MDW you need the following:
- Create SQL Server Login in the Master Database
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>'
The link to Microsoft regarding Azure SQL DB logins no longer exists (404) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-manage-logins%C2%A0%C2%A0
I think the information is now at Adding Users to Your SQL Azure Database | Azure-blog en -updates | Microsoft Azure or Authorize server and database access using logins and user accounts - Azure SQL Database & SQL Managed Instance & Azure Synapse Analytics | Microsoft Learn.
Andrew - E-mergo