SQL Server with custom login: permissions for the underlying SQL User?

... me too. I have the same question, not clear answers yet.

Hello,

Very relevant question here.
As you probably already understood, this Authentication model will require two levels of authentication ; At the database level, and at the RDM level.
This kind of setup will have nice advantages, such as limited amount of database users (only 2 are needed), and users don't actually have these database credentials.
On the database side, you will need 1 db_owner (let's call it VaultOwner) account to perform the database upgrades.
The second account (Let's call it VaultRunner) is kind of optional, but recommended, should be member of db_datareader, and a set of privileges should be Granted to it.
Since these privileges can change from a version to another, we prefer not to publish them.
Please contact the support (ticket@devolutions.net) to get the script to define them.
Once these accounts are defined on the database server, Custom (Devolutions) users will be able to login the data source with the proper configuration.
**See the attachment CustomLoginDSConfig**
To distribute the data source configuration to users without communicating the database credentials, configure it once, with the VaultRunner Credentials, check the "Allways ask Password" and "Allow change username" checkboxes, and leave "Username" and "Password" fields empty. You can then click on "Test Database" and confirm it works (this will only test the database connectivity to the database). Click OK to save this "template".

You can the Export the .RDD file by clicking the export button of the data sources interface **See attachment DataSourceExport** and distribute this file to users.

I hope this is what you were looking for!

Hello,

Thanks. I'll contact technical support for the privileges.

Is it possible in Custom login to use a user that have authentication type Domain instead of Custom (Devolutions) ?

Hello,

Custom Users are managed directly within the database, making them unverifiable at the domain level.

You will need to use Database users with "Integrated Security (Active Directory)" in order to be able to authenticate against Active Directory.

I hope this helps.

Best regards,