disabling security

It is possible to disable security in sql server ?
A user will need to go through the authentication process to
access the server so not from that end. Database objects are
accessed based on the permissions set for users or groups in
that database so not from that end. You can modify security
settings but you can't disable the security checks at the
different levels.
-Sue
..
On Mon, 7 Feb 2005 14:11:38 -0800,
<anonymous@.discussions.microsoft.com> wrote:

>It is possible to disable security in sql server ?
|||Hi
No. It is a intrinsic function of the database and engine.
What issues do you have?
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<anonymous@.discussions.microsoft.com> wrote in message
news:01d301c50d61$feb5c000$a601280a@.phx.gbl...
> It is possible to disable security in sql server ?
|||anonymous@.discussions.microsoft.com wrote:
> It is possible to disable security in sql server ?
In what respect? Do you mean not requiring a user log in? No, you need
to log in. Can you provide more information about what you're trying to
accomplish.
David Gugick
Imceda Software
www.imceda.com

disabling security

It is possible to disable security in sql server ?A user will need to go through the authentication process to
access the server so not from that end. Database objects are
accessed based on the permissions set for users or groups in
that database so not from that end. You can modify security
settings but you can't disable the security checks at the
different levels.
-Sue
.
On Mon, 7 Feb 2005 14:11:38 -0800,
<anonymous@.discussions.microsoft.com> wrote:

>It is possible to disable security in sql server ?|||Hi
No. It is a intrinsic function of the database and engine.
What issues do you have?
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<anonymous@.discussions.microsoft.com> wrote in message
news:01d301c50d61$feb5c000$a601280a@.phx.gbl...
> It is possible to disable security in sql server ?|||anonymous@.discussions.microsoft.com wrote:
> It is possible to disable security in sql server ?
In what respect? Do you mean not requiring a user log in? No, you need
to log in. Can you provide more information about what you're trying to
accomplish.
David Gugick
Imceda Software
www.imceda.com

disabling security

It is possible to disable security in sql server ?A user will need to go through the authentication process to
access the server so not from that end. Database objects are
accessed based on the permissions set for users or groups in
that database so not from that end. You can modify security
settings but you can't disable the security checks at the
different levels.
-Sue
.
On Mon, 7 Feb 2005 14:11:38 -0800,
<anonymous@.discussions.microsoft.com> wrote:
>It is possible to disable security in sql server ?|||Hi
No. It is a intrinsic function of the database and engine.
What issues do you have?
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<anonymous@.discussions.microsoft.com> wrote in message
news:01d301c50d61$feb5c000$a601280a@.phx.gbl...
> It is possible to disable security in sql server ?|||anonymous@.discussions.microsoft.com wrote:
> It is possible to disable security in sql server ?
In what respect? Do you mean not requiring a user log in? No, you need
to log in. Can you provide more information about what you're trying to
accomplish.
--
David Gugick
Imceda Software
www.imceda.com

Disabling extended stored procedures for security

Our security team wants us to disable access to (or drop) all of the built-in extended stored procedures in MSDE 2000 as they feel it is a vulnerability. Where can I find out which extended procs are safe to disable or how we can disable them during install time? Or, is the security team being too cautious and we should just tell them to leave these intact?

There are some that are extremely useful (perhaps even necessary) for many routine maintenance tasks.

Perhaps your security department just needs to know that you have access to the stored procedures 'locked' down to only administrative users.

|||

The onyl procedure which is questionable to let it enabled it the xp_cmdshell procedure as it can execute a command shell on the server. But... if noone (or only adminstrators) are granted access to this procedure there should be no security impact for you at all. make just sure that noone create a extended stored procedure which is not shipped by MS.

Code Snippet

SELECT

xproc.name AS [Name],

SCHEMA_NAME(xproc.schema_id)AS [Schema],

CAST(

xproc.is_ms_shipped

ASbit)AS [IsSystemObject],

xproc.create_date AS [CreateDate]

FROM

sys.all_objectsAS xproc

WHERE

(xproc.type='X')and(CAST(

xproc.is_ms_shipped

ASbit)=0)

ORDERBY

[Schema] ASC,[Name] ASC

Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

Thanks Jens. The security dept wants us to drop xp_cmdshell, not just remove the rights. Our MSDE 2000 database stores app settings and is not involved in heavy transactions or replication, etc. So would dropping this cause any harm? I read in the Microsoft KB article that it could affect some other stored procedures that depend on it, but those SPs appear to support enterprise-level features.

|||

I agree with Jens. I would not remove xp_cmdshell since I find it very useful for automating maintenance tasks.

However, set the permissions so that only the sysadmin role can execute xp_cmdshell. (Unless, of course, the worst imaginable sin has been commited and the application is running under the 'sa' account.)

No one, no group, no other role, except the very small list of SQL Server administrators 'should' be in the sysadmin role -AND the sa account 'should' NOT be used at all, and it should be tightly locked down with a strong password.

Since the SQL Server administrators have access to the server, there is nothing that they could do using xp_cmdshell that they couldn't do at an OS level command prompt.

Completely removing xp_cmdshell is folly. Tightly limiting access through appropriate permissions is a 'best practice'.

But if you MUST remove it, there 'may' be little impact. Only time will tell. And you can always put it back if necessary.

Disabling extended stored procedures for security

Our security team wants us to disable access to (or drop) all of the built-in extended stored procedures in MSDE 2000 as they feel it is a vulnerability. Where can I find out which extended procs are safe to disable or how we can disable them during install time? Or, is the security team being too cautious and we should just tell them to leave these intact?

There are some that are extremely useful (perhaps even necessary) for many routine maintenance tasks.

Perhaps your security department just needs to know that you have access to the stored procedures 'locked' down to only administrative users.

|||

The onyl procedure which is questionable to let it enabled it the xp_cmdshell procedure as it can execute a command shell on the server. But... if noone (or only adminstrators) are granted access to this procedure there should be no security impact for you at all. make just sure that noone create a extended stored procedure which is not shipped by MS.

Code Snippet

SELECT

xproc.name AS [Name],

SCHEMA_NAME(xproc.schema_id) AS [Schema],

CAST(

xproc.is_ms_shipped

AS bit) AS [IsSystemObject],

xproc.create_date AS [CreateDate]

FROM

sys.all_objects AS xproc

WHERE

(xproc.type='X')and(CAST(

xproc.is_ms_shipped

AS bit)=0)

ORDER BY

[Schema] ASC,[Name] ASC

Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

Thanks Jens. The security dept wants us to drop xp_cmdshell, not just remove the rights. Our MSDE 2000 database stores app settings and is not involved in heavy transactions or replication, etc. So would dropping this cause any harm? I read in the Microsoft KB article that it could affect some other stored procedures that depend on it, but those SPs appear to support enterprise-level features.

|||

I agree with Jens. I would not remove xp_cmdshell since I find it very useful for automating maintenance tasks.

However, set the permissions so that only the sysadmin role can execute xp_cmdshell. (Unless, of course, the worst imaginable sin has been commited and the application is running under the 'sa' account.)

No one, no group, no other role, except the very small list of SQL Server administrators 'should' be in the sysadmin role -AND the sa account 'should' NOT be used at all, and it should be tightly locked down with a strong password.

Since the SQL Server administrators have access to the server, there is nothing that they could do using xp_cmdshell that they couldn't do at an OS level command prompt.

Completely removing xp_cmdshell is folly. Tightly limiting access through appropriate permissions is a 'best practice'.

But if you MUST remove it, there 'may' be little impact. Only time will tell. And you can always put it back if necessary.

Disabling Export to Excel Sheets In MS SQL Reports 2005

Hello All,

Can i disable export to Excel sheet in ms sql server 2005 reporting services.

This is due to security reasons as the client doesnt want the reports to be send via mail.

Can someone provide the solution on how to disable export to excel

Thanks

Pritam Shetty

Look at the article here:

http://msdn2.microsoft.com/en-us/library/ms156281.aspx

This will only disable the option in the Report Manager, URL access will be still allowed.

Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

I'm a little concerned about something...

>>

This is due to security reasons as the client doesnt want the reports to be send via mail.

<<

Disabling export doesn't prevent the reports from being sent email. Someone can still select the text on the page and dump it into an e-mail message from the HTML version, or Save the page As and attach the result to an email.

>L<

|||

Hello Lisa,

Indirectly i will be disabling all the options.

As of the copy paste thing the clients are ok with it.

But They have just asked to disble the export feature.

So i m just going with it as of now

Thanks & Regards

Pritam Shetty

disable guest account in MSDB

I'm trying to enforce DTS package managment security in an
Enterprise Enviroment. Microsoft has published KB Article 282463
related, recommending disable guest account in msdb. But,
what it's the impact of doing that? it's just a simple
"execute sp_revokedbaccess 'guest'" ' will everything continue
functioning normally?
Thanks
--
Javier Herrera P.
MCDBA - OCP
SQL*Technology
Santiago - Chile
--Generally things would be okay but it depends on if you have
anything setup or configured that relies on users gaining
access to msdb through the guest account. You'd need to
assess that based on your databases, apps, etc. Removing
guest from msdb means that users would need be granted
access to msdb in order to execute or access anything that
the guest account access through permissions via the public
role.
-Sue
On Mon, 2 Aug 2004 06:55:05 -0700, "Javier Herrera P."
<Javier Herrera P.@.discussions.microsoft.com> wrote:

>I'm trying to enforce DTS package managment security in an
>Enterprise Enviroment. Microsoft has published KB Article 282463
>related, recommending disable guest account in msdb. But,
>what it's the impact of doing that? it's just a simple
>"execute sp_revokedbaccess 'guest'" ' will everything continue
>functioning normally?
>Thanks
>--
>Javier Herrera P.
>MCDBA - OCP
>SQL*Technology
>Santiago - Chile
>--

Disable Generate Scripts on Database

Hi guys, is it possible to disable database generate scripts for certain users? I would like to restrict it for security purposes while they able to get into the db and their role like the db owner. Hope can any assistance from you guys. Thanks a lot.

Best Regards,

Hans

You can't do it directly; but there is a workaround there.

1. Add the user in Master database

2. Select the db_denydatareader & db_denydatawriter role

3. Deny execute permission of the sp_helptext & etc.. for the given user

|||Thx for the reply Manivannan.D.Sekaran, however it seems not working at all.|||

If you don't want your users to have access to the definitions of your Stored Procs, Views, Triggers etc... then you could always re-create the procs with the WITH ENCRYPTION option - just ensure that you store copies of the original scripts in a source control database.

Chris

|||

Hans1982 wrote:

Thx for the reply Manivannan.D.Sekaran, however it seems not working at all. I wish to create a login for developer that able modify things within the db but cant backup/restore db, generate the whole db scripts and unable to execute 'Script table as' feature.

|||Thx for the reply,Chris. However, I just wish to the developer unable to generate the db scripts or table scripts for preventing the db structure bring out from the office.|||

I can't think of away of doing this other than taking SSMS away from the developers, which would obviously be counter-productive. I guess you could always write your own version of SSMS if this is a big issue for you.

The problem is that the 'Script table as' option directly queries system tables and views that are essential to the running of SQL Server and SSMS. Although you can deny permissions on these objects, doing so is likely to have wide implications.

Why do you need to restrict access to the 'Script table as' functionality?

Chris

|||For preventing the db structure bring out from the office.|||

Any developer who has enough knowledge of SQL Server's system tables and views would be able to generate their own scripts to reconstruct the structure without using 'Script As'.

Perhaps you need to look at ways of preventing people from copying / emailing script files from work PCs. Even then there's nothing to stop someone printing out a database diagram and taking it home, or even resorting to copying the structure using more traditional techniques, such as pen and paper.

If your database schema is of such high value then maybe you should address (at least) the above issues and add confidentiality clauses into your developers' contracts. Either that or simply don't allow the people you don't trust to work on your databases.

Chris

|||

I see. I guess that's the only solution for that issue because it seems no way to disable the SMO. Thanks for the good advice, Chris. Have a nice day.

Best Regards,

Hans