Sign in
 
Home20122008 R2200820052000LibraryForums
SQL Server >
> 
> 
NT Service\winmgmt account has sysadmin in SQL 2012

Answered NT Service\winmgmt account has sysadmin in SQL 2012

  • Thursday, January 24, 2013 12:22 AM
     
     
    Sign In to Vote
    0
    I noticed the NT Service\winmgmt virtual account has sysadmin in SQL 2012.  I understand it's a virtual account and that it is used by WMI but, are the permissions really required to be that high?  I'm just concerned it creates another vulnerability spot.

    Laura

     

All Replies

  • Thursday, January 24, 2013 12:28 AM
     
     Answered
    Sign In to Vote
    0

    http://msdn.microsoft.com/en-us/library/ms143504.aspx

    WMI

    Windows Management Instrumentation (WMI) must be able to connect to the Database Engine. To support this, the per-service SID of the Windows WMI provider (NT SERVICE\winmgmt) is provisioned in the Database Engine.

    The SQL WMI provider requires the following permissions:

    • Membership in the db_ddladmin or db_owner fixed database roles in the msdb database.

    • CREATE DDL EVENT NOTIFICATION permission in the server.

    • CREATE TRACE EVENT NOTIFICATION permission in the Database Engine.

    • VIEW ANY DATABASE server-level permission.

      SQL Server setup creates a SQL WMI namespace and grants read permission to the SQL Server Agent service-SID.

    • Marked As Answer by kodaksmile Thursday, January 31, 2013 5:44 PM
    •  
     
  • Thursday, January 24, 2013 3:25 AM
     
     
    Sign In to Vote
    0
    I saw that article but, then why is the account granted sysadmin at install instead of the least permission required?  I'm assuming it is safe to modify the permissions to this lower level within SQL itself but, if this is all that is required it seems excessive to grant sysadmin.

    Laura

     
  • Thursday, January 24, 2013 8:31 AM
    Moderator
     
     Answered
    Sign In to Vote
    0

    Hi kodaksmile,

    Managed service accounts and virtual accounts are designed to provide crucial applications such as SQL Server with the isolation of their own accounts, while eliminating the need for an administrator to manually administer the Service Principal Name (SPN) and credentials for these accounts.

    Always run SQL Server services by using the lowest possible user rights. Use a MSA or virtual account when possible. When MSA and virtual accounts are not possible, use a specific low-privilege user account or domain account instead of a shared account for SQL Server services.

    In addition, I think we could change the virtual account permission for our use.

    If you have any feedback on our support, please click here.

    Thanks.

    Maggie Luo
    TechNet Community Support

     
  • Thursday, January 31, 2013 9:39 AM
    Moderator
     
     
    Sign In to Vote
    0

    Hi kodaksmile,

    I’m writing to follow up with you on this post. Was the problem resolved?

    If you are satisfied with our solution, I’d like to mark this issue as "Answered". Please also feel free to unmark the issue, with any new findings or concerns you may have.  

    Thanks.

    Maggie Luo
    TechNet Community Support