Clustering and SA Role

Sorry for the re-post.
In a clustered SQL Server 2005 environment you must assign SQL Server, Agent
and Full Text Search to domain groups. These groups then appear in the Sys
Admin fixed role. With that, anyone who can add members to groups in the
domain can also become SQL Server SAs. How can this be prevented? I don't
think anyone with ability/access to add members to groups (even domain
admins) should be allowed to automatically make him/herself a SQL SA be
inheritance.
Hi
It comes down to processes within your organization and also how you secure
your AD.
You can grant someone to only manage objects in a certain tree, so not
giving them rights to the SQL Server accounts that should be in their own
tree would be the correct way of doing it.
Do you trust the same person not to give themselves Enterprise Admin rights
in the domain?
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/
"Jay" <msnews.microsoft.com> wrote in message
news:uf6d0$L6FHA.1148@.tk2msftngp13.phx.gbl...
> Sorry for the re-post.
> In a clustered SQL Server 2005 environment you must assign SQL Server,
> Agent
> and Full Text Search to domain groups. These groups then appear in the
> Sys
> Admin fixed role. With that, anyone who can add members to groups in the
> domain can also become SQL Server SAs. How can this be prevented? I
> don't think anyone with ability/access to add members to groups (even
> domain admins) should be allowed to automatically make him/herself a SQL
> SA be inheritance.
>
>
|||I guess the issue is that in SQL2000 one could remove local admin group from
the sysadmin role, thus preventing the server admin from easily and
legitimately getting into SQL Server. So why can't we have that in SQL2005?
In practice, of course, I bet in many places one would find that the
accounts of the DBAs are placed into a group and that group is granted
access to SQL Server. So if a server admin really wants, he can add himself
to that group, thus gaining full access to SQL Server. So in the end, it
does come down to trust. Trust for sure simplifies management in many
scenarios. Without trust, one would have to go to excessive length to get
things down or prevent things from happening. And in most places, I'd say if
you don't have trust, you have a bigger problem than keeping the server
admin out of SQL Server.
Nevertheless it's nice to, at least, have the option available to keep the
server admin out, if necessary. Unfortunately, the cluster domain groups
required in SQl2005 are not thoroughly documented in current SQL2005 BOL. I
underdstand that the December BOL refresh will have more materials on these
groups. I hope it can shed some light on the issue being discussed here.
Linchi
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:Ok%23Y3jN6FHA.2816@.tk2msftngp13.phx.gbl...
> Hi
> It comes down to processes within your organization and also how you
> secure your AD.
> You can grant someone to only manage objects in a certain tree, so not
> giving them rights to the SQL Server accounts that should be in their own
> tree would be the correct way of doing it.
> Do you trust the same person not to give themselves Enterprise Admin
> rights in the domain?
> 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/
> "Jay" <msnews.microsoft.com> wrote in message
> news:uf6d0$L6FHA.1148@.tk2msftngp13.phx.gbl...
>
|||You do have to remember too that Domain Admins, Enterprise Admins, User
Admins, and OU Admins have the ability to reset the passwords to user
accounts in the AD as well as add users to Global and Resource (Domain
Local?) Groups. So, again, it comes down to trust . . . and audits.
It helps if your Domain/Enterprise Administrators, Server Administrators,
Security Administrators, AD Administrators, Exchange Administrators, Web
Server Administrators, Application Server Administrators, Message Queue
Administrators, and SQL Server Administrators, etc., etc., etc., all be
managed by separate groups by managers of equal rank, all with elevated
privileges, all auditing the activities of the other groups: peer review,
within and throughout the organization to provide checks and balances to the
Change Control Process.
Sincerely,
Anthony Thomas

"Linchi Shea" <linchi_shea@.NOSPAMml.om> wrote in message
news:u3MQcxN6FHA.2888@.tk2msftngp13.phx.gbl...
> I guess the issue is that in SQL2000 one could remove local admin group
from
> the sysadmin role, thus preventing the server admin from easily and
> legitimately getting into SQL Server. So why can't we have that in
SQL2005?
> In practice, of course, I bet in many places one would find that the
> accounts of the DBAs are placed into a group and that group is granted
> access to SQL Server. So if a server admin really wants, he can add
himself
> to that group, thus gaining full access to SQL Server. So in the end, it
> does come down to trust. Trust for sure simplifies management in many
> scenarios. Without trust, one would have to go to excessive length to get
> things down or prevent things from happening. And in most places, I'd say
if
> you don't have trust, you have a bigger problem than keeping the server
> admin out of SQL Server.
> Nevertheless it's nice to, at least, have the option available to keep the
> server admin out, if necessary. Unfortunately, the cluster domain groups
> required in SQl2005 are not thoroughly documented in current SQL2005 BOL.
I
> underdstand that the December BOL refresh will have more materials on
these[vbcol=seagreen]
> groups. I hope it can shed some light on the issue being discussed here.
> Linchi
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:Ok%23Y3jN6FHA.2816@.tk2msftngp13.phx.gbl...
own[vbcol=seagreen]
the[vbcol=seagreen]
SQL
>