HiveBrain v1.2.0
Get Started
← Back to all entries
snippetsqlModerate

How to deny access to SQL Server to certain login over SSMS, but allow over .Net SqlClient Data Provider

Submitted by: @import:stackexchange-dba··
0
Viewed 0 times
ssmsprovidersqlbutlogindenyallownethowserver

Problem

We have a situation where Developers do not have any UPDATE permissions, BUT they work with applications and see connection strings -> they know passwords from some SQL accounts (example SQLLogin1) that have UPDATE permissions. Our operations currently are not perfect, and sometimes production data needs to be modified (no GUI for that yet).

Instead of contacting DBA, and asking him to modify the data, Developer would (improperly) use SQL account SQLLogin1 (that has permission to modify the data),
and connect over SQL Server Management Studio to modify the data himself.

DBA can not change password for SQLLogin1 without Developer seeing the new connection string and new password, since the application connection string that uses SQLLogin1 is maintained by Developer.

Question:

Is there a way to deny access to SQLLogin1 SQL login, but only if it is connecting over SSMS?

At the same time if SQLLogin1 is connecting over .Net SqlClient Data Provider (program_name in the sys.dm_exec_sessions), it must be allowed to login.

This way we want to not let Developer connect over SSMS using SQLLogin1, while the application that is using SQLLogin1, would still be able to connect.

Solution

I think there is no reliable solution for your problem since Application Name is modifiable parameter that cam be changed by any user.

Here is how to change it within SSMS:

In Connect to Database Object dialog choose Options, open Additional Connection Parameters and choose any name for Application Name like this:

Now sys.dm_exec_sessions DMV and Program_name() will show you what you passed in your connection string in Application Name parameter:

Context

StackExchange Database Administrators Q#231228, answer score: 17

Revisions (0)

No revisions yet.