Ma question est la suivante: si vous créez un nouveau compte d'utilisateur de domaine pour chacun des processus SQL Server, quelles autorisations doivent être définies pour chaque compte? Ou le gestionnaire de configuration SQL s'occupe-t-il réellement de cela, et je viens d'avoir un problème imprévu?
Je dois souvent configurer Microsoft SQL Server et je me suis demandé si quelqu'un pouvait fournir des conseils sur la configuration des comptes sous lesquels les services devraient fonctionner. OMI, cela a été vaguement documenté par Microsoft, alors qu'ils vous indiquent la bonne direction, je n'ai jamais pu trouver d'exemples concrets.
Pour résumer ce que j'ai vu jusqu'à présent:
Pour les déploiements simples \ environnements de développement, il est OK d'utiliser les valeurs par défaut du compte virtuel que le programme d'installation utilise: par exemple NT SERVICE\MSSQLSERVER
Évitez d'utiliser le SYSTEMcompte, ce n'est pas sécurisé.
Pour la production et dans les environnements de domaine, il est recommandé d'utiliser soit un compte de service géré, soit de créer un compte d'utilisateur de domaine (et non un administrateur) pour chaque service. Apparemment, si vous utilisez un compte de domaine au moment de l'installation, le programme d'installation définira les autorisations requises pour vous.
Si vous modifiez le compte de service sur une installation existante d'un compte virtuel à un compte de domaine, la recommandation consiste à utiliser le gestionnaire de configuration SQL Server pour définir les nouveaux comptes de service. Il semblerait que cela définisse les autorisations requises pour vous.
J'ai juste essayé de changer le compte de service dans une installation existante en un compte de domaine et cela me donnerait un échec de connexion jusqu'à ce que j'accorde l' log on as serviceautorisation de compte , ce qui contredit la partie où le gestionnaire de configuration SQL Server définira les autorisations requises. (Bien que je ne sais pas si un objet de stratégie de groupe peut avoir interféré avec la définition de cette stratégie de sécurité locale)
Microsoft fournit une liste des autorisations accordées par le programme d' installation de SQL Server sur cette page .
Mais je ne sais pas si c'est quelque chose que je dois faire manuellement pour l'utilisateur que je crée pour exécuter le service, ou si l'utilisation du gestionnaire de configuration SQL doit automatiquement définir ces autorisations.
SQL Server 2014, le contrôleur de domaine est sur Windows Server 2008 R2.
Réponses:
Il est en fait documenté de manière assez approfondie: http://msdn.microsoft.com/en-us/library/ms143504.aspx
Y en a-t-il une partie dont vous n'êtes pas sûr?
Cela dépendra de l'environnement. Personnellement, je déteste trouver un serveur configuré par quelqu'un à l'aide d'un compte local et demander à avoir accès aux ressources du réseau dans le futur, entre autres problèmes.
Encore une fois, cela dépend, mais en général, je serais d'accord (un contre-exemple serait les groupes de disponibilité où il est logique d'utiliser un seul compte de domaine dans toutes les instances).
Sauf en cas d'échec, etc., il le fera. Je ne sais pas pourquoi la partie "prétendument".
Lorsque vous modifiez l'un des services pour SQL Server, utilisez toujours SSCM. Toujours. Période. Il définira les autorisations pour le nouveau compte sur les bases. Si, avant que le compte système local ne soit utilisé et qu'une autorisation illimitée soit accordée à tout ce qui se trouvait sur le système, je m'attendrais à ce que quelque chose échoue aux autorisations après le changement en raison d'une sécurité contrôlée plus stricte. Ce n'est pas une faute de SQL Server SSCM, c'est une faute d'administrateur de ne pas accorder les autorisations EXTRA appropriées (telles que l'accès à un partage réseau, des dossiers restreints, des éléments en dehors du domaine d'installation de SQL Server, etc.)
Sonne comme un GPO est à l'origine d'un problème (à mon humble avis). Ce ne serait pas la première fois :)
Je définirais explicitement toutes les autorisations en dehors de celles indiquées dans le lien msdn que j'ai ci-dessus (également donné par @joeqwerty et dans votre OP). Par exemple, sur un dossier "sauvegarde" sur un partage réseau, sur un nouveau lecteur ajouté pour contenir de nouvelles bases de données (où l'installation était déjà exécutée mais le lecteur n'existait pas), etc.
Sauf si quelque chose est extrêmement cassé avec le serveur, ceux-ci ne devraient pas avoir à être donnés manuellement.
la source