L'authentification SQL Server Windows échoue après les mises à jour de sécurité de ce soir: la connexion provient d'un domaine non approuvé

8

Nous avons la configuration suivante:

  • Un contrôleur de domaine ( DC , Server 2003 R2 Standard x64)
  • Un serveur SQL ( SQL , Server 2008 R2 Standard x64)
  • certains clients.

Toutes les machines sont dans le même domaine. Tous les comptes d'utilisateurs utilisés sont des comptes de domaine. SQL exécute une instance de chaque serveur SQL Server 2005, 2008, 2008R2, 2012 et 2014.

Depuis ce soir ( DC redémarré pour installer les mises à jour de sécurité Windows automatiques), l'accès aux instances SQL 2005, 2008 et 2008R2 via l'authentification Windows ne fonctionne plus correctement:

Lors de l'accès à l'une de ces instances

  • de l'un des clients
  • à l'aide de l'authentification Windows

l'erreur suivante se produit (c'est le message 2008R2, les messages 2005/2008 sont similaires):

É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)

De toute évidence, le texte du message ne s'applique pas, car il n'y a qu'un seul domaine.

Maintenant, la chose surprenante est: dès que l'utilisateur est connecté à SQL (démarrer une session RDP ou même simplement exécuter runas /user:MYDOMAIN\someuser cmdet garder la fenêtre ouverte), cet utilisateur peut accéder à toutes les instances SQL Server à partir de tous les clients sans aucun problème jusqu'à ce que le processus s'exécute avec les informations d'identification de cet utilisateur sont fermées.

Cela signifie que je peux simplement contourner ce problème en exécutant la commande runas ci-dessus pour tous les utilisateurs sur SQL une fois (et en gardant les fenêtres ouvertes), mais, évidemment, quelque chose est gravement cassé. Je soupçonne que les mises à jour de sécurité de ce soir sur DC ont quelque chose à voir avec cela (puisque c'est la seule chose qui a changé), mais je préfère éviter de désinstaller et de redémarrer chacune d'elles (12 mises à jour ont été installées et DC est vraiment ancien et lent).

Quelqu'un a-t-il déjà rencontré ce problème et sait comment le résoudre définitivement? Avez-vous d'autres idées (à part passer les prochains jours à devenir un expert Kerberos)?

Heinzi
la source
Avez-vous vérifié l'horloge de votre DC? Bien que je ne puisse pas expliquer la différence d'instance, une horloge incorrecte d'un contrôleur de domaine provoque le comportement que vous expliquez lorsque vous vous limitez à regarder une instance. Vous pouvez également envisager de mettre à niveau votre système d' exploitation DC à l' approche de la fin de vie.
Réagit
@Reaces: Merci pour l'indice, mais les horloges sont parfaitement synchrones. Oui, le DC est la prochaine machine dont le remplacement est prévu.
Heinzi

Réponses:

7

vérifiez si votre DC a installé la mise à jour KB3002657 ce soir. voir http://support2.microsoft.com/?kbid=3002657 J'ai eu le même problème. La désinstallation de cette mise à jour a résolu le problème pour moi.

Simon
la source
Bien repéré, je viens de le découvrir moi-même et je voulais écrire exactement la même chose. :-) Apparemment, KB3002657 cause beaucoup de problèmes aujourd'hui .
Heinzi
Certains clients afficheront le message d'erreur "La connexion provient d'un domaine non approuvé". par exemple, si vous vous connectez via RDP ou à un serveur MSSQL. Supprimez simplement l'hôte auquel vous souhaitez vous connecter de votre domaine et ajoutez-le à nouveau.
simson
2

Le correctif suivant via la stratégie de groupe a fonctionné pour moi:

  1. Administrateur de stratégie de groupe ouverte
  2. Accédez à Configuration ordinateur >> Paramètres Windows >> Politiques locales >> Options de sécurité
  3. Double-cliquez sur "Sécurité réseau: niveau d'authentification LAN Manager"
  4. Changer l'option de "Envoyer les réponses NTLM" à "Envoyer les réponses LM & NTLM"
  5. Exécutez gpupdate /forcesur les ordinateurs et serveurs affectés.
Ron DeFulio
la source