quote:The only problem here can be third party software that utilises SQL Server as its security or other repository in order to run. I have come across a few products that prompt to for the SA password, then end up creating a database with no other user but SA, only to spend hours reading documentation and testing to change it.
Where is a link to Part I.
Thanks,
ThomasLL
Outstanding article! Very thorough with great references for further information.
I agree with Brian's post -- that's the most infuriating thing to have applications that demand dbo, or worse, sysadmin access. There is no reason any application (with the exception of admin utilities) should require this level of access. I'm often asked to evaluate software for clients, and this one is a deal-breaker from my point of view.
The Windows world really has to get use to the idea of having to explicitly set permissions to resources required. Windows Server 2003 has done a much better job at forcing you to explicitly set NTFS and Share permissions, and Yukon is moving in the same direction. The problem is that we, as administrators and developers, need to get in the habit of doing this regardless of what the platform forces you to do. This isn't a technology problem, it's a process problem.
OK, my 2 cents, I'll shut up now. Again, great article!
I used to have that same opinion actually but then I had a conversation with someone who has been in software development for several years. My feelings haven't changed, mind you, but I'm not nearly as stubborn about apps that do this.
Consider: Not all companies running a given software package have a DBA full or part-time. If they don't, then the application administrator must be able to create new SQL logins through the application itself. To do this requires sysadmin rights.
Check out http://databasejournal.com/features/mssql/article.php/1473011 for a good discussion on why GreatPlains decided to use the sa account in its application. Yes, it can be turned off. However, it increases workload for the DBA who now has to create SQL accounts by hand.
-- J.T."I may not always know what I'm talking about, and you may not either."
One way we share DTS Packages where I work is to save the package as a .DTF in an NT shared Folder. That way, authorized users can access the package and make revisions or run it individually as necessary...
No need to be a sysadmin because you are opening the DTS Package from the DTF and it appears that you are the author. Just a thought....
