Sql-server – Limiting Domain Admins permissions on a SQL Server

What do you need to take into account when migrating SQL Server to another domain?

The steps below presume:

1. IP address will also change
2. SQL Server is NOT clustered

Steps:

A. Backup:

• BEFORE: backup the databases off-machine

B. Services:

• BEFORE: depending on the nature of the change/move, you may want to set service start to Manual for all SQL Service
• AFTER: Once things or up and running properly, return service start to its original setting

C. SA account:

• BEFORE: If all administrator accounts are domain accounts or groups, temporarily enable the 'sa' account with a strong password
• AFTER moving: once the domain-based accounts are setup in the new domain, 'sa' can be disabled again

D. Service Windows account:

• BEFORE moving: for each SQL-Server-related Windows service, change the service to use a LOCAL windows account or one of the built-in accounts
• AFTER moving: grant the necessary privileges to the service new domain accounts. When special permissions are not needed, the SQL Service Configuration Manager can be used to change the service account

E. Windows domain accounts used to login to SQL Server

• Re-create the needed accounts or use corresponding accounts in the new domain.
• BEFORE moving, script out permissions for OLD domain accounts, including SQL permissions, Windows folder and file permissions, Windows permissions, etc.
• AFTER moving, apply these scripts to the corresponding NEW domain accounts so they will have the same permissions

F. IP Address: SQL Server (unless clustered) will use the new IP address

• AFTER: Client applications that reference the service by IP address will need to be configured with the new IP address.

G. Firewall:

• AFTER: OLD firewall openings that are no longer used will need to be closed, NEW firewall openings may need to be created for SQL Server, OLAP services, SSRS between servers and clients

H. DNS entries:

• AFTER: verify DNS has correctly updated
• AFTER: Clients and services that reference by DNS name, may need to be restarted AND/OR their host systems may need their DNS cache flushed. For windows workstations, this can be done with "ipconfig /flushdns"

I. Service Principle Names (SPNs). Some standalone (and all clustered) instances use SPNs.

• AFTER: The OLD SPN must be dropped and a NEW SPN must be created. Although it's not recommended to use a SQL Server service account to manage (its own) SPNs, if this is the case, the NEW domain service account will need to be granted WriteServicePrincipalName" privilege

J. Client Network Utility Alias.

• AFTER: Update any clients that use these will need to updated

K. Client application and service connection configuration:

• AFTER: Data Source Names (DSNs), connection strings, config files, Oracle TNS names for connections - will need to be udpated and applications and services may need to be restarted

L. Internal machine name.

• AFTER: If the machine name is also changing, SQL Server's internal machine name entry may need to be udpated

  sp_dropserver 'MyOldMachineName' go sp_addserver 'MyNewMachineName','local' go

M. Merge Replication - If merge replication is in use, it will also need to be reconfigured.

• BEFORE: ensure all replicas are up-to-date
• AFTER: re-configure merge replation

Attributions - some information added from these sources:

https://serverfault.com/questions/49681/change-ad-domain-membership-of-a-server-2008-running-ms-sql-08

http://social.msdn.microsoft.com/Forums/en-US/sqlsecurity/thread/f3e8ff83-8fcd-4335-87fe-ea5641ae6b88

If you grant the dbcreator server role to a login, that login can create databases. Databases created by a login also (unless changed as part of the process) will be owned by that login, meaning that the login will be a member of the db_owner role for that database and have full rights to that database and all objects within it.

The primary issue here is that by granting the role, you will have no control over when and how the login creates databases, nor do you have any control on how many databases that login creates. A login with dbcreator can create as many databases as there is space for. My recommendation is that you create the database for the login and then grant that login db_owner rights in their database. You can then grant the login db_datareader in the databases that it doesn't/shouldn't own. This gives you better manageability along with accomplishing your stated goal.