SQL Server 2012 avec compte NT Service \ MSSQLSERVER L'accès est refusé dans le domaine
Il y a quelques mois, nous avons installé SQL Server 2012 sous Windows 2008 R2 sous le compte virtuel " NT Service\MSSQLSERVER", tout va bien.
Il y a quelques jours, l'un des administrateurs du département informatique a installé le composant de recherche de texte complet au SQL Server 2012 (le problème est qu'il ne pouvait pas rappeler quels paramètres il a choisi pendant la configuration) et, après cela, de nombreux problèmes viennent :
a. Nous avons vérifié les journaux Windows, dans l'application, nous découvrons que MSSQLServer a beaucoup de bûches anormales, telles que:
La bibliothèque d'interface réseau SQL Server n'a pas pu enregistrer le nom du capital de service (SPN) [MSQLSVC/FOOCOMUTER.FOODOMAINK.COM: 1433] pour le service SQL Server. Windows Retour Code: 0xFFFFFFFF, State: 63. L'échec de l'enregistrement d'un SPN pourrait provoquer une authentification intégrée d'utiliser NTLM au lieu de Kerberos. Ceci est un message informatif. Une action supplémentaire n'est requise que si l'authentification Kerberos est requise par les stratégies d'authentification et si le SPN n'a pas été enregistré manuellement.
Cela semble être la cause mais aucune idée de la raison et de la façon de le résoudre.
b. Emplois SQL avec les propriétaires qui sont des utilisateurs de domaine tels que ("Mydomain\Ploouser") échouera avec le message suivant:
Le travail a échoué. Impossible de déterminer si le propriétaire (Mydomain\Ploouser) de Job Jobname a accès au serveur (raison: impossible d'obtenir des informations sur Windows NT Group/Utilisateur 'Mydomain\Ploouser', code d'erreur 0x6e. [SQLSTAT 42000] (Erreur 15404)).
Nous avons effectué une recherche intensive et remplacons enfin le propriétaire avec "SA" et résolu le problème, bien que ce ne soit pas si décent. Néanmoins, nous aimerions savoir pourquoi.
c. Impossible d'accéder aux ressources du réseau comme un dossier d'autres ordinateurs, par exemple, le SQL suivant reviendra "l'accès est refusé":
DECLARE @CopyCommand nvarchar(1000)
set @CopyCommand = 'dir ' + Char(34) + '\\FooComputer\FooFolder\' + Char(34)
EXEC master..xp_cmdshell @CopyCommand
Pour le problème C, selon MSDN (- http://technet.microsoft.com/en-us/library/ms143504.aspx ) Nous avons essayé d'accorder un accès complet au contrôle pour le compte "Mydomain\SQLServerComputerTername $ "Pour le dossier, toujours le même résultat.
Ces trois problèmes sont tous résultants du compte exécutant le service SQL n'étant pas un compte de domaine et ils seront tous corrigés en modifiant SQL pour exécuter sous un compte de domaine. Spécifiquement:
A - Un SPN est une fonction de sécurité Kerberos nécessitant un compte de domaine et ne fonctionne pas avec les comptes locaux.
B - Pour lire à partir de Active Directory, le service nécessite des informations d'identification d'un compte de domaine.
C - Les comptes locaux ne sont pas reconnus par des ordinateurs distants, ils nient donc la tentative de connexion.
Voici une promenade sur la façon de changer le compte de service:
Vieille question mais ne semble pas avoir une réponse appropriée. NT SERVICE\MSSQLSERVER Être un compte virtuel local, il accède au réseau comme compte d'ordinateur. Et tant que le compte d'ordinateur a accès à des actions et de systèmes de fichiers, vous devriez être capable de sauvegarder par exemple sur les chemins UNC sur le réseau. Voir Configurer les comptes de service Windows et les autorisations .
Lorsque nous avons rencontré ce problème, notre résolution était de localiser le dossier et d'ajouter les autorisations nécessaires au compte virtuel nécessitant ceci. Une fois que nous avions ajouté le compte, simplement en tapant dessus, nous avons suivi les fichiers journaux et nous avons trouvé que nous n'avions plus la question concernant ce dossier/fichier.