Erreur: impossible de générer le contexte SSPI

Lorsque quelqu'un essaie de se connecter à une instance SQL Server, l'erreur s'affiche:

Il n'est pas possible de générer un contexte SSPI.

Hier, nous avons eu une panne de courant (je ne sais pas comment dire cette expression en anglais) et j'ai dû fermer nos serveurs.

À la recherche de réponses, j'ai trouvé ceci:

Problème de connectivité SQL Server 2008: impossible de générer le contexte SSPI

Mais cela ne m'aide pas, car ils fonctionnent bien jusqu'à hier. Je ne veux rien changer. Mais si c'est nécessaire, je vais le changer.

Obs: je ne peux pas redémarrer le serveur maintenant.

Edit: Depuis ma réponse, nous n'avons eu aucune erreur.

«Impossible de générer le contexte SSPI» est une erreur générique. Cela peut être dû à de nombreux problèmes, comme un mot de passe obsolète, une dérive de l'horloge, des autorisations d'accès à Active Directory, l'échec de l'enregistrement d'un SPN, etc.

Il n'y a pas de solution à ce problème. La seule «solution» consiste à rechercher la cause, conformément à KB811889 et / ou à la résolution des erreurs Kerberos . L'application d'une solution ou d'une autre à partir de ressources Internet aléatoires, sans comprendre la cause, peut ou peut ne pas résoudre le problème, peut ou peut ne pas provoquer de frustration, peut ou peut ne pas causer de dommages irrévocables.

Nous avons changé SQL SERVICE usercelui qui est " Domain Admin".

J'ai fait quelques recherches pour savoir pourquoi cela se produit. Il indique que lorsque vous arrêtez le service, vous avez besoin d'un compte avec des privilèges pour créer un nouveau SPN (quand il se rallume). Si vous démarrez un service sans lui, il s'affichera dans CANNOT GENERATE SSPI CONTEXT.

nous modifions les privilèges de notre compte système.

J'espère que cela aide quelqu'un.

Nous avons eu ce problème après avoir pris une base de données de PROD et l'avons restaurée dans QA. Notre application a appelé trois bases de données sur trois serveurs et à part cela, ce n'était pas compliqué.

Il s'avère qu'un SPN (nom principal du service) parasite gênait le compte de service sous lequel la connexion aurait dû être exécutée. Nous l'avons découvert à l'aide du programme Program Files> Microsoft Kerberos Config Manager.

Le correctif à court terme consistait à utiliser SQL Server Configuration Manager et à modifier les connexions SQL Server et SQL Server Agent du compte de service à «LocalSystem» sous «Utiliser le compte intégré».

Impossible de générer un contexte SSPI peut signifier exactement cela. Lorsqu'un client se connecte à un serveur SQL, il utilise une méthode de génération qui inclut le nom de domaine complet du serveur (MsSQLsvr) et le port. Il utilise DNS pour générer le nom du serveur, donc s'il résout le nom incorrectement en raison de CNAME ou d'un fichier hôte, etc., la génération échouera. Envoyez un ping au serveur souhaité et voyez quelle réponse vous obtenez. S'il ne s'agit pas du nom de domaine complet du serveur SQL, le SPN sera généré de manière incorrecte, provoquant cette erreur.

Dans certaines situations, vous obtiendrez cette erreur en raison des paramètres SPN. Par exemple, si vous effectuez des tests de récupération après sinistre sur un nouveau serveur, vous pouvez obtenir une erreur SSPI lors de la connexion à SQL Server. Encore plus étrange, vous pouvez vous connecter à l'aide de SQL Server Management Studio, mais vous ne pouvez pas vous connecter via ODBC ou OLEDB. Il peut y avoir une solution temporaire qui vous permettra probablement d'accéder à la base de données.

Solution : sur chaque ordinateur client essayant de se connecter à SQL Server, créez une entrée dans le fichier hôte de chaque poste de travail. Le mécanisme exact utilisé pour résoudre le problème n'est pas confirmé, mais il se peut que son utilisation l'emporte sur la nécessité du SPN.

Bien que cela ne soit pas garanti pour être corrigé dans tous les cas, cela vous permettra probablement de vous remettre en marche. Cela ne doit pas être considéré comme un correctif permanent. Vous devez résoudre le SPN ou d'autres problèmes dans une situation idéale. Cependant, si vous rencontrez des problèmes avec d'anciennes machines Windows exécutant un système d'exploitation non pris en charge ou si vous effectuez simplement des tests de reprise après sinistre de preuve de concept, cela devrait vous permettre de rester là où vous devez être pour garder les lumières allumées ou la production de nouveau opérationnelle.

J'ai rencontré ce problème et il a été résolu en supprimant l'entrée SPN dans les attributs du compte d'ordinateur dans AD pour le serveur

Rechercher le compte d'ordinateur dans Utilisateurs et ordinateurs AD (vue avancée)

Supprimez ensuite les deux entrées dans servicePrincipalName pour MSSQLSvc

J'ai eu un problème similaire. J'ai fini par devoir supprimer les entrées des informations SPN sur le compte d'ordinateur dans ADSIEdit.

Après avoir supprimé les entrées, j'ai redémarré le service SQL et il a enregistré le SPN avec le compte de ressource de domaine que j'avais créé. J'ai ensuite pu accéder à SQL Server à distance.

Pour moi, la solution était d'exécuter SQL Studio en tant qu'utilisateur de domaine avec cette commande:

runas / user: OtherDomain \ User SSMS.exe

J'ai récemment rencontré ce problème. J'exécutais en tant que compte NT SERVICE et lorsque je suis passé à l'utilisation d'un compte de service, je ne pouvais plus me connecter à l'aide de SSMS avec le nom de la machine ou le FQDN. J'ai pu me connecter avec l'adresse IP. Après quelques recherches, j'ai trouvé que le SPN dans Active Directory pour l'instance SQL était enregistré sur la machine. Une fois que j'ai supprimé cela, que je l'ai ajouté au compte de service et que j'ai redémarré la machine SQL, tout a fonctionné comme il se doit. Heureux de fournir plus de détails si nécessaire.