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 |
|
Blin
Starting Member
36 Posts |
 Posted - 2004-08-31 : 13:47:52
|
| We have a situation that every user can run, update, or delete DTS packages in our organization. DB Users log in using SQL Server authentication, and packages were not built using owner/user passwords.We want to figure out the best way of protecting the packages besides using passwords, so that only authorized users can execute and change the packages. Is it best to set up packages to run off of windows authentication using the local server setting or to use SQL server authentication? My thought is that if we use the local setting, no one but those of us with a windows authentication login could execute the packages. Is it correct? Any suggestions?Thanks,Ben |
|
|
MuadDBA
628 Posts |
Posted - 2004-08-31 : 13:55:45
|
| Windows authentication is better.For securing DTS packages, you shouldn't allow your users to access them directly. Rather, grant them permission to execute a stored procedure which will call the DTSRun utility.Store your DTS packages as structured storage files (.DTS extension) and place them in a secure area on the local server (and make sure this area is backed up!). Lock down the security in that area so it might have global reads, but only certain users will have delete and write permission to the area. When the package is changed, they will edit it and post it back to that secured area, which will be where all of your new stored procedures (see first paragraph) reference the packages. |
 |
|
|
|
|
|
How to secure a DTS package