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

89

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é.

entrez la description de l'image ici

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.

Le bord
la source
Nous n'exécutons pas de serveur DNS interne. Mais pour éliminer cela comme un problème, dites-vous que je devrais "ping -a xxxx" ou y a-t-il un autre moyen de déterminer s'il y a des doublons?
TheEdge
Je ne suis pas un expert mais je pensais que les SPN et SSPI étaient une chose Kerberos? Êtes-vous sûr de ne pas utiliser Kerberos?
Dylan Smith
@DylanSmith Pas que je puisse voir ..... Quand j'ai exécuté SP dans SQL Server (Oubliez le nom maintenant), tout est venu comme NTLM. Savez-vous comment je vérifie?
TheEdge
Je sais que la question est ancienne, alors gagnez du temps et exécutez cet outil: microsoft.com/en-us/download/…
Eduardo

Réponses:

57

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.

Slothario
la source
1
C'était mon problème. Mot de passe changé. mon compte exécutait le pool d'applications.
Dragos Durlut
quand j'ai eu ce problème, je me suis déconnecté et je me suis reconnecté. Résolution du problème.
shary.sharath
Problème similaire. Cela m'a aidé à revenir sur mes actions. TQ
Reddy
24

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.

Matt Shepherd
la source
22

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

Anatolyevich
la source
Comment supprimez-vous cela si la connexion se fait via SSMS?
Geoff Dawdy
23
Eh bien, la suppression clairement Integrated Security va éviter cette erreur, parce que l'erreur se produit lorsque vous essayez de vous connecter avec vos informations d' identification Windows. Malheureusement, la plupart du temps, vous voulez pouvoir vous connecter avec vos identifiants Windows!
Auspex
2
@GeoffDawdy ma réponse ci-dessous peut vous aider? Cela était dû à un mot de passe expiré, m'obligeant à changer mon mot de passe, à me déconnecter et à me reconnecter, puis tout fonctionnait normalement.
Matt Shepherd
3
Gagnez du temps et exécutez cet outil: microsoft.com/en-us/download/…
Eduardo
15

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é.

Abubakar Mehmood
la source
12

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.

Don
la source
C'est ridicule. Et ça a marché. J'ai perdu tellement de temps là-dessus. Merci!
mcb2k3
2
Oups, ce n'était pas tout à fait ça. SSMS a fait un interrupteur sur moi lorsque je ne cherchais pas et est retourné à mon compte SQL Server. Mais j'ai finalement essayé de passer de l'utilisation d'un compte Microsoft pour se connecter localement à l'utilisation d'un compte local localement. Cela a fait l'affaire, et cela semble fonctionner maintenant même si je me connecte à l'aide de mon code PIN.
mcb2k3
Ouais, utiliser le mot de passe au lieu de la broche a également fonctionné pour moi. +1 pour Microsoft.
BrunoMartinsPro
OMG! Je ne peux pas croire que cela ait fait une différence!
arni
8

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.

Alex
la source
7

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

entrez la description de l'image ici

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/

Sarah
la source
Cela a résolu le problème pour moi. Les SPN ont été enregistrés sur le mauvais objet utilisateur dans Active Directory. Le gestionnaire de configuration Kerberos pour SQL Server l'a corrigé en deux clics!
Craig - MSFT
6

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"

user685590
la source
J'ai eu un problème similaire (vpn iMac avec une machine virtuelle Windows). Je l'ai résolu en ajoutant les serveurs DNS de mon travail aux paramètres du réseau Wi-Fi de mon Mac. Je suppose qu'il existe un meilleur moyen, mais cela a fonctionné pour moi.
Erik Pearson
5

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.

Frank.Germain
la source
a fait votre réponse sur mon ordinateur client et SQL box plus ipconfig/releaseet ipconfig/renewsur mon ordinateur client et cela n'a pas fonctionné pour moi; (
AlbatrossCafe
4

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
    

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

EM0
la source
J'ai fait passer une instance MS SQL Server de l'exécution en utilisant NT Service\MSSQLSSERVERà l'exécution en tant que compte de service géré. Après cela, SSMS pourrait se connecter à la base de données localement sur le serveur, mais pas à distance depuis mon ordinateur portable. La correction des SPN a résolu le problème.
Hydrargyrum
4

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

mxasim
la source
Idem SQL Server 2016.
youcantryreachingme
4

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.

Graham Walker
la source
3

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
  1. 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>
    
  2. 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>
  1. 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

Nate S.
la source
2

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.

Ramki
la source
2

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.

Daniel Bailey
la source
1

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.

Greg
la source
Ce problème ne m'est arrivé que lorsque j'ai ajouté un certificat à la connexion SQL. Le certificat a été délivré au FQDN, donc lorsque je me connecte à FQDN \ Instance, cela a fonctionné.
Slogmeister Extraordinaire
1

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.

CrainBramp
la source
1

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.

Questions101
la source
J'ai eu ce même problème, mais ce n'était pas sur un cluster. J'avais changé la connexion pour le service SQL Engine en un compte de domaine. J'ai dû supprimer les MSSQLSvc/SERVER_FQNName:*SPN du compte d'ordinateur, puis les ajouter au compte d'utilisateur exécutant le service.
Slogmeister Extraordinaire
1

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.

AlbatrosCafé
la source
Expérience similaire, SQLServer 2016 sur VM. Je ne sais pas pourquoi les connexions ont commencé à échouer. Le redémarrage de la VM l'a corrigé sans avoir besoin de redémarrer le client.
youcantryreachingme
1

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.

Jeff
la source
C'est ce que j'ai fait après avoir comparé setspn -L <Hostname>avec un serveur qui fonctionnait. Il s'est avéré que toutes les instances qui fonctionnaient n'avaient aucun SPN enregistré. Je ne sais pas vraiment ce que je fais, mais apparemment sans ces SPN enregistrés, NTLM peut être utilisé. Merci!
BenderBoy
Sachez que ce n'est pas vraiment une solution si vous souhaitez utiliser Kerberos au lieu de NTLM, comme vous devriez apparemment: serverfault.com/a/384721 . En fait, cette solution désactive essentiellement l'authentification Kerberos.
BenderBoy
1

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.

somu
la source
1

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.

Julie
la source
J'ai mis le mien sur "TCP / IP". Je ne sais pas si le fait de le changer a résolu le problème ou le paramètre spécifique à ma situation réseau ...
Zarepheth
1

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é.

Como ficou minha configuração do DNS

kbral
la source
1

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.
S3minaki
la source
1
J'ai eu le même message. J'essayais de me connecter avec IP alors j'ai fait comme stackoverflow.com/users/8568873/s3minaki , c'est-à-dire les étapes 1 à 6 mais j'ai activé TCP / IP au lieu de Named Pipes. Également sous IPALL, j'ai effacé le port dynamique TCP et défini le port TCP à la place. Assurez-vous qu'aucune autre instance n'exécute ce port, sinon l'instance ne redémarrera pas. J'avais également besoin d'un utilisateur SQL, l'authentification Windows ne fonctionnera pas. Dans SQL Manager, vous vous connectez avec xxxx \ instancename, portnr. ie 127.0.0.1 \ SQLEXPRESS, 1433
Tomas Hesse
1

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.

Michael Csikos
la source
1

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é.

El_01
la source
1

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

user2442020
la source
0

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.

sorrell
la source
0

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.

harikrishna puppala
la source