Impossible de créer le contexte SSPI
Je travaille sur une application .NET où j'essaie de créer les scripts de base de données. Lors de la construction du projet, le message d'erreur «Impossible de créer le contexte SSPI» s'affiche. Cette erreur apparaît dans la fenêtre de sortie (dans l’écran de VS2008) et le processus de construction a échoué. S'il vous plaît aider sur ce point. SQL Server est configuré pour fonctionner sur l'authentification Windows et s'exécuter en tant que service réseau (ces deux éléments sont indispensables pour mon projet).
S'il vous plaît aider sur ce point. Cette erreur ne semble pas être cohérente. Cela avait été corrigé par le passé en redémarrant la machine, en modifiant l'heure système pour qu'elle corresponde à l'heure du domaine et à certaines suggestions du réseau. S'il vous plaît aider sur ce point.
C'est une erreur assez commune avec une variété de causes: commencez ici avec KB 811889
- Quelle version de SQL Server?
- Et Windows sur le client et le serveur?
- Instance SQL locale ou réseau?
- Domaine ou groupe de travail? Fournisseur?
- Changer le mot de passe
- Erreurs de journal Windows locales?
- Toutes les autres applications concernées?
Il semble que votre PC n’ait pas contacté de contrôleur de domaine authentifiant depuis un moment. (J'avais l'habitude que cela se produise plusieurs fois sur mon ordinateur portable.)
Cela peut également arriver si votre mot de passe expire.
J'ai eu le même problème après avoir changé l'utilisateur qui exécutait le service MSSQLSERVER
Pour résoudre les SPN incorrects avec SQL Server, j'ai utilisé cet outil.
http://www.Microsoft.com/en-us/download/details.aspx?id=39046 - Gestionnaire de configuration Microsoft® Kerberos pour SQL Server
Dans mon cas, cela a plutôt bien fonctionné.
Cette erreur survient généralement lorsque le compte d'utilisateur Windows a expiré et qu'il est déjà connecté avec l'ancien mot de passe… .. Demandez à l'utilisateur de redémarrer l'ordinateur et vérifiez si le mot de passe est expiré ou s'il a changé de mot de passe… ... J'espère que cela t'aides!!!!!
La première chose à faire est d'aller dans les journaux (Management\SQL Server Logs) et de voir si SQL Server successfully registered the Service Principal Name (SPN). Si vous voyez une sorte d'erreur (The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service), vous savez par où commencer.
Nous avons vu cela se produire lorsque nous avons changé le compte sous lequel SQL Server était exécuté. Le réinitialiser sur le compte système local a résolu le problème. Microsoft propose également un guide sur la configuration manuelle du SPN.
J'ai résolu mon erreur Cannot Generate SSPI Context en utilisant le Gestionnaire de configuration SQL Server. Comme j'ai le client natif SQL Server 10.0 sur ma machine, la connexion au serveur tente d'utiliser des canaux nommés (ou de la mémoire partagée?). D'autres machines pourraient exécuter mon application sans problème. Lorsque j'ai regardé le gestionnaire de configuration, les canaux nommés et la mémoire partagée étaient tous deux activés (bien). Cependant, sous alias, le nom de l’ordinateur était là avec TCP forcé. Comme je ne savais pas quel effet cela aurait, changer la chaîne de connexion dans mon programme pour utiliser <nom du serveur>. <Nom du domaine> à la place. Fixé.
Si vous hébergez sur IIS, assurez-vous que le mot de passe du compte AppPool n'a pas changé .
Si tel est le cas, procédez comme suit:
- Aller à IIS
- Cliquez sur Pools d'applications
- Sélectionnez l'AppPool de votre application
- Clic droit sur votre AppPool
- Réglages avancés
- Identité
- Mettre à jour le mot de passe
- Redémarrer AppPool
J'ai également publié ce problème et les administrateurs du serveur l'ont résolu en suivant la même solution que celle proposée par indu_teja dans http://www.sqlservercentral.com/Forums/Topic546566-146-1.aspx
La solution proposée par indu_teja dit:
Si vous obtenez cette "erreur de contexte SSPI". Les problèmes auxquels nous sommes confrontés sont:
- Nous ne pourrons pas nous connecter à SQL Server à distance.
- Cependant, nous pourrons nous connecter au serveur avec un compte local.
CAUSE: Le problème pourrait être dû à l’absence de synchronisation correcte du SPN dans Active Directory.
RÉSOLUTION:
- Vous devez réinitialiser SPN. Utilisez la syntaxe "SET SPN". Vous pouvez vérifier la syntaxe dans net une fois.
- Remplacez votre compte de service serveur SQL par un compte de domaine par un compte local, recyclez SQL, puis réinitialisez-le à nouveau avec votre compte de domaine et recyclez le serveur SQL.
L'erreur "Impossible de générer le contexte SSPI" est très générique et peut se produire pour une multitude de raisons. N’est qu’une erreur de couverture pour toute erreur Kerberos/NTLM sous-jacente. Le lien vers les articles de Gbn est un très bon point de départ et résout généralement les problèmes. Si vous rencontrez toujours des problèmes, je vous recommande de suivre les étapes de dépannage décrites dans Dépannage des erreurs Kerberos .
Je viens d'avoir le même problème et tout ce que je faisais était de supprimer les informations de connexion de l'utilisateur dans le serveur SQL en utilisant un autre ID utilisateur et de les rajouter.
Nous avons eu un cas vraiment étrange de cela; Tous les produits Web contenant des chaînes de connexion contenant le nom d'ordinateur Windows du serveur SQL fonctionnaient correctement, mais les produits dotés d'un nom de domaine complet (FQDN) avec le domaine interne attaché généraient une erreur SSPI COMPUTERNAME.DOMAIN (Le ping a toujours fonctionné comme prévu)
Cela causait UNIQUEMENT des problèmes lorsqu'un nouveau serveur SQL était utilisé et que les fichiers hôtes désignaient à la fois le nom de l'ordinateur et le nom de l'ordinateur comme un nom de domaine complet pour les chaînes de connexion.
Dans ce cas, la solution consistait à définir toutes les chaînes de connexion sur le nom de l'ordinateur uniquement, en supprimant les références de domaine.
SQL: 2008R2 SQL2012
IIS: 2008R2
Je peux pouvoir résoudre ce problème en réinitialisant le domaine (la machine serveur, qui est le serveur de domaine, mais qui n'est pas lié à SQL Server, à l'exception de la gestion de domaine) suivi des machines clientes.
Merci à tous pour votre soutien immédiat!
Voici mon cas. J'avais une machine distante hébergeant SQL Server. À partir de ma machine locale, j'essayais d'accéder à l'instance SQL via du code C # et j'obtenais cette erreur. Mon mot de passe pour le compte d'utilisateur sur ma machine/domaine avait a expiré . Je l'ai corrigé avec ce qui suit:
- Ouvert la machine distante, qui m'a invité pour un changement de mot de passe
- J'ai changé mon mot de passe dans cette invite et me suis connecté à la machine distante
- J'ai "verrouillé" ma machine locale (à l'aide des touches
windows+Lafin de ne pas devoir me déconnecter complètement) afin de pouvoir revenir à la page de connexion - Je me suis connecté sur ma machine locale avec le nouveau mot de passe
Tout a ensuite bien fonctionné.
Dans mon cas, c'était un SPN manquant, il fallait exécuter ces deux commandes:
setspn -a MSSQLSvc: SERVERNAME SERVERNAME setspn -a MSSQLSvc: SERVERNAME: 1433 SERVERNAME
En d’autres termes, dans mon cas, le nom de domaine complet y était déjà correctement, mais pas uniquement le nom NETBIOS; après l’ajout de ces noms, cela fonctionnait bien. Au début, ce n’est pas le cas, mais après 2 minutes, c’est le.
Peut-être avez-vous utilisé Integrated Security = SSPI dans la chaîne de connexion. SSPI est utilisé pour les connexions approuvées utilisant Windows Authentication.hence. Pour fonctionner correctement dans l'authentification Windows, votre système et votre serveur de base de données doivent appartenir au même domaine et utiliser la même adresse de serveur DNS, ou être situés dans un domaine approuvé.
si votre système et votre serveur de base de données appartiennent au même domaine, vérifiez l'adresse du serveur DNS des propriétés IPV4 dans la connexion réseau de votre système et indiquez le même serveur DNS utilisé par le serveur de base de données.
J'ai eu cette erreur, c'est parce que mon mot de passe a expiré et que je devais le changer. Je ne l'ai pas remarqué, car dans certains programmes, je pouvais toujours me connecter et tout fonctionnerait normalement (y compris Windows), mais je ne pouvais me connecter à aucun serveur SQL.