Erreur de connexion Windows Auth SQL Server 2008: la connexion provient d'un domaine non approuvé

Lors de la tentative de connexion à une instance SQL Server 2008 à l'aide de Management Studio, j'obtiens l'erreur suivante:

Échec de la connexion. La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows. (Microsoft SQL Server, erreur: 18452)

Je peux me connecter en utilisant l'authentification SQL sans problème. J'ai eu cette erreur tout d'un coup. L'authentification en mode mixte est activée.

Est-ce que quelqu'un a de l'expérience avec ça?

Informations supplémentaires: version 64 bits de SQL Enterprise Edition sur Windows 2003 Server

Une autre raison pour laquelle cela pourrait arriver (m'est arrivé) ... est l'expiration du mot de passe de l'utilisateur. Je ne m'en suis rendu compte que lorsque j'ai essayé de me connecter à distance au serveur réel et que j'ai été invité à changer mon mot de passe.

Pour moi, cela s'est produit lorsque j'ai modifié un drivers/etc/hostsfichier vierge et ajouté une entrée pour un site Web local, mais j'ai négligé d'ajouter127.0.0.1 localhost

Le problème était dû à un serveur Active Directory en panne, qui, bien sûr, ne pouvait pas authentifier le compte Windows. Merci pour votre aide.

Pour toute autre personne qui rencontre cela, j'avais ceci dans mon fichier hosts:

127.0.0.1   localhost
127.0.0.1   customname

et j'avais besoin que ce soit ceci:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"Le problème a été causé par un serveur Active Directory en panne, qui n'a bien sûr pas pu authentifier le compte Windows"

Ce n'est pas "bien sûr - car si AD n'est pas disponible, l'authentification Kerberos revient à NTLM (les informations d'identification du compte de domaine sont mises en cache localement, on peut se connecter avec elle même si AD / Kerberos n'est pas disponible). Je suppose que vous avez peut-être 2 conditions simultanées pour que cet échec se produise:

• SQL Server n'est pas local (sur une autre machine)
• L’approbation est configurée «Kerberos uniquement»

ou d'autres configurations spécifiques de réseau / serveur / AD / machine de sécurité

J'ai eu ce problème pour une instance de serveur sur ma machine locale et j'ai trouvé que c'était parce que je pointais vers 127.0.0.1 avec autre chose que "localhost" dans mon fichier hosts. Il existe deux façons de résoudre ce problème dans mon cas:

1. Effacez l'entrée incriminée pointant vers 127.0.0.1 dans le fichier hosts
2. utilisez "localhost" au lieu de l'autre nom qui dans le fichier hosts qui pointe vers 127.0.0.1

* Cela n'a fonctionné pour moi que lorsque j'exécutais l'instance de serveur SQL sur ma boîte locale et que j'essayais d'y accéder à partir de la même machine.

Assurez-vous que vous n'êtes pas connecté à un VPN sur un autre domaine \ utilisateur . Ou, inversement, assurez-vous que vous êtes connecté, si c'est ce qui est nécessaire.

J'ai résolu ce problème sur la machine désactivant le paramètre de vérification de bouclage:

1. Modifiez le registre Windows: Démarrer -> Exécuter> Regedit
2. Accédez à: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Ajoutez une valeur DWORD appelée "DisableLoopbackCheck"
4. Définissez cette valeur sur 1

essayez d'utiliser une autre connexion valide à l' aide de la commande RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Pour moi, c'était parce que je n'ai pas ajouté le compte pour avoir les rôles que je voulais utiliser dans la base de données SQL elle-même. Et aussi en raison de mauvaises tentatives de mot de passe via un compte de verrouillage de problème de copier-coller.

D'accord, répondez complètement de ma part. J'obtenais cette erreur d'un environnement de développement hébergé sur VM VirtualBox. Trois serveurs; SharePoint, SQL DB et contrôleur de domaine. Le serveur SharePoint n'a pas pu se connecter à la base de données de configuration. Je pourrais toujours me connecter via ODBC pour l'authentification SQL en utilisant le compte SA mais pas l'authentification Windows. Mais cet utilisateur se connecterait volontiers à SSMS sur le serveur SQL lui-même. J'ai également reçu un meilleur message d'erreur d'ODBC et également en vérifiant les messages de connexion échoués sur le serveur SQL:

select text from sys.messages where message_id = '18452' and language_id = 1033

Je ne peux pas m'en attribuer le mérite, car j'ai demandé de l'aide à l'un de nos administrateurs de systèmes d'entreprise et il l'a diagnostiqué en environ 5 minutes après avoir regardé quelques captures d'écran que je lui ai envoyées. Le problème était que l'horloge du contrôleur de domaine n'était pas réglée correctement! Je ne pouvais pas y croire. Les serveurs sont configurés pour la mise en réseau de l'hôte uniquement, vous n'avez donc pas Internet avec lequel synchroniser l'horloge. Cela explique également pourquoi revenir à un instantané antérieur alors que je sais que le système fonctionnait n'a pas résolu le problème.

Modifier: l'installation des suppléments invité sur le serveur synchronise l'horloge de l'invité avec l'hôte.

Il existe un paramètre sur le pilote jTDS appelé USENTLMV2 qui est défini sur false par défaut. Définir ceci sur «vrai» dans mon logiciel de base de données (DBVisualizer) l'a résolu.

Un autre scénario dans lequel vous pouvez voir cela est lorsque vous essayez de vous connecter à un autre serveur SQL à partir d'une session SSMS qui était déjà connectée pendant que vous avez modifié votre mot de passe. La séquence des événements peut ressembler à quelque chose comme:

1. RDP vers Server-A (votre serveur SQL), ouvrez SSMS et connectez-vous
2. RDP vers Server-B dans le même domaine et modifiez votre mot de passe
3. Revenez à la session RDP sur le serveur-A et via SSMS, essayez d'ajouter une autre base de données dans un groupe de disponibilité AlwaysOn existant. Lors de la connexion à des réplicas, vous obtenez une erreur de connexion "domaine non approuvé"

Pour résoudre, déconnectez-vous et reconnectez-vous

Vous pouvez être induit en erreur sur le nom d' utilisateur que vous utilisez localement. C'était mon cas dans Windows 10 Famille. Quand je regarde les utilisateurs dans le panneau de configuration, je vois le nom usrpc01 . Cependant, lorsque je tape net config workstation, il apparaît que le nom de l'utilisateur est spc01 . On dirait que quelqu'un a renommé l'utilisateur, mais le nom interne est resté inchangé.

Ne sachant pas comment réparer le nom d'utilisateur Windows (et le nom du dossier sous C:\Users, qui fait également référence au nom interne d'origine), j'ai ajouté un nouveau compte utilisateur sur mon serveur db.

J'ai essayé de me connecter à un SQL Server 2008 à partir d'un compte de domaine. SQL Server 2008 est hébergé sur un autre ordinateur de groupe de travail qui ne fait pas partie du domaine. Aussi étrange que cela puisse paraître, sur le serveur de groupe de travail où s'exécute SQL Server 2008, j'ai dû accéder à Propriétés système | Nom de l'ordinateur (onglet) | Changer (bouton) | Changement de nom d'ordinateur | Plus ... (bouton) et entrez le "Suffixe DNS principal de cet ordinateur" (il était vide, alors entrez le suffixe souhaité pour votre réseau) et cochez la case "Changer le suffixe DNS principal lorsque l'appartenance au domaine change". Cela a permis au processus d'authentification Windows de se terminer lors de la connexion à SQL Server 2008.

J'ai dû utiliser netonly pour que cela fonctionne sur Windows moderne:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Une autre raison> quelqu'un a changé le mot de passe de l'utilisateur SQL par défaut

cela m'est arrivé il y a quelques minutes en passant à un nouveau contrôleur de domaine ...

J'ai eu une mauvaise entrée dans le fichier d'hôtes sous C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Assurez-vous d'avoir une entrée comme ci-dessous

127.0.0.1   localhost
127.0.0.1   localhost   servername

J'utilisais un alias pour une instance SQL Server qui pointait vers "127.0.0.1". Le changer en "localhost" a fait l'affaire.

Si votre serveur SQL s'exécute sur un serveur qui ne fait pas partie d'un domaine et que dans la chaîne de connexion, vous utilisez un nom de domaine entièrement qualifié (par exemple xyz.mypc.com) avec Integrated Security = True, vous devrez peut-être passer à l'adresse IP, MachineName (SERVER01) ou le point (.) s'il est hébergé localement.

Cela a fonctionné pour moi, l'utilisation de la fqdn a entraîné l'erreur ci-dessus.

Afin d'activer l'authentification Windows, les deux ordinateurs doivent être dans le même domaine. afin de permettre aux studios de gestion de transmettre les informations d'identification actuelles et de s'authentifier dans la boîte SQL

Pour moi, je dois me déconnecter (changer de groupe de travail / domaine) du domaine et me reconnecter.

Et une autre raison possible: le nouveau compte local créé sur le serveur DB avait le drapeau: «L'utilisateur doit changer de mot de passe à la prochaine connexion».

Voici ce qui a résolu le problème pour moi: Propriétés de la connexion réseau Cliquez sur: "Internet Protocol Version 4 (TCT / IPv4)". Cliquez sur le bouton "Propriétés". Cliquez sur le bouton "Avancé". Sélectionnez l'onglet "DNS". Supprimer le texte dans "Suffixe DNS pour cette connexion".

Je n'ai pas non plus pu me connecter à distance au serveur SQL. Le serveur SQL et le serveur distant se trouvent dans le même domaine. Et on m'avait demandé un changement de mot de passe quelques jours auparavant. Le redémarrage du serveur SQL et du serveur distant à partir duquel j'essayais d'accéder au serveur SQL a fait l'affaire pour moi.

Dans notre cas, c'était le fait que le développeur exécutait le pool d'applications sous son propre compte, avait réinitialisé son mot de passe mais avait oublié de le changer sur le pool d'applications. Duh ...

Dans mon cas, le serveur avait été désactivé dans le contrôleur de domaine. Je suis allé dans l'unité d'organisation ORDINATEURS dans l'annuaire actif, j'ai cliqué avec le bouton droit sur le serveur, je l'ai activé, puis j'ai fait un gpupdate / force à partir du serveur SQL. Cela a pris un moment, mais cela a finalement fonctionné.

Dans mon cas, dans le fichier hôte, le nom de la machine est codé en dur avec une IP plus ancienne. Je remplace l'ancienne IP par la nouvelle, le problème est résolu.

Emplacement du fichier hôte

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Modifications effectuées 159.xx.xx.xxx MachineName

Aucun de ces éléments n'a fonctionné pour moi. Ce que j'avais à faire était: Dans SQL Server Management Studio sur l'écran de connexion, sélectionnez Options >> Dans la section Réseau, changez le protocole réseau en canaux nommés.

En outre, ce que je devais faire pour le faire fonctionner avec le <default>paramètre était de désactiver le réseau sans fil (la machine était également connectée au réseau filaire).

Ma solution consistait à modifier le fichier web.config pour qu'il corresponde à mon nouveau nom de serveur pour SQL Connection (IT Security venait juste de renommer netdom sur ma boîte de développement.