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:

• Comment: insertion en bloc SQL Server avec délégation contrainte (l'accès est refusé)

• Insertion en vrac et Kerberos

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 INSERTne 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.

Votre configuration semble solide. Les SPN et la délégation sont configurés comme je l'aurais fait moi-même.

La seule chose que vous n'avez pas expliquée est les autorisations de fichier / partage. C'est là que ma solution intervient.

Solution 1 (compte personnel)

1. Vérifiez que votre compte personnel est autorisé à accéder au fichier sur le partage du serveur de fichiers
   • votre compte personnel a besoin d'au moins les autorisations de lecture au niveau des autorisations de partage ou dans la plupart des cas, vous pouvez voir que TOUT LE MONDE a l'autorisation de lecture.
   • votre compte personnel a besoin au moins des autorisations de lecture au niveau d'autorisation du fichier
   • Vérifier l'héritage des autorisations au niveau du fichier pour ce seul fichier
     • Redémarrez le serveur SQL après avoir modifié les autorisations de fichier ou faites un cycle le service SQL Server.
   • Alternativement: connectez-vous à SQL Server avec votre compte personnel et connectez-vous au partage et ouvrez le fichier.
2. Ouvrez SSMS avec votre compte personnel .
3. Ouvrez une connexion à votre instance SQL Server avec l'authentification Windows.
   • Vérifiez que vous êtes connecté à votre instance avec le compte de service SQL Server avec le script que vous avez utilisé auparavant.
4. Effectuer l'importation avec BULK INSERT

Solution 2 (compte de service SQL Server)

1. Vérifiez que le compte de service SQL Server est autorisé à accéder au fichier sur le partage du serveur de fichiers
   • le compte de service SQL Server a besoin d'au moins des autorisations de lecture au niveau des autorisations de partage ou dans la plupart des cas, vous pouvez voir que TOUT LE MONDE dispose d'autorisations de lecture.
   • le compte de service SQL Server a besoin d'au moins des autorisations de lecture au niveau d'autorisation du fichier
   • Vérifier l'héritage des autorisations au niveau du fichier pour ce seul fichier
     • Redémarrez le serveur SQL après avoir modifié les autorisations de fichier ou faites un cycle le service SQL Server.
   • Sinon: connectez-vous à SQL Server avec le compte de service SQL Server et connectez-vous au partage et ouvrez le fichier.
2. Ouvrez SSMS avec le compte de service SQL Server .
   • Runas: votre_domaine \ SQL_Server_service_account
   • Fournir un mot de passe
3. Ouvrez une connexion à votre serveur SQL avec authentification Windows.
   • Vérifiez que vous êtes connecté à votre instance avec le compte de service SQL Server avec le script que vous avez utilisé auparavant.
4. Effectuer l'importation avec BULK INSERT

Autorisations BULK INSERT

Délégation de compte de sécurité (emprunt d'identité)

Si un utilisateur utilise une connexion SQL Server, le profil de sécurité du compte de processus SQL Server est utilisé. Une connexion utilisant l'authentification SQL Server ne peut pas être authentifiée en dehors du moteur de base de données. Par conséquent, lorsqu'une commande BULK INSERT est lancée par une connexion utilisant l'authentification SQL Server, la connexion aux données est établie à l'aide du contexte de sécurité du compte de processus SQL Server (le compte utilisé par le service SQL Server Database Engine ). Pour lire correctement les données source, vous devez accorder au compte utilisé par le moteur de base de données SQL Server l'accès aux données source. En revanche, si un utilisateur SQL Server ouvre une session à l'aide de l' authentification Windows, l'utilisateur ne peut lire que les fichiers auxquels le compte utilisateur peut accéder, quel que soit le profil de sécurité du processus SQL Server.

Référence: BULK INSERT (Transact-SQL)

D'après mon expérience avec la délégation, le compte de service SQL Server a besoin des autorisations appropriées sur le partage auquel il tente d'accéder en votre nom. Avez-vous ajusté ces autorisations? Je pense que la lecture seule suffirait dès le départ.