Le nom du principal cible est incorrect. Impossible de générer le contexte SSPI

J'ai du mal à obtenir une connexion SQL Server de la machine A à la machine B qui exécute SQL Server.

J'ai beaucoup cherché sur Google et toutes les choses que j'ai trouvées n'ont 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 là où il est 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 (Cette machine génère l'erreur)
• xxDEVSVR002 - Windows Server 2012 (cette machine exécute SQL Server 2012)

Les SPN suivants sont enregistrés sur le DC (xxPRODSVR001). J'ai masqué le domaine avec yyy pour des raisons de sécurité:

ServicePrincipalNames enregistré 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.local

ServicePrincipalNames enregistré 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 à quel nom principal il essayait de se connecter, je pourrais peut-être diagnostiquer cela.

Quelqu'un peut-il donc m'expliquer comment résoudre celui-ci ou pouvez-vous voir quelque chose de faux 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 eu ce problème avec une application ASP.NET MVC sur laquelle je travaillais.

J'ai réalisé que j'avais récemment changé mon mot de passe et j'ai pu le réparer en me déconnectant et en me reconnectant.

J'ai reçu cette erreur lors de la 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 modifié. Une fois le changement effectué, j'ai dû me déconnecter et me reconnecter pour que la machine fonctionne en utilisant mes nouvelles informations d'identification.

Essayez de définir Integrated Security=truepour supprimer ce paramètre de la chaîne de connexion.

IMPORTANT: comme l'a commenté l'utilisateur @Auspex,

La suppression de la sécurité intégrée empêchera cette erreur, car l'erreur se produit lorsque vous essayez de vous connecter avec vos informations d'identification Windows. Malheureusement, la plupart du temps, vous souhaitez pouvoir vous connecter avec vos informations d'identification Windows

J'obtenais la même erreur en essayant via l'authentification Windows. Cela semble ridicule, mais juste au cas où cela aiderait quelqu'un d'autre: c'était parce que mon compte de domaine a été verrouillé d'une manière ou d'une autre alors que j'étais toujours connecté (!). Le déverrouillage du compte l'a corrigé.

Je me connectais à Windows 10 avec un code PIN au lieu d'un mot de passe. Je me suis déconnecté et reconnecté avec mon mot de passe à la place et j'ai pu accéder à SQL Server via Management Studio.

Juste pour ajouter une autre solution potentielle à cette erreur la plus ambiguë The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Vérifiez que l'adresse IP qui est résolue lors de la commande ping sur SQL Server est la même que celle du Gestionnaire de configuration. Pour vérifier, ouvrez le Gestionnaire de configuration SQL Server, puis accédez à Configuration réseau SQL Server> Protocoles pour MSSQLServer> TCP / IP.

Assurez-vous que TCP / IP est activé et dans l'onglet Adresses IP, assurez-vous que l'adresse IP à laquelle le serveur résout lors du ping est la même ici. Cela a corrigé cette erreur pour moi.

L'erreur de contexte SSPI indique clairement que l'authentification est tentée à l' aide de Kerberos .

Étant donné que l'authentification Kerberos L'authentification Windows de SQL Server repose sur Active Directory , ce qui nécessite une relation poussée entre votre ordinateur et votre contrôleur de domaine réseau, vous devez commencer par valider cette relation.

Vous pouvez vérifier rapidement cette relation, via la commande Powershell suivante Test-ComputerSecureChannel .

Test-ComputerSecureChannel -verbose

S'il renvoie False , vous devez réparer le canal sécurisé Active Directory de votre ordinateur, car sans lui, aucune validation des informations de domaine n'est possible en dehors de votre ordinateur.

Vous pouvez réparer votre Computer Secure Channel, via la commande Powershell suivante :

Test-ComputerSecureChannel -Repair

Vérifiez les journaux des événements de sécurité, si vous utilisez Kerberos, vous devriez voir les tentatives de connexion avec le package d'authentification: Kerberos.

L'authentification NTLM peut échouer et donc 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 des événements kerberos dans dev pour essayer de déboguer pourquoi le kerberos échoue, bien que ce soit très détaillé.

Le gestionnaire de configuration Kerberos de Microsoft pour SQL Server peut vous aider à diagnostiquer et à résoudre rapidement ce problème.

Voici une bonne histoire à lire: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Le problème semble être un problème d'informations d'identification Windows. J'obtenais la même erreur sur mon ordinateur portable de travail avec un VPN. Je suis censé être connecté en tant que domaine / nom d'utilisateur, ce que j'utilise avec succès lors de la connexion directe, mais dès que je passe à un VPN avec une autre connexion, je reçois cette erreur. Je pensais que c'était un problème DNS car je pouvais cingler le serveur mais il s'est avéré que je devais exécuter SMSS explicitement en tant qu'utilisateur à partir de l'invite de commande.

par exemple runas / netonly / user: YourDoman \ YourUsername "C: \ Program Files (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"

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 machine client ... Cela fonctionne pour 2 PC dans notre bureau.

Je viens de rencontrer ceci et je l'ai corrigé en faisant 2 choses:

1. Octroi d'autorisations de lecture / écriture servicePrincipalName au compte de service à l'aide de ADSI Edit, comme décrit dans https://support.microsoft.com/en-us/kb/811889

2. Suppression des SPN qui existaient auparavant sur le compte d'ordinateur SQL Server (par opposition au compte de service) à l'aide de

   setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
   

   où 1234 était le numéro de port utilisé par l'instance (le mien n'était pas une instance par défaut).

Dans mon cas, le redémarrage de SQL Server 2014 (sur mon serveur de développement) a résolu le problème.

Je testais IPv6 sur un cluster de PC dans un réseau isolé et j'ai rencontré ce problème lorsque je suis revenu à votre IPv4. J'avais joué dans l'annuaire actif, DNS et DHCP donc je n'ai 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é à distance que j'ai trouvée.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

puis après une brève recherche, j'ai trouvé cela sur le site Web de Microsoft https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message .

exécutez l'outil sur le serveur SQL pour voir s'il y a un problème si l'état indique une erreur, puis appuyez sur le bouton de réparation qui apparaît.

Cela a résolu le problème pour moi.

Cela est généralement dû à des noms de principe de service (SPN) manquants, incorrects ou dupliqués

Étapes à suivre:

1. Confirmer le compte AD utilisé par SQL Server
2. Exécutez la commande suivante dans Powershell ou CMD en mode administrateur (le compte de service ne doit pas contenir le domaine)

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

3. Assurez-vous que la sortie renvoyée contient un SPN qui est pleinement qualifié, non pleinement qualifié, avec un port et sans port.

   Production attendue:

   Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
   MSSQLSvc/<ServerName>.<domain>.com:1433
   MSSQLSvc/<ServerName>:1433                                           
   MSSQLSvc/<ServerName>.<domain>.com
   MSSQLSvc/<ServerName>
   

4. Si vous ne voyez pas tout ce qui précède, exécutez la commande suivante dans PowerShell ou CMD en mode administrateur (assurez-vous de changer le port si vous n'utilisez pas la valeur par défaut 1433)

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>

5. Une fois que ci-dessus est terminé, la propagation DNS prend normalement quelques minutes

De plus, si vous recevez un message concernant les SPN en double trouvés, vous souhaiterez peut-être les supprimer et les recréer

J'ai eu ce problème lors de l'accès à l'application Web. Cela peut être dû au fait 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 que votre horloge correspond entre le client et le serveur.

Lorsque j'ai eu cette erreur par intermittence, aucune des réponses ci-dessus n'a fonctionné, puis nous avons 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 sous Windows.

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 atterriraient ici aussi.

Je me connectais bien à SQL Server jusqu'à ce que ma machine soit déplacée vers un autre bureau sur un autre domaine . Ensuite, après le changement, j'obtenais cette erreur concernant le nom du principal cible. Ce qui a corrigé, c'était la connexion en utilisant un nom complet tel que: serveur.domaine.com . Et en fait, une fois que je me suis connecté au premier serveur de cette façon, je pourrais me connecter à d'autres serveurs en utilisant uniquement le nom du serveur (sans la qualification complète), mais votre kilométrage peut varier.

Je suis tombé sur ce problème aujourd'hui et je voulais partager mon correctif, car celui-ci est simplement négligé et facile à réparer.

Nous gérons notre propre rDNS et avons récemment refait notre schéma de nommage de serveur. Dans ce cadre, nous aurions dû mettre à jour notre rDNS et oublier de le faire.

Un ping a révélé le nom d'hôte correct, mais un ping -a a renvoyé le mauvais nom d'hôte.

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 résoudre le bon nom d'hôte, connectez-vous ... profit.

J'en ai rencontré un nouveau pour cela: SQL 2012 hébergé sur le serveur 2012. A é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, exécutez la 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 a rencontré des problèmes.

Puis redémarré SQL. À ma grande surprise, j'ai pu me connecter.

J'essayais de me connecter à une machine virtuelle 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 ça va. Le matin, j'essaye de déboguer l'application et j'obtiens cette erreur. J'ai essayé ipconfig/flushet release+ renewet un tas d'autres poubelles, mais au final ...

Redémarrez votre VM et redémarrez le client. Cela a résolu le problème pour moi. J'aurais dû savoir, redémarrer fonctionne à chaque fois.

J'ai eu ce problème sur mon serveur SQL. J'ai setspn -D mssqlsvc \ Hostname.domainname Hostname puis arrêté et démarré mon service serveur SQL.

Je pense que simplement arrêter et démarrer mon service SQL l'aurait fait.

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 génèrent des erreurs.

Je ne suis pas sûr que cela fonctionnera pour vous ou non, je ne fais que partager mon expérience.

J'ai essayé toutes les solutions ici et aucune d'elles n'a encore fonctionné. Une solution de contournement qui fonctionne est de cliquer sur Se connecter , entrez le nom du serveur, sélectionnez Options, onglet Propriétés de connexion. Réglez le "Protocole réseau" sur "Named Pipes". Cela permet aux utilisateurs de se connecter à distance à l'aide de leurs informations d'identification réseau. Je publierai une mise à jour lorsque j'aurai une solution.

Dans mon cas, le problème était de configurer DNS sur le wifi. J'ai supprimé les paramètres, je les ai laissés vides et j'ai travaillé.

Assurez-vous que les «canaux nommés» sont activés à partir de «SQL Server Configuration Manager». Cela a fonctionné pour moi.

1. Ouvrez "SQL Server Configuration Manager".
2. Développez "Configuration réseau SQL Server", dans la liste de gauche.
3. Sélectionnez «Protocoles pour [votre nom d'instance]».
4. Faites un clic droit sur "Named Pipes", dans la liste de droite.
5. Sélectionnez "Activer"
6. Redémarrez votre service d'instance.

Cet outil Microsoft est comme Magic. Exécutez-le, connectez-le au serveur SQL et cliquez sur Corriger

L'ancienne version liée ici fonctionnait sur SQL Server 2017.

Gestionnaire de configuration Kerberos pour SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

Dans ma situation, j'essayais d'utiliser la sécurité intégrée pour me connecter d'un PC à SQL Server sur un autre PC sur un réseau sans domaine. Sur les deux PC, je me connectais à Windows avec le même compte Microsoft . Je suis passé à un compte local sur les deux PC et SQL Server se connecte maintenant avec succès.

Dans mon cas, puisque je travaillais dans mon environnement de développement, quelqu'un avait arrêté le contrôleur de domaine et les informations d'identification Windows ne pouvaient pas être authentifiées. Après avoir allumé le contrôleur de domaine, l'erreur a disparu et tout a bien fonctionné.

Un autre créneau à ce problème causé par les connexions réseau. Je me connecte via le client VPN Windows et ce problème est survenu lorsque je suis passé du Wifi à une connexion filaire. Le correctif pour ma situation était d'ajuster manuellement la métrique de l'adaptateur.

Dans PowerShell, utilisez Get-NetIPInterface pour voir toutes les valeurs de métrique. Les nombres inférieurs sont moins chers et sont donc préférés par les fenêtres. J'ai commuté Ethernet et VPN et les informations d'identification sont arrivées là où elles devaient être pour que SSMS soit heureux.

Pour configurer la fonction de métrique automatique: Dans le Panneau de configuration, double-cliquez sur Connexions réseau. Cliquez avec le bouton droit sur une interface réseau, puis sélectionnez Propriétés. Cliquez sur Protocole Internet (TCP / IP), puis sélectionnez Propriétés. Dans l'onglet Général, sélectionnez Avancé. Pour spécifier une métrique, dans l'onglet Paramètres IP, désactivez la case à cocher Métrique automatique, puis entrez la métrique de votre choix dans le champ Métrique de l'interface.

Source: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

J'ai rencontré une variante de ce problème, voici les caractéristiques:

• L'utilisateur a réussi à se connecter à une instance nommée, par exemple, des connexions àServer\Instance ont réussi
• L'utilisateur n'a pas pu se connecter à l'instance par défaut, par exemple, les connexions àServer échoué avec la capture d'écran de l'OP concernant SSPI
• L'utilisateur n'a pas pu connecter l'instance par défaut avec un nom complet, par exemple, des connexions à Server.domain.com échoué (délai d'expiration)
• L'utilisateur n'a pas pu se connecter à l'adresse IP sans instance nommée, par exemple, des connexions à 192.168.1.134 échoué
• D'autres utilisateurs ne faisant pas partie du domaine (par exemple, les utilisateurs qui utilisent un VPN sur le réseau) mais utilisant des informations d'identification de domaine ont pu se connecter avec succès à l'instance et à l'adresse IP par défaut

Donc, après de nombreux maux de tête à essayer de comprendre pourquoi cet utilisateur unique ne pouvait pas se connecter, voici les étapes que nous avons prises pour corriger la situation:

1. Jetez un œil au serveur dans la liste SPN en utilisant
   setspn -l Server
   un. Dans notre cas, il a ditServer.domain.com
2. Ajoutez une entrée au fichier d'hôtes 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 était
   Server.domain.com Server

Après cela, nous avons réussi à nous connecter via SSMS à l'instance par défaut.

J'ai aussi 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 essayez de me connecter, cela a fonctionné pour moi.