Le nom principal cible est incorrect. Impossible de générer le contexte SSPI
J'ai du mal à établir une connexion SQL Server de la machine A à la machine B qui exécute SQL Server.
J'ai beaucoup cherché sur Google et tout ce que j'ai trouvé n'a pas fonctionné. Ils ne vous guident pas non plus, étape par étape, dans le processus de résolution de ce problème.
Nous n'utilisons pas Kerberos, mais NTLM où configuré.
Les machines impliquées sont (xx est utilisé pour masquer une partie du nom de la machine à des fins de sécurité):
- xxPRODSVR001 - Contrôleur de domaine Windows Server 2012
- xxDEVSVR003 - Windows Server 2012 (cet ordinateur génère l'erreur)
- xxDEVSVR002 - Windows Server 2012 (cet ordinateur exécute SQL Server 2012)
Les SPN suivants sont enregistrés sur le DC (xxPRODSVR001). J'ai obscurci le domaine avec aaaa pour des raisons de sécurité:
ServicePrincipalNames enregistrés pour CN = xxDEVSVR002, CN = Ordinateurs, DC = yyy, DC = local:
MSSQLSvc/xxDEVSVR002.yyy.local:49298 MSSQLSvc/xxDEVSVR002.yyy.local:TFS RestrictedKrbHost/xxDEVSVR002 RestrictedKrbHost/xxDEVSVR002.yyy.local Hyper-V Replica Service/xxDEVSVR002 Hyper-V Replica Service/xxDEVSVR002.yyy.local Microsoft Virtual System Migration Service/xxDEVSVR002 Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local Microsoft Virtual Console Service/xxDEVSVR002 Microsoft Virtual Console Service/xxDEVSVR002.yyy.local SMTPSVC/xxDEVSVR002 SMTPSVC/xxDEVSVR002.yyy.local WSMAN/xxDEVSVR002 WSMAN/xxDEVSVR002.yyy.local Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local TERMSRV/xxDEVSVR002 TERMSRV/xxDEVSVR002.yyy.local Host/xxDEVSVR002 Host/xxDEVSVR002.yyy.localServicePrincipalNames enregistrés pour CN = xxDEVSVR003, CN = Ordinateurs, DC = yyy, DC = local:
MSSQLSvc/xxDEVSVR003.yyy.local:1433 MSSQLSvc/xxDEVSVR003.yyy.local Hyper-V Replica Service/xxDEVSVR003 Hyper-V Replica Service/xxDEVSVR003.yyy.local Microsoft Virtual System Migration Service/xxDEVSVR003 Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local Microsoft Virtual Console Service/xxDEVSVR003 Microsoft Virtual Console Service/xxDEVSVR003.yyy.local WSMAN/xxDEVSVR003 WSMAN/xxDEVSVR003.yyy.local TERMSRV/xxDEVSVR003 TERMSRV/xxDEVSVR003.yyy.local RestrictedKrbHost/xxDEVSVR003 Host/xxDEVSVR003 RestrictedKrbHost/xxDEVSVR003.yyy.local Host/xxDEVSVR003.yyy.local
Maintenant, si seul le message d'erreur SQL Server était plus descriptif et m'indiquait le nom principal auquel il essayait de se connecter, je pourrais peut-être diagnostiquer cela.
Alors, est-ce que quelqu'un peut me expliquer comment résoudre celui-ci ou pouvez-vous voir quelque chose de mal dans ce que j'ai fourni?
Je serais heureux de générer plus d'informations de débogage, dites-moi simplement ce dont vous avez besoin.
J'ai passé environ deux heures avec le même problème… .. Il s'est avéré que "Integrated Security=true" était la cause du problème.
Essayez de supprimer ce paramètre de la chaîne de connexion.
J'ai eu ce problème avec une application ASP.NET MVC sur laquelle je travaillais.
J'ai réalisé que j'avais récemment changé de mot de passe et j'ai pu le corriger en me déconnectant puis en se reconnectant.
J'ai reçu cette erreur lors d'une connexion via SQL Server Management Studio à l'aide de l'authentification Windows. Mon mot de passe avait expiré mais je ne l'avais pas encore changé. Une fois la modification effectuée, je devais me déconnecter et me reconnecter afin que la machine fonctionne avec mes nouvelles informations d'identification.
Je me connectais à Windows 10 avec un PIN au lieu d'un mot de passe. Je me suis déconnecté puis reconnecté avec mon mot de passe et j'ai pu accéder à SQL Server via Management Studio.
Juste pour ajouter une autre solution potentielle à cette plus ambiguë d’erreurs The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):
Vérifiez que l'adresse IP résolue lors de l'envoi d'une requête ping à SQL Server est identique à celle de Configuration Manager. Pour vérifier, ouvrez le Gestionnaire de configuration SQL Server, puis accédez à Configuration du réseau SQL Server> Protocoles pour MSSQLServer> TCP/IP.
Assurez-vous que TCP/IP est activé et que dans l'onglet Adresses IP, assurez-vous que l'adresse IP que le serveur résout lors de l'envoi d'une commande ping est la même ici. Cela a corrigé cette erreur pour moi.
J'obtenais la même erreur en essayant via l'authentification Windows. Cela semble ridicule, mais au cas où cela aiderait quelqu'un d'autre: c'est parce que mon compte de domaine s'est verrouillé alors que j'étais encore connecté (!). Le déverrouillage du compte l'a corrigé.
Connectez-vous à la fois à votre SQL Box et à votre client et tapez:
ipconfig /flushdns
nbtstat -R
Si cela ne fonctionne pas, renouvelez votre DHCP sur votre ordinateur client ... Ceci fonctionne pour 2 PC dans notre bureau.
L'erreur de contexte SSPI indique clairement que l'authentification est tentée à l'aide de Kerberos.
Consultez les journaux des événements de sécurité. Si vous utilisez Kerberos, vous devriez voir les tentatives d’ouverture de session avec le package d’authentification: Kerberos.
L'authentification NTLM peut échouer et une tentative d'authentification Kerberos est en cours. Vous pouvez également voir un échec de tentative d'ouverture de session NTLM dans votre journal des événements de sécurité?
Vous pouvez activer la journalisation d'événements kerberos dans dev pour essayer de déboguer sur la raison pour laquelle kerberos échoue, même si elle est très prolixe.
Je viens de rencontrer ceci et de le réparer en faisant 2 choses:
- Octroi d'autorisations servicePrincipalName en lecture/écriture au compte de service via ADSI Edit, comme décrit dans https://support.Microsoft.com/en-us/kb/811889
Suppression des SPN qui existaient auparavant sur le compte SQL Server computer (par opposition au compte de service) à l'aide de
setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAMEoù 1234 était le numéro de port utilisé par l'instance (la mienne n'était pas une instance par défaut).
Je testais IPv6 sur un cluster de PC dans un réseau isolé et je me suis heurté à ce problème lorsque je suis revenu sur IPv4. J'avais joué dans Active Directory, DNS et DHCP, je n'ai donc aucune idée de ce que j'ai poussé à casser la configuration de Kerberos.
J'ai retesté la connexion en dehors de mon logiciel avec cette astuce utile pour connecter la connectivité distante que j'ai trouvée.
https://blogs.msdn.Microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/
après une brève recherche, nous avons trouvé ceci sur le site Web de Microsoft https://support.Microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context- Message d'erreur .
exécutez l'outil sur le serveur SQL pour voir s'il y a un problème si l'état indique une erreur, appuyez sur le bouton de réparation qui apparaît.
Cela a résolu le problème pour moi.
Dans mon cas, le redémarrage de SQL Server 2014 (sur mon serveur de développement) a résolu le problème.
J'ai eu ce problème lors de l'accès à l'application Web. C'est peut-être parce que j'ai récemment changé un mot de passe Windows.
Ce problème a été résolu lorsque j'ai mis à jour le mot de passe du pool d'applications où j'ai hébergé l'application Web.
Vérifiez vos correspondances d'horloge entre le client et le serveur.
Lorsque j'ai eu cette erreur par intermittence, aucune des réponses ci-dessus n'a fonctionné. Nous avons alors constaté que le temps avait dérivé sur certains de nos serveurs. Une fois qu'ils ont été synchronisés à nouveau, l'erreur a disparu. Recherchez w32tm ou NTP pour voir comment synchroniser automatiquement l'heure sur Windows.
J'en ai rencontré un nouveau: SQL 2012 hébergé sur Server 2012 . J'ai été chargé de créer un cluster pour SQL AlwaysOn.
Le cluster a été créé. Tout le monde a reçu le message SSPI.
Pour résoudre les problèmes couru commande suivante:
setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService
DomainNamerunningSQLService == le compte de domaine que j'ai défini pour SQL J'avais besoin d'un administrateur de domaine pour exécuter la commande. Un seul serveur du cluster avait des problèmes.
Puis redémarré SQL. À ma grande surprise, j'ai pu me connecter.
Je me suis heurté à cela aujourd'hui et je voulais partager ma solution, celle-ci étant simplement négligée et facile à corriger.
Nous gérons notre propre rDNS et avons récemment refait notre schéma de nommage des serveurs. Dans ce cadre, nous aurions dû mettre à jour notre rDNS et oublier de le faire.
Un ping a indiqué le nom d'hôte correct, mais un ping -a a renvoyé un nom d'hôte incorrect.
Solution facile: changez le rDNS, faites un ipconfig/flushdns, attendez 30 secondes (juste quelque chose que je fais), faites un autre ping -a, voyez-le en résolvant le bon nom d’hôte, connectez-vous ... gagnez.
J'essayais de me connecter à une VM exécutant SQL Server 2015 à partir de mon ordinateur portable dans une application console Visual Studio 2015. Je lance mon application la nuit précédente et tout va bien. Dans la matinée, j'essaie de déboguer l'application et j'obtiens cette erreur. J'ai essayé ipconfig/flush et release + renew et un tas d'autres ordures, mais à la fin ...
Redémarrez votre VM et redémarrez le client. Cela a réglé le problème pour moi. J'aurais dû savoir, redémarrer les travaux à chaque fois.
Depuis que j'ai atterri ici en cherchant une solution à mon propre problème, je vais partager ma solution ici, au cas où d’autres y atterrissent également.
Je me connectais correctement à SQL Server jusqu'à ce que ma machine soit déplacée vers un autre bureau sur un autre domaine . Puis, après le basculement, cette erreur concernant le nom du principal cible s’exprimait. Ce qui a résolu le problème, c'était de se connecter en utilisant un nom complet tel que: server.domain.com . Et en réalité, une fois que je me suis connecté au premier serveur de cette façon, je pouvais me connecter à d'autres serveurs en utilisant uniquement le nom du serveur (sans qualification complète), mais votre kilométrage pourrait varier.
Avait un seul utilisateur qui a eu cette erreur sur un seul serveur SQL. Il s'avère qu'il avait stocké un ancien mot de passe dans le Panneau de configuration - Gestionnaire d'informations d'identification sous Informations d'identification Windows pour le nom du serveur. Supprimez les informations d'identification stockées et cela a fonctionné.
Dans mon cas, le problème était de configurer DNS sur le wifi. J'ai supprimé les paramètres et les ai laissés vides et j'ai travaillé.
J'ajouterai ceci ici, car cela m'a surpris et pourrait aider quelqu'un d'autre. Caveat emptor, je ne suis pas un utilisateur de Windows, mais j'ai dû regarder un scénario incluant SQL Server.
J'ai téléchargé la version pour développeurs du produit SQL Server complet et je l'ai installée sous Windows 10. Tout va pour les connexions locales, rien pour le client distant.
J'ai essayé plusieurs des solutions ci-dessus, mais je me suis finalement rendu compte que l'authentification Windows voulait authentifier remoteclient\myuser et qu'il était impossible, dans un monde Windows autonome, de créer un mécanisme d'authentification (comme le comprend kerberos). Le message d'erreur est "Impossible de générer le contexte SSPI".
L'utilisation de l'authentification SQL ne semblait pas fonctionner non plus.
Je suis finalement retourné à SQL Server Express qui a un mode combiné et je pouvais alors utiliser l'authentification SQL à partir des clients distants.
J'ai eu le même problème. J'ai récemment changé mon mot de passe Windows et mon site renvoyait l'erreur. J'ai essayé de me déconnecter et de me connecter mais je n'ai pas travaillé. Ensuite, j'ai réalisé que j'avais configuré ma defaultappppol à l'aide de mon compte dans la section "compte personnalisé" et que j'ai de nouveau configuré le compte à l'aide du nouveau mot de passe. Cela a fait la magie !!! S'il vous plaît laissez-moi savoir vos commentaires sur cette solution.
J'ai rencontré une variante de ce problème, voici les caractéristiques:
- L'utilisateur pouvait s'est connecté avec succès à une instance nommée, par exemple, les connexions à
Server\Instanceont abouti - L'utilisateur était incapable de se connecter à l'instance par défaut, par exemple, les connexions à
Serveront échoué avec la capture d'écran de l'OP concernant SSPI - L'utilisateur n'a pas pu se connecter à l'instance par défaut avec un nom complet. Par exemple, les connexions à
Server.domain.comont échoué (délai d'expiration). - L'utilisateur n'a pas pu se connecter à l'adresse IP sans l'instance nommée, par exemple, les connexions à
192.168.1.134ont échoué. - D'autres utilisateurs n'appartenant pas au domaine (par exemple, les utilisateurs qui utilisent un réseau privé virtuel (VPN) sur le réseau) mais qui utilisent des informations d'identification de domaine ont pu se connecter avec succès à l'instance par défaut et à l'adresse IP.
Ainsi, après de nombreux casse-tête pour essayer de comprendre pourquoi cet utilisateur unique ne pouvait pas se connecter, voici les étapes que nous avons suivies pour remédier à la situation:
- Regardez le serveur dans la liste des SPN en utilisant
setspn -l Server
une. Dans notre cas, il est ditServer.domain.com - Ajoutez une entrée au fichier hosts situé dans
C:\Windows\System32\drivers\etc\hosts(exécutez le Bloc-notes en tant qu'administrateur pour modifier ce fichier). L'entrée que nous avons ajoutée étaitServer.domain.com Server
Après cela, nous avons réussi à nous connecter via l'instance par défaut via SSMS.
J'exécute un système de test Mickey Mouse basé sur SQL.COM.
J'ai exécuté setspn -T sql -F -Q */Servername (dans ce cas, SQL01) sur la machine à laquelle je ne pouvais pas me connecter et sur une machine que je pouvais. J'ai ensuite simplement supprimé les entrées supplémentaires dans la machine à problèmes et tout a fonctionné, par exemple. setspn -D MSSQLSvc/SQL01.SQL.COM:1433 SQL01
Moi aussi j'ai eu ce problème sur SQL Server 2014 lors de la journalisation avec l'authentification Windows, pour résoudre le problème, j'ai redémarré mon serveur une fois, puis essayé de vous connecter, cela a fonctionné pour moi.
J'ai rencontré ce problème lors de la tentative de connexion à mon instance SQL Server 2017 via un VPN L2TP sur une machine Windows 10 jointe à un domaine.
Le problème a fini par être dans mes paramètres VPN. Dans les paramètres de sécurité, dans Authentification, en utilisant EAP-MSCHAPv2 et dans la boîte de dialogue Propriétés, j'avais sélectionné Automatically use my Windows logon name and password (and domain if any)..
J'ai désactivé cette fonction, puis reconnecté mon VPN, puis j'ai réussi à me connecter à SQL Server.
Je pense que cela entraînait l'utilisation de Kerberos au lieu de NTLM par ma connexion SQL (avec la sécurité du compte Windows), provoquant l'erreur SSPI.
J'ai eu le même problème, mais le verrouillage et le déverrouillage de la machine ont fonctionné pour moi. Parfois, les problèmes de pare-feu donneront des erreurs.
Je ne suis pas sûr que cela fonctionne pour vous ou pas, je partage simplement mon expérience.
J'ai eu ce problème sur mon serveur SQL. Setspn -D mssqlsvc\Hostname.domainname Nom d’hôte s’est ensuite arrêté et a démarré mon service SQL Server.
Je pense que simplement arrêter et démarrer mon service SQL l'aurait fait.
J'ai essayé toutes les solutions ici et aucune d'entre elles n'a encore fonctionné. Une solution de contournement qui fonctionne consiste à cliquer sur Connexion , entrez le nom du serveur, sélectionnez Options, onglet Propriétés de la connexion. Définissez le "Protocole réseau" sur "Tubes nommés". Cela permet aux utilisateurs de se connecter à distance à l'aide de leurs informations d'identification réseau. Je posterai une mise à jour lorsque j'aurai un correctif.
Pas du tout une solution idéale, je voulais juste ajouter ceci pour référence future pour tous ceux qui voient cette page:
J'avais ce problème en essayant de me connecter à une instance SQL Server distante en utilisant mon compte de domaine, essayer de faire la même chose sur une instance hébergée sur une autre machine fonctionnait parfaitement.
Donc, si vous avez la possibilité d'utiliser simplement une instance différente, cela peut aider, mais cela ne règle en réalité aucun problème.
Le problème semble lié au serveur DNS . Pour résoudre ce problème, remplacez l'adresse IP par Nom de l'ordinateur.
Exemple: Modifiez la valeur "10.0.0.10\TestDB" en "YourcomputerName\TestDB".