SQLServerCentral / Discuss Content Posted by Chris Kempster / Article Discussions / Article Discussions by Author / SQL Server Security Part 2 / Latest Posts

RE: SQL Server Security Part 2

tymberwyld — Mon, 23 Jul 2007 12:00:00 GMT

I have a question (and please excuse me if it's been asked before). If I am using SSL between a WebClient and WebServer, is it possible to intercept the communication between the WebServer and SQL Server Database? I would think that the database communication is running on the server end and that the only thing the client can see or intercept would be things that it has a certificate for.Can someone shed some light on this? Thanks!

RE: SQL Server Security Part 2

Liliya Huff — Thu, 09 Mar 2006 14:26:00 GMT

yes. dynamic sql in sp works as well. wery easy to test.

RE: SQL Server Security Part 2

IsaacGoGo — Wed, 09 Nov 2005 09:25:00 GMT

Chris - this is an excellent article. Great work!

RE: SQL Server Security Part 2

James Luetkehoelter — Fri, 04 Nov 2005 10:06:00 GMT

For those of you new to the article (or others of Chris has posted), he's outstanding. Check out his other articles. He also has some excellent e-books on his website on disaster recovery (an issue dear and unfortunately near to my heart).

Keep discussing and debating --it's the only way we truly learn.

RE: SQL Server Security Part 2

Yelena Varshal — Fri, 04 Nov 2005 09:09:00 GMT

The article mentioned denying somethings like syscomments access to PUBLIC. Everyone is a member of Public, will SPs work after that?

Otherwise the article is very good. Chris even did not forget to remind us to take care of cleaning audit tables having in mind the amount of information in them

Yelena

RE: SQL Server Security Part 2

Dave Hegwood — Fri, 04 Nov 2005 06:33:00 GMT

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....

RE: SQL Server Security Part 2

J.T. Shyman — Tue, 03 Feb 2004 11:17:00 GMT

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.

RE: SQL Server Security Part 2

James Luetkehoelter — Sun, 01 Feb 2004 10:02:00 GMT

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!

RE: SQL Server Security Part 2

Thomas LeBlanc — Fri, 30 Jan 2004 07:02:00 GMT

Where is a link to Part I.

Thanks,

ThomasLL

RE: SQL Server Security Part 2

Steven. — Fri, 21 Jun 2002 05:29:00 GMT

thanks,learn something new everyday

RE: SQL Server Security Part 2

ckempste — Fri, 21 Jun 2002 05:28:00 GMT

Hi StevenSelect properties of your DB and go to the last tab called "permissions".CheersCk

RE: SQL Server Security Part 2

ckempste — Fri, 21 Jun 2002 05:27:00 GMT

Hi StevenSelect properties of your DB and go to the last tab called "permissions".CheersCk

RE: SQL Server Security Part 2

Steven. — Fri, 21 Jun 2002 02:04:00 GMT

In the Statement Privilege Revocation section of the document you display a image of User/Roles against DDL statements.I have never come across this screen, could you tell me how to get to it etc.RegardsSteven White

RE: SQL Server Security Part 2

K. Brian Kelley — Sun, 27 Jan 2002 19:25:00 GMT

This is the one that gets me upset most of the time:

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.

Certain products balk at when they run in anything less than dbo and when making the ODBC connections, you have the same username and password. This leaves a database wide open and just causes headaches. Grrr.K. Brian Kelleybkelley@sqlservercentral.comhttp://www.sqlservercentral.com/columnists/bkelley/

SQL Server Security Part 2

ckempste — Sun, 27 Jan 2002 00:00:00 GMT

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/ckempster/securitypart2.asp