SQL Server’installation échoue si le compte d’installation ne comprend pas certains droits d’utilisateur

Cet article vous aide à résoudre le problème qui se produit lorsque vous installez ou Microsoft SQL Server une fois la sécurité renforcée.

Version du produit d’origine :   SQL Server 2008, SQL Server 2008 R2, SQL Server 2012
Numéro de la ko d’origine :   2000257

Symptômes

Envisagez le scénario ci-dessous. Pour renforcer la sécurité, vous supprimez certains droits d’utilisateur par défaut sur le groupe Administrateurs local sur un système d’exploitation Windows. En préparation de la configuration de SQL Server sur ce système, vous ajoutez le compte d’installation au groupe Administrateurs local.

Dans ce scénario, si vous installez ou SQL Server, le processus d’installation peut échouer et vous recevez divers messages d’erreur comme indiqué dans les sections suivantes.

  • Scénario 1 : Pour une nouvelle installation, le programme d’installation échoue et vous recevez le message d’erreur suivant :

    L’accès est refusé En outre, vous pouvez remarquer des messages d’erreur semblables à ce qui suit dans le fichier Detail.txt : 2009-01-02 13:00:17 SQLEngine: --SqlServerServiceSCM : attente de l’événement nt 'Global\sqlserverRecComplete$NIIT' à créer 2009-01-02 13:00 0:20 SQLEngine: --SqlServerServiceSCM: Waiting for nt event 'Global\sqlserverRecComplete$NIIT' or sql process handle to be signaled 2009-01-02 13:00:20 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC. 2009-01-02 13:00:20 Slp : Accès refusé 2009-01-02 13:00:20 Slp : Échec de l’action de configuration pour la fonctionnalité SQL_Engine_Core_Inst lors du minutage ConfigRC et scénario ConfigRC. 2009-01-02 13:00:20 Slp : System.ComponentModel.Win32Exception : Accès refusé 2009-01-02 13:00:20 Slp : sur System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited) 2009-01-02 13:00:20 Slp: at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited) 2009-01-02 13:00:20 Slp: at System.Diagnostics.Process.OpenProcessHandle() 2009-01-01- 02 13:00:20 Slp : à System.Diagnostics.Process.get_Handle() 2009-01-02 13:00:20 Slp : Microsoft.SqlServer.Configuration. SqlEngine.SqlServerServiceBase.WaitSqlServerStart(Process processSql) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration. SqlEngine.SqlServerServiceSCM.StartSqlServer(String[] parameters) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration. SqlEngine.SqlServerStartup.StartSQLServerForInstall(String sqlCollation, String masterFullPath, Boolean isConfiguringTemplateDBs) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.ConfigSQLServerSystemDatabases(EffectiveProperties properties, Boolean isConfiguringTemplateDBs, Boolean useInstallInputs) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.DoCommonDBStartConfig(ConfigActionTiming timing) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration. SqlEngine.SqlEngineDBStartConfig.Install(ConfigActionTiming timing, Dictionary 2 actionData, PublicConfigurationBase spcb) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.SqlConfigBase.PrivateConfigurationBase.Execute(ConfigActionScenario scenario, ConfigActionTiming timing, Dictionary 2 actionData, PublicConfigurationBase spcbCurrent) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.SqlConfigBase.SqlFeatureConfigBase.Execute(ConfigActionScenario scenario, ConfigActionTiming timing, Dictionary'2 actionData, PublicConfigurationBase spcbCurrent) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction(String actionId) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.Execute(String actionId, TextWriter errorStream) 2009-01-02 13:00:20 Slp : Exception : System.ComponentModel.Win32Exception. 2009-01-02 13:00:20 Slp : Source : Système. 2009-01-02 13:00:20 Slp : Message : l’accès est refusé.

  • Scénario 2 : les mises à niveau vers SQL Server 2008 signaleront le message d’erreur suivant sur la Engine_SqlEngineHealthCheck règle :

    Nom de la règle : Engine_SqlEngineHealthCheck de règle : vérifie si le service SQL Server peut être redémarré ; ou pour une instance en cluster, si la SQL Server ressource est en ligne. Résultat : Message/Action corrective en échec : le service SQL Server ne peut pas être redémarré ; ou pour une instance en cluster, la ressource SQL Server n’est pas en ligne. Vous pouvez remarquer des messages d’erreur semblables à ce qui suit dans le fichier Detail.txt 2009-05-27 17:50:20 SQLEngine : : Vérification du point de contrôle du moteur « GetSqlServerProcessHandle_1 » 2009-2009-2009 05-27 17:50:20 SQLEngine: --SqlServerServiceSCM: Waiting for nt event 'Global\sqlserverRecComplete$SQL10' to be created 2 0009-05-27 17:50:22 SQLEngine: --SqlServerServiceSCM: Waiting for nt event 'Global\sqlserverRecComplete$SQL10' ou le handle de processus sql doit être signalé 2009-05-27 17:50:22 SQLEngine: --FacetSqlEngineHealthCheck: Engine_SqlEngineHealthCheck: Error: Access is denied

  • Scénario3 : Échec d’une nouvelle installation SQL Server 2012 ou SQL Server 2008 R2

    Vous voyez le message d’erreur suivant lorsque vous essayez d’installer une nouvelle instance de SQL Server 2012 ou SQL Server 2008 R2 :

    Échec de la règle « Privilèges de compte d’installation ». Le compte qui exécute le programme d’installation SQL Server n’a pas un ou tous les droits suivants : le droit de back up files and directories, the right to manage auditing and the security log and the right to debug programs. Pour continuer, utilisez un compte avec ces deux droits.

  • Scénario 4 : l’installation SQL Server 2012 ou une instance ultérieure échoue lorsque vous spécifiez un partage réseau (chemin UNC) pour l’emplacement du répertoire de sauvegarde. Lorsque ce problème se produit, vous recevez le message d’erreur suivant :

    SQL Server d’installation n’a pas le privilège SeSecurityPrivilege sur le serveur de fichiers spécifié dans le chemin <UNC backup location> d’accès. Ce privilège est nécessaire dans l’action de paramètre de sécurité des dossiers SQL Server programme d’installation. Pour accorder ce privilège, utilisez la console stratégie de sécurité locale sur ce serveur de fichiers pour ajouter SQL Server de configuration à la stratégie « Gérer le journal d’audit et de sécurité ». Ce paramètre est disponible dans la section « Attributions des droits d’utilisateur » sous Stratégies locales dans la console Stratégie de sécurité locale.

    Notes

    Ce problème se produit car le compte SQL Server d’installation n’a pas d’autorisations sur le serveur de fichiers SeSecurityPrivilege qui héberge le partage réseau.

Cause

Ce comportement est inhérent au produit. Outre l’ajout du compte d’utilisateur qui exécute le programme d’installation en tant qu’administrateur local, le compte d’utilisateur du programme d’installation requiert les droits d’utilisateur par défaut suivants pour que l’installation se termine correctement.

Nom complet de l’objet de stratégie locale Droit de l’utilisateur
Fichiers et répertoires de sauvegarde SeBackupPrivilege
Programmes de débogage SeDebugPrivilege
Gérer le journal d’audit et de sécurité SeSecurityPrivilege

Notes

Pour plus d’informations sur les autorisations requises pour installer SQL Server, consultez la section « Conditions préalables » des articles MSDN suivants :

En outre, si le partage de fichiers SMB est utilisé comme option de stockage pour le répertoire de données ou tout autre répertoire (répertoire de base de données utilisateur, répertoire des journaux de base de données utilisateur, répertoire TempDB, répertoire de journaux TempDB ou répertoire de sauvegarde), les autorisations supplémentaires suivantes sont requises pour le compte d’installation sur le système de fichiers SMB, comme indiqué dans l’article MSDN suivant : Installer SQL Server avec le stockage de partage de fichiersSMB

Dossier de partage de réseau SMB CONTRÔLE TOTAL SQL du programme d’installation
Dossier de partage de réseau SMB CONTRÔLE TOTAL SQL Server service d’agent SQL Server et de sécurité
SMB Fileserver SeSecurityPrivilege SQL du programme d’installation

Résolution

Pour ajouter les droits au compte d’administrateur local, suivez les étapes suivantes :

  1. Connectez-vous à l’ordinateur en tant qu’utilisateur ayant des informations d’identification administratives.
  2. Cliquez sur Démarrer, cliquez sur Exécuter, tapez Admintools du contrôle, puis cliquez sur OK.
  3. Double-cliquez sur Stratégie de sécurité locale.
  4. Dans la boîte de dialogue Paramètres de sécurité locale, cliquez sur Stratégies locales, double-cliquez sur Attribution des droits d’utilisateur, puis double-cliquez sur Fichiers et répertoires de sauvegarde.
  5. Dans la boîte de dialogue Fichiers de sauvegarde et propriétés des répertoires, cliquez sur Ajouter un utilisateur ou un groupe.
  6. Dans la boîte de dialogue Sélectionner un utilisateur ou des groupes, tapez le compte d’utilisateur utilisé pour l’installation, puis cliquez deux fois sur OK.
  7. Répétez la procédure pour les deux autres stratégies mentionnées dans la section Cause.
  8. Dans le menu Fichier, cliquez sur Quitter pour fermer la boîte de dialogue Paramètres de sécurité locale.

Informations supplémentaires

  • Pour vérifier la liste des privilèges actuellement associés au compte utilisé pour le programme d’installation, vous pouvez utiliser l’outil AccessChk.exe client. Pour télécharger cet outil, voir AccessChk v6.13.

    Utilisation: accesschk.exe- a <setup account> *

    Par exemple : c:\tools\accesschk.exe -a testdc\setupaccount *

      Sample output:
             SeSecurityPrivilege
              SeBackupPrivilege
              SeRestorePrivilege
              SeSystemtimePrivilege
              SeShutdownPrivilege
              SeRemoteShutdownPrivilege
              SeTakeOwnershipPrivilege
              SeDebugPrivilege
              SeSystemEnvironmentPrivilege
              SeSystemProfilePrivilege
              SeProfileSingleProcessPrivilege
              SeIncreaseBasePriorityPrivilege
              SeLoadDriverPrivilege
              SeCreatePagefilePrivilege
              SeIncreaseQuotaPrivilege
              SeChangeNotifyPrivilege
              SeUndockPrivilege
              SeManageVolumePrivilege
              SeImpersonatePrivilege
              SeCreateGlobalPrivilege
              SeTimeZonePrivilege
              SeCreateSymbolicLinkPrivilege
              SeInteractiveLogonRight
              SeNetworkLogonRight
              SeBatchLogonRight
              SeRemoteInteractiveLogonRight
    
  • Configurer les autorisations et les comptes de service Windows

  • Forum aux questions

    • Pourquoi SeSecurityPrivilege est-il requis sur le serveur de fichiers pour le répertoire de sauvegarde sur le partage UNC ?

      Cette autorisation est requise pour récupérer des listes de contrôle d’accès dans le répertoire de sauvegarde par défaut afin de s’assurer que le compte de service SQL Server dispose des autorisations complètes sur le dossier. Cela définit également les ACA si des autorisations sont manquantes pour le compte de service SQL afin qu’il puisse effectuer une sauvegarde sur l’annuaire. Le programme d’installation effectue ces vérifications pour le répertoire de sauvegarde par défaut de sorte que si la sauvegarde est effectuée sur l’installation de l’annuaire de sauvegarde par défaut, l’utilisateur ne rencontre pas d’erreur ou de problème (en raison d’autorisations manquantes) lorsque vous effectuez une sauvegarde sur le répertoire par défaut.

      Notes

      SeSecurityPrivilege est nécessaire pour modifier les ALA get/set à partir des répertoires et des sous-répertoires. C’est le cas car même les utilisateurs qui ont des autorisations CONTRÔLE TOTAL sur les répertoires ne sont pas autorisés à obtenir/définir des informations OWNER et Audit à partir de l’annuaire.

    • Pourquoi l’erreur décrite dans le scénario 4 se produit-elle SQL Server 2012 et les versions ultérieures de SQL Server ?

      Dans SQL Server 2012 et versions ultérieures, Microsoft a commencé à prise en charge des données et des fichiers journaux sur le partage de fichiers SMB. Dans le cadre de cette amélioration, l’expérience d’installation a été améliorée pour renforcer les contrôles afin que les clients ne rencontrent pas d’erreurs ou de problèmes en raison d’autorisations insuffisantes après l’installation. Dans les versions antérieures à SQL Server 2012, les clients peuvent toujours configurer le chemin d’accès du partage réseau pour le répertoire de sauvegarde lorsque le compte du service SQL n’est pas autorisé à effectuer la sauvegarde. Toutefois, ils rencontreront une erreur après l’installation dans cette situation. Ces scénarios sont désormais interdits lorsque vous démarrez la vérification de SQL 2012 sur un partage réseau.