Home Dashboard Directory Help
Search

per-service SID’s are not being granted correct permissions by Anthony Duff


Status: 

Resolved
 as Won't Fix Help for as Won't Fix


2
0
Sign in
to vote
Type: Bug
ID: 770984
Opened: 11/13/2012 6:16:14 PM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

I am referring to 'Configure Windows Service Accounts and Permissions'
http://msdn.microsoft.com/en-us/library/ms143504(v=sql.110)

I have Performed a full install of SQL 2012 (all Instance and Shared Features selected).(Both RTM and SP1). I have local administrative priviledges on the server. The server is a virtual server under VMWare.

In 'Server Configuration', 'Service Accounts' Tab, for those Services where an Account can be specified (everything except 'SQL Full-text Filter Daemon Laucher' 'and SQL Server Browser'), the same domain user account and password was entered.

In checking the permissions granted, post installation, the following was observed :

'Log on as a service' :
- 'NT SERVICE\MSSQLSERVER','NT Service\SQLSERVERAGENT', 'SQLServerMSASUser$ComputerName$MSSQLSERVER',
'NT Service\MSSQLFDLauncher', 'SQLServer2005SQLBrowserUser$ComputerName' and the domain account specified were successfully were added.
- NT SERVICE\ReportServer and NT SERVICE\MsDtsServer110 were NOT added.

'Replace a process-level token' :
- 'NT SERVICE\MSSQLSERVER' and 'NT Service\SQLSERVERAGENT' were added.

'Bypass traverse checking' :
- 'NT SERVICE\MSSQLSERVER' and 'NT Service\SQLSERVERAGENT' were added.
- 'NT SERVICE\MsDtsServer110' and 'NT Service\MSSQLFDLauncher' were NOT added.

'Adjust memory quotas for a process' :
- 'NT SERVICE\MSSQLSERVER' and 'NT Service\SQLSERVERAGENT' were added.
- 'NT Service\MSSQLFDLauncher' was NOT added.

'Impersonate a client after authentication' :
'NT SERVICE\MsDtsServer110' was NOT added.

When uninstalling / re-installing, and using the default settings in 'Server Configuration', 'Service Accounts' Tab (ie. not specifying a domain user account) the following was observed :    

'Log on as a service' :
- NT SERVICE\ReportServer and NT SERVICE\MsDtsServer110 were now ADDED successfully.

'Bypass traverse checking' :
- 'NT SERVICE\MsDtsServer110' and 'NT Service\MSSQLFDLauncher' were still NOT added.

'Adjust memory quotas for a process' :
- 'NT Service\MSSQLFDLauncher' was still NOT added.

'Impersonate a client after authentication' :
'NT SERVICE\MsDtsServer110' was still NOT added.

** ADDITIONAL INFORMATION

I have subsequently run a repair on my SQL 2012 installation and can report the following :
'Bypass traverse checking' :
- 'NT Service\MSSQLFDLauncher' was now ADDED successfully.
- 'NT SERVICE\MsDtsServer110' was still NOT added.

'Adjust memory quotas for a process' :
- 'NT Service\MSSQLFDLauncher' was now ADDED successfully.

'Impersonate a client after authentication' :
'NT SERVICE\MsDtsServer110' was still NOT added.

Obviously running repair directly after installing is not suitable, however it does show it is possible for SQL to grant this access to these service SIDs.


Details
Sign in to post a comment.
Posted by Randy in Marin on 5/7/2014 at 12:37 PM
Maybe the missing rights were added but then removed? Domain policy can remove the rights granted by either a SQL install or repair. If policy is applied just after the install, it might appear that the install is faulty. The per-service SID rights for my current SQL install lasted over a weekend before policy finally struck. In other cases, it took only a few minutes. If the rights are present before policy is applied but not after, then that is where the issue is. I've yet to find anything explicit on how domain policy can or should allow each specific SQL per-service SIDs to retain the rights required. This is something to consider if you just goggled this because you can't figure out why the rights keep disappearing.
Posted by Microsoft on 1/16/2013 at 1:54 PM
I'm sorry, but the repro steps aren't sufficient for me to verify this. A dozen people had input into this topic (people from each area) and I'm not able to refer an error back to one of them. A simplier defect with clearer repro steps could help correct this.
Posted by Microsoft on 1/10/2013 at 8:24 AM
Thank you for submitting this. It will take a while to look into this one, but I'll get back to you. Rick Byham
Sign in to post a workaround.