Is there a Microsoft document on “Why SQL DBA’s need Local Windows Administrator Privilege”?

It's pretty common to give the DBA god rights over an SQL server for the following reasons:

• The SQL server is usually just a SQL server, hence the only service a DBA can impact is the one he's responsible for.
• DBAs sometimes need to reboot the server and reconfigure the OS.
• For practical purposes where the DBA would otherwise have to wake an admin up on an overnight callout.

That said, it really depends on the organisation, and the kind of DBAs you have. Plus, you can grant a DBA administrative access over the SQL instance, without also granting administrative access to the OS. This is preferred if you don't/can't trust the DBA to maintain the OS, and you'll have to shoulder rebooting/maintenance responsibilities yourself.

You've asked a loaded question though, since MS doesn't really have a fixed position on this issue. You might find some technet discussions on the issue but I can't see them issuing a white paper. The closest I can get you is the security best-practices doco: http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc

AFAIK the assumption is supposed to be the other way around. You should have to prove that you need admin access. Clearly you would need it during an install (although I'd be the one doing the install with my account according to their specs). DBA's need admin access to SQL server. SQL server management studio should be run from their workstation, using their windows credentials and should give them all the access they need.

Edit: I took this take in my answer not because there is an absolute answer but because the OP states "There is a general assumption that SQL DBA's need Local Administrator Privilege"

From an admin point of view (whether it be as a SQL admin OR a sysadmin) I do not believe that this is either an industry standard practice or a best practice. Certainly all of the Microsoft docs are going to espouse least privilege

Here is an MSDN article with lots of links to other articles relating to SQL Server Security.

http://msdn.microsoft.com/en-us/library/bb283235(SQL.90).aspx

Here is an article that talks about restricting interactive login for SQL Analysis services http://msdn.microsoft.com/en-us/library/ms175588(SQL.90).aspx

Depending on what the DBA's job responsibilities include and what you mean by "SQL Server", the DBA might need administrator rights. SQL Server could mean SQL Database Engine or Analysis Services or Integration Services or Reporting Services.

And then there is backups and restores and where those files sit. Does the DBA need to create new databases and can he/she create the data files and log files for those without admin rights. What about restarting services?

No the DBA does not have to be an administrator of the machine, but often the DBA is expected to do a lot of tasks that require those permissions.

I don't think MS would give a definitive position on this. The way I would see it is that if someone has local admin on a box then they are assuming a level of responsibility for that box: it's uptime, reliability, performance, security, etc at OS level. If the person is in a position to take on that responsibility, and if taking on that responsibility is within the remit of their job, then it's OK; otherwise the answer is "no".

Setting up and installing sql server, with today's MSA and gMSA accounts will require the DBA to have plenty of AD access...

Setting up a windows cluster for an availability group requires assigning permissions (read all properties and create computer objects) in AD to the cluster object, so that it can create the listener computer object, for a sql server availability group.

Setting up and maintaining the security for your sql server should always involve AD, unless you want SQL logins, which for god's sake need to go away... Master data services for example is all AD...

Setting up SQL server to communicate properly and troubleshooting connectivity issues with Kerberos, will require setSPN rights.

SQL Server encryption, cluster file share witnesses, setting up jobs to export/import files or backup/restore databases will require rights to alter folder permissions on a network.

Performance troubleshooting and management will require access to vmware, localadmin access on the box in order to view things like disk queue length and so on.

Capacity planning and architecture of the database will require access to the storage san to evaluate performance metrics

DBA will need to coordinate OS level patching, you can't just reboot the primary server in an AG.

Troubleshooting connectivity or manipulating cnames during upgrades will require DNS rights to verify the cnames, set refresh times, create and alter cnames to point to new production servers as needed to avoid downtime.

It really comes down to whether you hired a DBA, or a SQL developer, and what you expect from them. If you want a DBA to be able to handle all things that are impacted by a database, stand up a high availability cluster of servers and maintain/troubleshoot them, then the DBA will need domain admin rights. If you want a SQL developer that can make a stored procedure run fast, and then put in tickets every 5 minutes for your sys admins to install/configure/maintain sql servers, then I guess they don't need anything beyond sys_admin at the sql server level.