Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
standers
Starting Member
4 Posts |
Posted - 2009-05-26 : 13:40:47
|
there is an old access project floating around my office which connects to our SQL server and basically gives direct table access to a lot of folks that I dont want to have it. I have been developing user interfaces for our internal users to update data in a safer manner, and have directed them to use the new interfaces rather than the old access app, however if it is still available to them, they will continue to use it (they continue to come to me with questions about why the old app doesnt work the way it used to regardless of how many times I tell them to stop using it...) The access app connects to the sql server using Windows Authentication, but the new interfaces do as well... so I cant grant/deny access based on username. The only thing I see in the connection that could distinguish users using the access app vs the new interfaces is the hostname (in Access, its "Workstation ID"). When this thing was first designed, the Workstation ID was prepopulated, and as such, when any of our users run the app, I can see it in the host field of the current process info in my SQL 2000 server. I know there must be a way to do this, but I can find it... How can I deny access to a database via hostname/workstationID?BTW - yes, I know that if the users were really trying, they could get around that by changing the hostname, but I dont believe most of them would know where that is, or how to change it. Plus, once they try a few times to connect and get denied, they will see that their access has been removed, and stop trying to use the old app (I hope!)Thanks! |
|
mcrowley
Aged Yak Warrior
771 Posts |
Posted - 2009-05-26 : 14:57:36
|
In SQL 2000 you are kind of stuck. You could potentially make a political deal out of this, but that will require that you enlist the aid of someone with more clout over these business people. In order to do this, you could set up SQL Profiler to capture when they connect, and even what they do (filter this trace on Workstation ID, or Application Name to strip out the "good" traffic). Present this to your business contact, and see if fur can fly. It may be, however, that you will have to wait for someone to really mess up the data in order to get that kind of backing from the business. It is sometimes hard for them to see potential loss due to lax security, especially in smaller companies. |
|
|
|
|
|
|
|