Domain Groups for Clustered Services

SQL Server Setup

Updated: 12 December 2006

Use the Domain Groups for Clustered Services page of the Microsoft SQL Server Installation Wizard to specify global or local domain groups for the clustered services that will be installed as part of your SQL Server 2005 failover cluster.

To ensure a secure operating environment, access to resources on failover cluster nodes must be restricted. On a SQL Server 2005 failover cluster, domain groups that are common to all cluster nodes are used to control access to registry keys, files, SQL Server objects, and other cluster resources. All resource permissions are controlled by domain-level groups that include SQL Server service accounts as members.

Adding domain groups is one of the principal responsibilities of a domain administrator. Ensure that all domain groups for your SQL Server 2005 failover cluster are created or modified with consideration for the security policies of your organization.

Options

SQL Server service, SQL Server Agent service, Analysis Services service, and Full-Text Search service must run as domain accounts. The domain groups for these services must exist at the time SQL Server Setup is run. If necessary, ask your domain administrator for the names of existing global or local domain groups, or to create domain groups for your failover cluster.

For each clustered service in the instance of SQL Server that you are installing, enter the domain and group name in the format <DomainName>\<GroupName>, subject to the following guidelines:

  • Domain groups can be global domain groups or local domain groups.
  • Domain groups must be within the same domain as the machine accounts. For example, if the machine where SQL Server will be installed is in the SQLSVR domain which is a child of MYDOMAIN, you must specify a group in the SQLSVR domain. The SQLSVR domain may contain user accounts from MYDOMAIN.
  • The user must be a direct member of the domain group, not a member via sub-groups. Setup will not follow sub-group memberships to validate that the user account is in the domain group.
  • The domain and domain group names must already exist at the time Setup is run. If necessary, ask your domain administrator for the names of existing domain groups, or to create domain groups for your failover cluster. If domain groups are created immediately prior to running Setup, allow time for changes to propagate through a corporate network.
  • The domain groups should have the appropriate service accounts added to them. If the service accounts are not members of the appropriate domain groups at the time Setup is run, Setup will attempt to add them. In this case, the account under which Setup is running must have adequate privileges to add accounts to the domain groups. If SQL Server Setup is run under an account that does not have permission to add users to the domain groups, the users must already be members of the appropriate group.
  • Each service should use a different domain group. However, you can use the same domain group and the same account for all SQL Server services, you can use the same domain group and different accounts for each SQL Server service, or you can use a different domain group and a different account for each SQL Server service. To maintain the most granular control over permissions, use a different account and different domain group for each SQL Server service and for each virtual server in your domain.
  • The SQL Server domain groups should not be shared with any other application.

Note that in order to troubleshoot domain group issues, you must have access to the domain controller.

SQL Server accounts will not be removed from the domain groups if SQL Server is uninstalled or if the accounts are changed. A domain administrator must ensure that all unwanted accounts are removed following removal of SQL Server.

Change History

Release History

12 December 2006

Changed content:
  • Specified that domain groups for clustered services can be global or local domain groups..

See Also