SQL Server Administrative rights VS DBA SA rights

Hi,
In previous versions of SQL it has been possible for us, the OS
Administrators, to remove administrative rights of the operating system

from the SQL DBA's.
Recently, we have installed a new SQL 2005 server.
The DBAis demanding administrative rights over the OS as well as the
Database.

This would give the DBA rights over applications that have nothing to
do with the SQL 2005 databases; what's more, it does not follow the
philosophy of providing the least amount of privledges required to do
your job.


(As a side note, we do make it a point to remove the privledges of
local machine adminstrators and domain admins from having SA authority
over SQL systems as well.)


DBA's not being administrators over the OS worked just fine in SQL
2000.


We have removed the local machine admin privledges from the DBA/SA;
however, the DBA has attempted to deploy an SSIS package and he no
longer can do so.


I have done searches and have yet to find an article or how to on what
privledges a SA/DBA needs to remotely administrate SQL 2005
successfully. There are some higher level pieces of information, but
no "how-to" articles or guides.


If it is now required that DBA's have local machine system
administration rights, it would seem like it would be a step backwards
in terms of security.


Can someone provide information on how to set this up so that we have a

good seperation of the OS administrative rights and the DBA/SA
administrative rights, it would be appreciated!
Thanks!

As I know it is hard to seperation of the OS administrative rights and the DBA/SA administrative rights, but you can try limit privilege level of SQL Server Services.

SQL Server 2000 and SQL Server Agent run as Windows services. Each service must be associated with a Windows account, from which it derives its security context. I think this can make Sql Server more secure.

SQL Server allows users of the sa login, and in some cases other users, to access operating system features. These operating system calls are made with the security context of the account that owns the server process. If the server is cracked, these operating system calls may be used to extend the attack to any other resource to which the owning process (the SQL Server service account) has access. For this reason, it is important to grant only necessary privileges to SQL Server services.

good luck.