I have an SQL Server 2012 instance running as a service on my computer, and according to the service page it logs on as account "NT Service\MSSQLSERVER". However I can't see that account name anywhere else including in the "Local Users and Groups" area in the computer management screen, because, as a link below says, that's not a User Account, it's a service name, in that box that Microsoft so helpfully labelled "account". At this point I can see many people being confused.
The task I'm trying to accomplish is to restore files using the SSMS dialog "Locate Backup File", which uses a dialog completely unlike any of the standard windows file open dialogs, probably because it's doing a "remote" job and operating from the security context of the SQL server, another rich source of end user confusion, that I hope this question might help clear up.
So far if I want to restore a backup .mdf/.bak file that I have in one of my folders, I have to set that folder to readable by Everyone or else I can't get in there with the SQL Server "Locate Backup File" window. I find this idea that you're using a GUI talking to a service that has different user accounts and rights than you, that nobody at Microsoft even cared to make clear to you, very confusing even when I have years of experience with windows system administration.
I'm hoping I missed some documentation pages for SQL Server that would tell you, after installing a new SQL server instance, how you might set up security.
Forum posts like this one have even Microsoft staffers saying "this is complicated", and that it "changed, again" in Denali. How does this work now in SQL Server 2012, and how might I add permission to read files belonging to Users to the SQL Database engine's security SID.
Best Answer
For reference "Denali" is SQL Server 2012. With regards to "end user confusion", I am not all that concerned with whether a end user is confused or not with regards to SSMS. Microsoft did not develop this tool for the normal end user, but for the database administrator and/or a user that had to manage a database. Therefore there will be a learning curve with the tools provided and how they function. The file dialog box has been that way in SSMS since SSMS came out with SQL Server 2005. This is why you will general see most stick with T-SQL statements for backing up, restoring, or attaching a database that have been using it since then.
To configure file system permissions with SQL Server you can follow the instructions from MSDN here.
The way service accounts are handled did not come with or because of SQL Server, it was due to the change on the operating system level. Window Server 2008 R2 put a bit more of a security layer around service accounts. The advantage you have is that the service account can more easily access resources on a domain even if installed with the default settings. This link provides a pretty detailed look at how service account permissions are handled with SQL Server 2012. Excerpt from the link is below on the Virtual Accounts used by default in SQL Server 2012. There is also a link provided in the article that goes into more discussion on the Service Account concept with Windows, here. It is from Window Server 2008 R2 but I believe still holds true on Window Server 2012, and likely Window Server 2012 R2.