Erreurs SSPI pour l'authentification SQL Server?

Question

Nous avons plusieurs anciennes applications Web ASP et PHP qui utilisent l'authentification SQL Server. Périodiquement, toutes les applications perdent la possibilité de se connecter à notre serveur de base de données SQL Server 2000, obtenant l'accès refusé.

correspondant à peu près les mêmes temps, nous obtenons

1115 Cannot generate SSPI Context SQLSTATE HY000 

erreurs sur le serveur SQL Server 2000.

Et voici la partie étrange - le redémarrage du serveur web résout le problème. Le redémarrage du serveur de base de données n'a aucun effet. Cela n'a aucun sens pour moi - je ne pensais pas que SSPI était impliqué dans l'authentification SQL Server.

Des idées?

Edit:

Quelques détails supplémentaires:

Le serveur Web est dans la zone démilitarisée. Le fichier hosts sur le serveur web a une entrée pour le serveur de base de données (et l'adresse IP est correcte), donc le serveur web (théoriquement au moins) ne devrait même pas aller au DNS pour se connecter au serveur de base de données.

Cela ne semble pas être un problème de pare-feu.

Answer 1

Je pense que vous avez raison, cette erreur n'est pas associée à l'authentification SQL dans mon expérience. Le serveur Web est-il derrière un pare-feu? Des modifications ont-elles été apportées au fichier "hosts" sur l'un ou l'autre des serveurs? Avez-vous essayé d'envoyer une requête ping au serveur SQL à partir du serveur Web lorsque vous rencontrez ces problèmes pour vous assurer que le serveur Web est capable de résoudre le nom du serveur SQL? Je vérifierais le moniteur d'activité dans Enterprise Manager pour être sûr que les applications Web se connectent définitivement à l'aide de l'authentification SQL. Une possibilité est un problème de réseau ou de contrôleur de domaine - qui expliquerait les connexions supprimées du serveur Web et les erreurs de contexte SSPI sur le serveur SQL, mais pas sûr pourquoi le redémarrage du serveur Web le résoudrait.

Answer 2

Nous avait ceci entre nos serveurs principaux et quelques clients dans d'autres pays.

Le Kerberos sous-jacent perd l'intrigue (terme technique :-) s'il y a trop de retard (par exemple des pare-feu) entre ici et là. Nous l'avons corrigé en spécifiant le port. En outre, je suggère d'utiliser le nom de domaine complet du serveur. Nous utilisons maintenant: "SQLServer.domain.tld \ InstanceName, 1234"