J'ai une paire de nœuds Microsoft SQL Server 2016 dans un groupe de disponibilité Always On. J'essaie d'effectuer une BULK INSERT
(à l'aide d'une requête SQL Server 2016 Management Studio) sur un fichier situé sur un cluster de basculement de serveur de fichiers Windows Server 2016, mais j'obtiens l'erreur suivante:
Msg 4861, niveau 16, état 1
Impossible de charger en bloc car le fichier "\ nas2.my.domain \ Microsoft SQL Server 2016 Enterprise \ test.txt" n'a pas pu être ouvert. Code d'erreur 5 du système d'exploitation (l'accès est refusé.).
Cela se produira peu importe si j'utilise le nom de nœud actif ( nas2.my.domain
) ou l'écouteur de cluster de basculement ( nas.my.domain
).
Après avoir regardé autour de moi, j'ai découvert que cela était dû au fait que SQL Server ne pouvait pas emprunter l'identité du compte utilisateur avec lequel je suis connecté en raison de nuances BULK INSERT
.
Si vous vous connectez à SQL Server à l'aide de l'authentification Windows, le compte de service SQL Server tente d'emprunter l'identité de votre compte d'utilisateur lors de la connexion au serveur de fichiers. Si vous vous connectez à l'aide de l'authentification SQL Server, il se connectera au serveur de fichiers en tant que compte de service SQL Server.
Si la délégation et l'emprunt d'identité ne sont pas configurés correctement (l'état par défaut), le service SQL Server ne pourra pas emprunter l'identité de votre compte d'utilisateur et reviendra à essayer de se connecter au serveur de fichiers en tant qu'utilisateur anonyme.
Cela peut être confirmé en consultant le journal des événements de sécurité sur le serveur de fichiers. Ces faits ainsi qu'un guide sur la configuration de la délégation sans contrainte et contrainte sont documentés dans ces liens:
J'ai essayé de suivre les instructions du guide de thesqldude mais cela ne fonctionne toujours pas.
La base de données que j'essaye de BULK INSERT
ne fait pas partie du groupe de disponibilité, donc seul le nœud MSSQL1 devrait être pertinent. Le serveur de fichiers était actif sur le nœud NAS2. La vérification du journal des événements sur le serveur de fichiers montre qu'il souffre toujours de ce problème et que SQL Server essaie de s'authentifier auprès du serveur de fichiers en tant qu'utilisateur anonyme plutôt que d'usurper l'identité de mon compte d'utilisateur.
Quelqu'un sait-il ce qui ne va pas? Ou si quelque chose a changé dans SQL Server 2016 pour rendre ces guides obsolètes?
- Entrée du journal des événements de sécurité du serveur de fichiers
- Délégation de compte de service
- SPN du compte de service
- Délégation de compte d'ordinateur SQL Server # 1
- Serveur de fichiers # 2 SPN de compte d'ordinateur
- Objets de stratégie de groupe
sys.dm_exec_connections
- Kerberos
Je peux confirmer que cet objet de stratégie de groupe a été appliqué à MSSQL1 via gpresult.exe /R
, et les nœuds SQL et File Server ont été redémarrés par la suite pour garantir que tous les caches ont été vidés.