|
|
You're in the
sql server clustering
group:Clustering and SA Role
sql server clustering:
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 [quoted text, click to view] "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... >> 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/ [quoted text, click to view] "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. > > >
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 -- [quoted text, click to view] "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 > 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... > >> 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. > >> > >> > >> > > > > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |