Hi
My RDMS instance is using an AD account (assigned to the application pool), please see at the bottom for the commands we invoke
On my RDMS server , I have registered the database used by the RDMS instance as a SQL Server data source as well. The credentials used in that data source definition have the dbo privileges. I use this setup to perform Schema updates.
Obviously this post will become a documentation page shortly...
I know we can write a single statement per table, but we are quite stringent and only assign permissions depending on what you give in the user permission screen
A last note about deletion, we have history tables that are filled in by triggers on tables, nothing is deleted permanently until you go in Administration - View deleted and do a cleanup.
{0} is replaced by the login name
GRANT SELECT, INSERT, DELETE, UPDATE TO [{0}];
GRANT INSERT ON Connections TO [{0}];
GRANT INSERT ON Attachment TO [{0}];
GRANT INSERT ON Credential TO [{0}];
GRANT DELETE ON Connections TO [{0}];
GRANT DELETE ON Attachment TO [{0}];
GRANT DELETE ON Credential TO [{0}];
GRANT UPDATE ON Connections TO [{0}];
GRANT UPDATE ON Attachment TO [{0}];
GRANT UPDATE ON Credential TO [{0}];
For the administration features, we do
GRANT INSERT, DELETE, UPDATE ON UserInfo TO [{0}];
GRANT INSERT, DELETE, UPDATE ON GroupInfo TO [{0}];
GRANT INSERT, DELETE, UPDATE ON UserGroupInfo TO [{0}];
GRANT INSERT, DELETE, UPDATE ON DatabaseInfo TO [{0}];
Obviously, if you decide to always perform user administration by direct connection to the SQL Datasource, the app pool identity doesn't need those..
My RDMS instance is using an AD account (assigned to the application pool), please see at the bottom for the commands we invoke
On my RDMS server , I have registered the database used by the RDMS instance as a SQL Server data source as well. The credentials used in that data source definition have the dbo privileges. I use this setup to perform Schema updates.
Obviously this post will become a documentation page shortly...
I know we can write a single statement per table, but we are quite stringent and only assign permissions depending on what you give in the user permission screen
A last note about deletion, we have history tables that are filled in by triggers on tables, nothing is deleted permanently until you go in Administration - View deleted and do a cleanup.
{0} is replaced by the login name
GRANT SELECT, INSERT, DELETE, UPDATE TO [{0}];
GRANT INSERT ON Connections TO [{0}];
GRANT INSERT ON Attachment TO [{0}];
GRANT INSERT ON Credential TO [{0}];
GRANT DELETE ON Connections TO [{0}];
GRANT DELETE ON Attachment TO [{0}];
GRANT DELETE ON Credential TO [{0}];
GRANT UPDATE ON Connections TO [{0}];
GRANT UPDATE ON Attachment TO [{0}];
GRANT UPDATE ON Credential TO [{0}];
For the administration features, we do
GRANT INSERT, DELETE, UPDATE ON UserInfo TO [{0}];
GRANT INSERT, DELETE, UPDATE ON GroupInfo TO [{0}];
GRANT INSERT, DELETE, UPDATE ON UserGroupInfo TO [{0}];
GRANT INSERT, DELETE, UPDATE ON DatabaseInfo TO [{0}];
Obviously, if you decide to always perform user administration by direct connection to the SQL Datasource, the app pool identity doesn't need those..