SECURITY – Restricting access by Application | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

SECURITY – Restricting access by Application

With MSAccess on the desktops, how can I deny access to a MS SQL database to all MSAccess applications? Or only allow .Net SqlClient Data Provider processes to access the MSSQL DB? thanks
Debbie
Well you can always disable the GUEST login and the users will need an valid password to access the server. Gaurav
Moderator
Man thrives, oddly enough, only in the presence of a challenging environment- L. Ron Hubbard

The views expressed here are those of the author and no one else. There are no warranties as to the reliability or accuracy of anything presented here.
My two cents: 0. Set appropriate permissions in your DB.
1. Include the "application name" in your connection string and then use the APP_NAME system function in T-SQL to check which app is trying to access your database objects. But this means that you have to restrict all access to your DB through stored procedures.
2. Application roles might also be helpful here. Although I am not very enthusiatic about this. HTH Nathan H.O.
Moderator
SQL-Server-Performance.com
1. Disable the Guest login. This needs to be done anwya.
2. Only use Trusted Security.
3. Have each application in .NET run under a different Domain User.
4. Grant the Domain User the appropriate access needed for the application.
MeanOldDBA
[email protected] When life gives you a lemon, fire the DBA.
quote:Originally posted by gaurav_bindlish Well you can always disable the GUEST login and the users will need an valid password to access the server. Gaurav
Moderator
Man thrives, oddly enough, only in the presence of a challenging environment- L. Ron Hubbard

The views expressed here are those of the author and no one else. There are no warranties as to the reliability or accuracy of anything presented here.

??? Gaurav
Moderator
Man thrives, oddly enough, only in the presence of a challenging environment- L. Ron Hubbard

The views expressed here are those of the author and no one else. There are no warranties as to the reliability or accuracy of anything presented here.
]]>