Tengo un par de nodos de Microsoft SQL Server 2016 en un grupo de disponibilidad siempre activo. Estoy tratando de realizar un BULK INSERT(usando una consulta SQL Server 2016 Management Studio) en un archivo ubicado en un clúster de conmutación por error del servidor de archivos de Windows Server 2016, pero aparece el siguiente error:

Msg 4861, Nivel 16, Estado 1
No se puede cargar en bloque porque el archivo "\ nas2.my.domain \ Microsoft SQL Server 2016 Enterprise \ test.txt" no se pudo abrir. Código de error del sistema operativo 5 (acceso denegado).

Esto ocurrirá independientemente de si uso el nombre de nodo activo ( nas2.my.domain) o el escucha de clúster de conmutación por error ( nas.my.domain).

Después de mirar alrededor, descubrí que esto se debía a que SQL Server no podía suplantar la cuenta de usuario con la que estoy conectado debido a matices BULK INSERT.

Si se conecta a SQL Server mediante la autenticación de Windows, la cuenta de servicio de SQL Server intenta suplantar su cuenta de usuario cuando se conecta al servidor de archivos. Si se conecta utilizando la autenticación de SQL Server, se conectará al servidor de archivos como la cuenta de servicio de SQL Server.

Si la delegación y la suplantación no están configuradas correctamente (el estado predeterminado), el servicio SQL Server no podrá suplantar su cuenta de usuario y volverá a intentar conectarse al servidor de archivos como un usuario anónimo.

Esto puede confirmarse mirando a través del registro de eventos de seguridad en el servidor de archivos. Estos hechos junto con una guía sobre la configuración de la delegación restringida y sin restricciones se documenta en estos enlaces:

• Cómo: Inserción masiva de SQL Server con delegación restringida (acceso denegado)

• Inserción masiva y Kerberos

He intentado seguir las instrucciones de la guía de SQLdude pero todavía no funciona.

La base de datos a la que estoy intentando BULK INSERTacceder no forma parte del grupo de disponibilidad, por lo que solo el nodo MSSQL1 debería ser relevante. El servidor de archivos estaba activo en el nodo NAS2. La comprobación del registro de eventos en el servidor de archivos muestra que todavía está sufriendo este problema y que SQL Server está intentando autenticarse en el servidor de archivos como un usuario anónimo en lugar de suplantar mi cuenta de usuario.

¿Alguien sabe qué va mal? ¿O si algo cambió en SQL Server 2016 para hacer que estas guías sean obsoletas?

• Entrada del registro de eventos de seguridad del servidor de archivos
• Delegación de cuenta de servicio
• SPN de cuenta de servicio
• SQL Server # 1 Delegación de cuenta de computadora
• SPN de cuenta de computadora del servidor de archivos n. ° 2
• Objetos de directiva de grupo
• sys.dm_exec_connections - Kerberos

Puedo confirmar que este GPO se ha aplicado a MSSQL1 a través de gpresult.exe /R, y tanto los nodos de SQL como del servidor de archivos se reiniciaron después para garantizar que las cachés se hayan vaciado.

Su configuración se ve sólida. Los SPN y la Delegación están configurados como lo habría hecho yo mismo.

Lo único que no ha explicado son los permisos de archivo / recurso compartido. Aquí es donde entra mi solución.

Solución 1 (cuenta personal)

1. Verifique que su cuenta personal tenga acceso al archivo en el recurso compartido del servidor de archivos
   • su cuenta personal necesita al menos permisos de LECTURA en el nivel de permiso compartido o, en la mayoría de los casos, puede ver que TODOS tienen permiso de LECTURA.
   • su cuenta personal necesita al menos permisos de LECTURA en el nivel de permiso del archivo
   • Verifique la herencia de permisos a nivel de archivo para ese archivo
     • Reinicie el servidor SQL después de cambiar los permisos del archivo o ciclo el servicio del servidor SQL.
   • Alternativamente: Inicie sesión en SQL Server con su cuenta personal y conéctese al recurso compartido y abra el archivo.
2. Abra SSMS con su cuenta personal .
3. Abra una conexión a su instancia de SQL Server con la autenticación de Windows.
   • Verifique que está conectado a su instancia con la cuenta de servicio de SQL Server con el script que ha utilizado anteriormente.
4. Realice la importación con BULK INSERT

Solución 2 (Cuenta de servicio de SQL Server)

1. Verifique que la cuenta de servicio de SQL Server pueda acceder al archivo en el recurso compartido del servidor de archivos
   • la cuenta de servicio de SQL Server necesita al menos permisos de LECTURA en el nivel de permiso compartido o, en la mayoría de los casos, es posible que TODOS tengan permisos de LECTURA.
   • la cuenta de servicio de SQL Server necesita al menos permisos de LECTURA en el nivel de permiso del archivo
   • Verifique la herencia de permisos a nivel de archivo para ese archivo
     • Reinicie el servidor SQL después de cambiar los permisos del archivo o ciclo el servicio del servidor SQL.
   • Alternativamente: Inicie sesión en SQL Server con la cuenta de servicio de SQL Server y conéctese al recurso compartido y abra el archivo.
2. Abra SSMS con la cuenta de servicio de SQL Server .
   • Runas: your_domain \ SQL_Server_service_account
   • Proporcionar contraseña
3. Abra una conexión a su servidor SQL con la autenticación de Windows.
   • Verifique que está conectado a su instancia con la cuenta de servicio de SQL Server con el script que ha utilizado anteriormente.
4. Realice la importación con BULK INSERT

Permisos de INSERTAR A GRANEL

Delegación de cuenta de seguridad (suplantación)

Si un usuario usa un inicio de sesión de SQL Server, se usa el perfil de seguridad de la cuenta de proceso de SQL Server. Un inicio de sesión con autenticación de SQL Server no se puede autenticar fuera del Motor de base de datos. Por lo tanto, cuando se inicia un comando BULK INSERT mediante un inicio de sesión utilizando la autenticación de SQL Server, la conexión a los datos se realiza utilizando el contexto de seguridad de la cuenta de proceso de SQL Server (la cuenta utilizada por el servicio del Motor de base de datos de SQL Server ). Para leer con éxito los datos de origen , debe otorgar acceso a los datos de origen a la cuenta utilizada por el Motor de base de datos de SQL Server. Por el contrario, si un usuario de SQL Server inicia sesión mediante la autenticación de Windows, el usuario solo puede leer aquellos archivos a los que puede acceder la cuenta de usuario, independientemente del perfil de seguridad del proceso de SQL Server.

Referencia: BULK INSERT (Transact-SQL)

En mi experiencia con la delegación, la cuenta de servicio de SQL Server necesita los permisos adecuados para el recurso compartido al que intenta acceder en su nombre. ¿Has ajustado esos permisos? Creo que leer solo sería suficiente por adelantado.