Le nom principal cible est incorrect. Impossible de générer le contexte SSPI (problème SQL ou AD)?
Nous avons eu une panne de courant la nuit dernière et lorsque le serveur est revenu, nos utilisateurs de domaine n'ont pas pu accéder à notre nom d'instance SQL Server 2000: MASSQL.
Nous pouvons accéder à l'aide de l'authentification SQL.
- Nous avons essayé de nous assurer que l'utilisateur qui exécute le service a la lecture et l'écriture SSPI
- Nous avons essayé de créer un nouvel utilisateur
- Nous avons essayé d'exécuter le service à l'aide du compte NETWORK SERVICE
- Nous avons essayé de fonctionner en tant que compte système local
- Nous avons essayé de créer un nouveau compte d'administrateur de domaine et d'exécuter le service en tant que nouveau compte d'administrateur de domaine
J'ai également exécuté la commande suivante sur l'instance de SQL Server problématique:
setspn -L xsql2
Résultats
ServicePrincipalNames enregistrés pour CN = MASSQL, CN = Computers, DC = ABC, DC = com: Host/MASSQL Host/MASSQL.ABC.COM
J'ai exécuté la commande suivante sur une instance SQL sans problème:
setspn -L xensql1
Résultats
ServicePrincipalNames enregistrés pour CN = XENSQL1, CN = Computers, DC = ABC, DC = com: WSMAN/XENSQL1 WSMAN/XENSQL1.ABC.com RestrictedKrbHost/XENSQL1 Hôte/XENSQL1 RestrictedKrbHost/XENSQL1.ABC.COM Hôte/XENSQL1.ABC.COM
Il semble que les résultats pour l'instance non problématique contiennent plus de données. Je ne sais pas si cela a à voir avec le fait que l'un est 2000 et l'autre 2012.
Que s'est-il probablement passé? Comment autoriser à nouveau les utilisateurs du domaine à se connecter?
Utilisation setspn -X pour rechercher des SPN en double pour le serveur SQL en question.
Supprimez tous les SPN en double qui n'alignent pas le compte de service SQL Server en question.
Les noms principaux de service pour SQL Server prennent la forme:
MSSQLSvc/server.domain: port MSSQLSvc/server: port
En supposant que votre serveur SQL utilise le port par défaut TCP, 1433, je suppose que vous avez besoin des serveurs suivants:
MSSQLSvc/MASSQL.abc.com: 1433 MSSQLSvc/MASSQL: 1433
Vous pouvez créer ces SPN à l'aide de la commande suivante:
SETSPN -A MSSQLSvc/MASSQL.abc.com: 1433 DOMAIN\Account SETSPN -A MSSQLSvc/MASSQL: 1433 DOMAIN\Account
Où DOMAIN\Account est le nom du compte de service utilisé par SQL Server.
Si votre serveur SQL utilise une instance nommée, les commandes SETSPN ressemblent à:
SETSPN -A MSSQLSvc/MASSQL.abc.com: 1433 DOMAIN\Account SETSPN -A MSSQLSvc/MASSQL: 1433 DOMAIN\Account SETSPN -A MSSQLSvc/MASSQL.abc.com: INSTANCENAME DOMAIN\Compte SETSPN -A MSSQLSvc/MASSQL: INSTANCENAME DOMAIN\Account
Les SPN SQL Server ne sont pas définis sur le compte d'ordinateur en soi , mais sur le compte sous lequel SQL Server s'exécute. Vous devrez créer deux SPN pour le service SQL Server si le compte de service n'a pas les autorisations pour créer les SPN. Les exemples suivants supposent l'utilisation du port par défaut 1433.
SetSPN -s "MSSQLSvc/<FQDN_SERVERNAME>" "<DOMAIN>\<SERVICE_ACCOUNT_NAME>"
SetSPN -s "MSSQLSvc/<FQDN_SERVERNAME>:1433" "<DOMAIN>\<SERVICE_ACCOUNT_NAME>"
Voir Enregistrer un nom de principal de service pour les connexions Kerberos
Pour vérifier s'ils sont déjà là:
SetSPN -L ServiceAccountName
Cependant, il semble que vous ayez de plus gros problèmes en jeu. Si vous avez configuré SQL Server pour qu'il s'exécute avec un compte d'administrateur de domaine, il doit avoir été autorisé à créer les SPN.
J'ai eu la même erreur et elle a été corrigée rapidement.
Je travaillais dans un environnement Virtual Server exécutait un script SQL à l'aide de Power Shell. Dans mon cas, je viens de déconnecter la connexion RDP et de me reconnecter au serveur virtuel, l'erreur a disparu.
Microsoft Kerberos Configuration Manager 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/