Reputation: 3
I have around 20 custom databases on a SQL Server 2014, and I have a use case where I want a subset of logins (defined by a server level role) to have the permission "CONNECT ANY DATABASE". On all the 20 custom databases, the public role and the guest user don't have any permissions, so this works fine. Except the built in SSISDB database that SSIS use. It has a bunch of EXECUTE and SELECT permissions granted to the public role. I don't want my users to have access to this. Is there an intelligent way to solve this? Why does the public role in ssisdb have so many permissions in the first place?
Upvotes: 0
Views: 362
Reputation: 3
After inspecting the views that are granted select-permissions on the public role, I see that they are dynamic views that don't return any rows if you don't have any additional permissions in the ssisdb. So I'm concluding that there is no harm letting the users run select-statements on the views in the SSISD database.
Upvotes: 0