Microsoft SQL Server Best Practices Analyzer

Should this tool be installed and run in a production server?
MM
barney@.newsgroups.nospam
Martin,
If you are concerned about installing this tool on production server, you
can install this tool on a remote machine and you could analyze a production
server from a remote machine (as long as you can connect to target SQL
Server from remote machine)
SQL Best Practices Analyzer relies on the BPA Repository database, which is
a SQL Server database created during SQL BPA installation. You can have this
BPA repository database created on local SQL Server or a remote SQL Server.
SQL Best Practices Analyzer requires the following components to be
installed on the machine
.. Microsoft Internet Explorer 6.0 or later
.. Microsoft .Net Framework 1.1
Reference:
http://www.microsoft.com/downloads/d...displaylang=en
Thanks
Sethu
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
"Martin Millar" <barney@.newsgroups.nospam> wrote in message
news:7C86BCA9-E805-48F2-91DD-E707914E9102@.microsoft.com...
> Should this tool be installed and run in a production server?
> --
> MM
> barney@.newsgroups.nospam
|||Thanks for this. perhaps I should have been a bit more precise. I am a
developer and I'm having a beef with my DBA who has installed this on the
live production server. My argument is that this should be installed and run
on a test system as there is no need to test the performance of the hardware
on which the DB runs on.
If it's OK on Test then it gets ported to live. I believe that anything that
does not need to be installed on a production server should not be on there
as there is a danger that something else running on the box may result in a
loss of service or may intoduce a risk of virus or attack. This tool requires
the dot.net framework and I am a strong fan of this being an asp.net
developer. But until this (dot.net) becomes a core part of the OS (i.e. when
it's installed by default on XP, win2003 etc) I categorise this as a
development add-on and has an attached if installed.
If MS release a security patch for dot.net then I need to schedule downtime
on the production server to apply this.
So back to my original question, which is in itself is about best practises,
should it be best practise to install the BPA on a production server?
Thanks in advance
"Sethu Srinivasan [MSFT]" wrote:

> Martin,
> If you are concerned about installing this tool on production server, you
> can install this tool on a remote machine and you could analyze a production
> server from a remote machine (as long as you can connect to target SQL
> Server from remote machine)
> SQL Best Practices Analyzer relies on the BPA Repository database, which is
> a SQL Server database created during SQL BPA installation. You can have this
> BPA repository database created on local SQL Server or a remote SQL Server.
> SQL Best Practices Analyzer requires the following components to be
> installed on the machine
> .. Microsoft Internet Explorer 6.0 or later
> .. Microsoft .Net Framework 1.1
> Reference:
> http://www.microsoft.com/downloads/d...displaylang=en
>
> Thanks
> Sethu
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm.
>
> "Martin Millar" <barney@.newsgroups.nospam> wrote in message
> news:7C86BCA9-E805-48F2-91DD-E707914E9102@.microsoft.com...
>
>

Microsoft SQL Server 2005 Best Practices Analyzer

Does anyone know if this tool is released or just still in beta?

It will not update, the site is: http://go.microsoft.com/fwlink/?LinkID=82044

Not released yet. However, you can download the latest CTP (public pre-release) version here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=DA0531E4-E94C-4991-82FA-F0E3FBD05E63&displaylang=en

Microsoft Search service vulnerabilities

I am working on a "best practices" document for my company and came across
the suggestion to disable any unnecessary SQL Server services. We do not us
e
full-text search so we have no need for the service. However, I would like
to be able to provide reasons why this service should be disabled. I've
searched for vulnerabilites related to the Microsoft Search service and have
come up empty. Does anyone know of any vulnerabilities?
Thanks!I'm not aware of any vulnerabilities but it's still a good idea to shut it
down if you know you are not going to use it. That way, if someone comes up
with an attack later, you aren't at risk. Reducing the surface that an
attacker can attack to only what's required is always a good idea.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"cltdba" <cltdba@.discussions.microsoft.com> wrote in message
news:14FA55C3-C274-458F-B7A8-ABB90EAD3E2C@.microsoft.com...
>I am working on a "best practices" document for my company and came across
> the suggestion to disable any unnecessary SQL Server services. We do not
> use
> full-text search so we have no need for the service. However, I would
> like
> to be able to provide reasons why this service should be disabled. I've
> searched for vulnerabilites related to the Microsoft Search service and
> have
> come up empty. Does anyone know of any vulnerabilities?
> Thanks!

Microsoft best practices for implementing windows authentication for sql server 2005

Microsoft recommends using Windows authentication instead of SQL Server authentication in SQL Server 2005 for improved security. What are the Microsoft best practices for implementing this? Will be helpful if someone also provides some links that talks about this....

The recommendation of using Windows authentication instead of SQL authentication is one of the best practices recommendations. One suggestion I have is to explicitly provision a Windows principal to make connection faster than if it were made by virtue of group membership.

BOL for SQL Server 2005 contains information about the authentication modes in the topic named "Authentication Mode". See also "How to: Change Server Authentication Mode "

I'm also including some SQL Server 2000 links from MSDN that refer to Windows Authentication:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_security_47u6.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_runsetup_6p9v.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_cs_79kj.asp

Finally, a search on the Internet for "Windows Authentication SQL Server" should provide you with additional links to discussions of Windows authentication.

Thanks
Laurentiu|||Hi Laurentiu,

Thanks for the reply. Can you suggest me wat considerations to be kept in mind incase we want to go for connection pooling as well as windows authentication simultaneously. How can we take the advantages of both?

Thanks in advance.

Abhi|||

Once you've established a connection, the authentication method that you used becomes less relevant. It might matter, for example, if the connection will be used to access resources outside the server, because in some scenarios, you would be able to go out using the Windows credentials, but for work performed inside the server it will not matter what was the authentication mode.

Windows authentication is recommended because with it, the authentication is done by Windows and SQL Server would not need to verify login passwords. Once you performed the authentication step and connected to the server, the way you authenticated becomes less important.

If the connections that you pool are made with Windows authentication, then you are taking advantage of both. Any other considerations would depend on the specific requirements of your application.

Thanks
Laurentiu

MIcrosft SQLServer Best Practices document on securing SQLServer

I'm chasing after a documetn that was available on one of the Microsoft
websites that was titled somethign like "MS SQL Server Best Practices"
and detailed a nyumber of best practices about securing the server.

Included in this was revoking public access to the system table
objects.

Can someone post the URL where I can pick this up, or drop me a note on
contacting them for a copy of the document?"byrocat" <bdealhoy@.sympatico.ca> wrote in message
news:1122653744.611069.56230@.o13g2000cwo.googlegro ups.com...
> I'm chasing after a documetn that was available on one of the Microsoft
> websites that was titled somethign like "MS SQL Server Best Practices"
> and detailed a nyumber of best practices about securing the server.
> Included in this was revoking public access to the system table
> objects.
> Can someone post the URL where I can pick this up, or drop me a note on
> contacting them for a copy of the document?

You can find the Microsoft security docs, including a best practices white
paper, here:

http://www.microsoft.com/sql/techin...ty/default.mspx

I don't know of any good reason to revoke public permissions on system
tables - it might actually break something if users can't retrieve metadata
for some operations. Books Online states that a REVOKE applied to the public
role applies to all database users, which is probably not desirable in many
cases.

This issue often seems to be raised by IT auditors, probably because it has
somehow became part of an industry-standard audit checklist, but the MS best
practices document says only "do not grant additional permissions to this
role", implying that the existing permissions are fine:

http://www.microsoft.com/technet/pr...n/sp3sec02.mspx

Simon|||byrocat (bdealhoy@.sympatico.ca) writes:
> I'm chasing after a documetn that was available on one of the Microsoft
> websites that was titled somethign like "MS SQL Server Best Practices"
> and detailed a nyumber of best practices about securing the server.
> Included in this was revoking public access to the system table
> objects.

I would not do this. At least not without extensive testing first.

The fact that all metadata is open to anyone is not entirely
satisfyable, but the opposite is not good either.

In SQL 2005 things are different. Here you can only see metadata
for objects that you have access to. Unfortunately, this important
distinction is not possible to make in SQL 2000.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp