The purpose is to avoid the owner rights MSSQL

Do you not create users using our User Management feature? It will grant the proper permissions.

In our setup, all users are accessing the database through Remote Desktop Manager Server, and RDMS is accessing the SQL database with an account that has control permissions only, i.e. DDL and DML queries are allowed. That works fine for us.

Our goal is to be able to run with only DML access rights, but that requires any database modifications to be performed by either the installer or the client when it is first run. We have yet to perform our first application upgrade, so no definite answer on that.

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..

Thank you ..

Obviously, if you decide to always perform user administration by direct connection to the SQL Datasource, the app pool identity doesn't need those ?

Thank you .
the next version will be able to reduce sql rights with active directory account?

Hello,

I'm not sure I understand your question(s). Can you describe the desired scenario?

Thank you,
edited by mcote on 10/25/2014