Preventing Enterprise Manager access from Windows users

Hello,
Scenario: SQL 2000 or 2005 server in an ADS domain. ADS groups are created
as SQL logins, and those logins are created as database users with datareade
r
and/or datawriter roles to a specific database. An intranet web site is
created to allow the ADS users in those ADS groups access to the data.
Problem: How do I prevent the ADS users in those ADS groups from running
Enterprise Manager (or creating their own ODBC connections, etc.) and messin
g
with my database? Or, put another way, how do I prevent the users from using
their own interface to the database?
Thanks much,
-TonyA common practice for something like this would be too...
1. Create Stored Procedures that the application uses to manipulate data.
2. Assign those groups Execute Permissions on the Stored Procedures.
3. Deny Data Reader and Data Writer to those groups.
If you are using ADHOC in your program this is going to be a little tougher.
What do you think?
/*
Warren Brunk - MCITP - SQL 2005, MCDBA
www.techintsolutions.com
*/
"Tony" <Tony@.discussions.microsoft.com> wrote in message
news:ADF6BDE5-11D7-496E-994D-F9B56EF645E3@.microsoft.com...
> Hello,
> Scenario: SQL 2000 or 2005 server in an ADS domain. ADS groups are created
> as SQL logins, and those logins are created as database users with
> datareader
> and/or datawriter roles to a specific database. An intranet web site is
> created to allow the ADS users in those ADS groups access to the data.
> Problem: How do I prevent the ADS users in those ADS groups from running
> Enterprise Manager (or creating their own ODBC connections, etc.) and
> messing
> with my database? Or, put another way, how do I prevent the users from
> using
> their own interface to the database?
> Thanks much,
> -Tony
>|||Warren,
Thanks for the info. That does sound like a good solution. I'm assuming this
would allow users to run Enterprise Manager and see my databases and objects
listed, but not interact with them.
BTW, these applications are web apps using .net. So, perhaps another
alternative would be for me to autherize and authenticate users to the web
site using IIS and ADS groups, then use a SQL login and password (encrypted
in the web.config file) to handle db access. Adding your suggestion to this,
I could restrict the SQL login to execute only the needed sprocs.
Seems like this would prevent any access to my database by those ADS users
via Enterprise Manager or whatever. If the SQL login should be hacked, at
least it would only allow execute on the sprocs and nothing else.
Thanks,
-Tony
"Warren Brunk" wrote:

> A common practice for something like this would be too...
> 1. Create Stored Procedures that the application uses to manipulate data.
> 2. Assign those groups Execute Permissions on the Stored Procedures.
> 3. Deny Data Reader and Data Writer to those groups.
> If you are using ADHOC in your program this is going to be a little toughe
r.
> What do you think?
> --
> /*
> Warren Brunk - MCITP - SQL 2005, MCDBA
> www.techintsolutions.com
> */
>
> "Tony" <Tony@.discussions.microsoft.com> wrote in message
> news:ADF6BDE5-11D7-496E-994D-F9B56EF645E3@.microsoft.com...
>
>|||Hello Tony
Please drop me a note if the following description sounds interesting to
you.
Best regards
Adrian
Here we go:
Corrupt users and compromised user-accounts, cf Phishing, account for the
majority of attacks in the commercial world. We present a two-stage
anti-corruption system (ACS) for database servers that, in the first stage,
makes it very hard to gain access to a database with an unauthorised client
application or from an unauthorised client PC and, in the second stage,
provides
early precise hints on users performing suspicious activities. Our first
implementation of the ACS is for the MS SQL Server 2000. It uses only
documented
functions and relies completely on mechanisms and data already provided by
the
database server. Its smooth and efficient operation for several months in a
middle-sized decentralised company proves it a valuable addition to the pool
of
security measures.
"Tony" <Tony@.discussions.microsoft.com> wrote in message
news:5D786B85-382F-49DD-8CE8-3B8A77DB8EF4@.microsoft.com...[vbcol=seagreen]
> Warren,
> Thanks for the info. That does sound like a good solution. I'm assuming
> this
> would allow users to run Enterprise Manager and see my databases and
> objects
> listed, but not interact with them.
> BTW, these applications are web apps using .net. So, perhaps another
> alternative would be for me to autherize and authenticate users to the web
> site using IIS and ADS groups, then use a SQL login and password
> (encrypted
> in the web.config file) to handle db access. Adding your suggestion to
> this,
> I could restrict the SQL login to execute only the needed sprocs.
> Seems like this would prevent any access to my database by those ADS users
> via Enterprise Manager or whatever. If the SQL login should be hacked, at
> least it would only allow execute on the sprocs and nothing else.
> Thanks,
> -Tony
>
> "Warren Brunk" wrote:
>