"Acceso denegado" al conectar SSMS a Integration Services

17

Recibo el siguiente error cuando intento conectar SSMS a Integration Services usando el nombre de red de un clúster de SQL Server en particular:

La conexión al servicio de Integration Services en la computadora 'FooDB' falló con el siguiente error: "Acceso denegado".

Este error se produce cuando la computadora no se ha configurado para permitir conexiones remotas a través de DCOM, o el usuario tiene permiso para acceder al servicio SQL Server Integration Services a través de DCOM.

Este es un problema de rutina con una solución bien documentada. Por ejemplo, vea las soluciones aquí y aquí .

Sin embargo, he probado todas las soluciones que conozco y el problema persiste.

Con más detalle, he hecho lo siguiente:

  • Verificó que los usuarios que se conectan tienen los permisos DCOM enumerados en los artículos vinculados anteriormente en MsDtsServer100:

    1. Permisos de lanzamiento y activación: Permitir lanzamiento local, permitir lanzamiento remoto, activación local, activación remota

    2. Permisos de acceso: Permitir acceso local, permitir acceso remoto

    3. Permiso de configuración: permitir lectura

  • Se confirmó con un sniffer de paquetes que todo el tráfico relacionado con la conexión llega con éxito a través del firewall. El último paquete que se muestra antes de que se rompa la conexión TCP es una respuesta del servidor que contiene el código de estado de Windows para 'acceso denegado' dentro de un encabezado MSRPC.

  • Probé agregando a los usuarios al grupo 'Usuarios de COM distribuidos' y / o al grupo de administradores locales, luego reiniciamos los servidores. Esto permitió a los usuarios conectarse a SSIS desde SSMS utilizando los nombres de nodos locales (FooDBN1, FooDBN2), pero aún así obtienen un error de 'acceso denegado' cuando se conectan al nombre de red del clúster (FooDB), que es lo que están acostumbrados. para usar, y lo que funciona en nuestros otros grupos.

Además, no he encontrado la alteración de la membresía de estos grupos necesaria en otros grupos.

En los otros clústeres que he comprobado, puedo conectar SSMS a SSIS usando el nombre del clúster sin ninguna configuración no predeterminada.

Me doy cuenta de que esto podría ser más apropiado para ServerFault y estoy de acuerdo con que la pregunta se migre si es necesario, pero también es un problema de SQL Server y creo que los usuarios aquí podrían tener más probabilidades de haberlo tratado antes.

Detalles de la plataforma:

  • Windows Server 2008 R2 SP1
  • SQL Server 2008 R2 SP2
  • Clúster activo-pasivo de 2 nodos con una sola instancia de SQL Server

¿Alguien podría sugerir lo que debería estar viendo aquí?

Actualización : esto misteriosamente comenzó a funcionar hoy, pero solo para miembros del grupo de administradores locales. Nada ha cambiado hasta donde puedo decir.

sql-server windows ssis permissions clustering James L
fuente
1
Si está utilizando el grupo de Administradores, puede ser mordido por el enmascaramiento de privilegios UAC. Intente crear un nuevo grupo o conceda permisos de usuario individuales directamente en la aplicación SSIS DCOM.
db2
Si tiene un clúster, los usuarios deben conectarse al alias del clúster, no a máquinas individuales. Es el caso?
Stoleg
Sí, deberían usar el nombre del clúster, no el nombre del nodo individual. Sin embargo, por alguna razón, el error solo ocurre cuando se usa el nombre del clúster.
James L
No tenemos UAC habilitado en los clientes o el servidor, pero voy a tratar de otorgar permisos DCOM a usuarios individuales en lugar de grupos y ver si eso hace alguna diferencia. Actualmente el problema no tiene ningún sentido para mí.
James L
Bien, ahora esto comenzó a funcionar de manera inexplicable para todos los que deberían tener acceso en función de los permisos que había otorgado hace semanas. No tengo idea de por qué esto solo comenzó a funcionar en los últimos días. Entonces, el problema parece estar resuelto, pero no tengo idea de por qué comenzó o por qué se detuvo cuando lo hizo. Supongo que está relacionado con cambios de política de grupo no anunciados.
James L

Respuestas:

9

Posibilidad muy remota tal vez, pero vale la pena revisar el archivo

\ Archivos de programa \ Microsoft SQL Server \ 100 \ DTS \ Binn \ MsDtsSrvr.ini

o el equivalente en su configuración. Puede que tenga que editarlo manualmente con el nombre de la instancia. De lo contrario, las conexiones SSIS podrían estar buscando un msdb de una instancia SQL predeterminada que no existe.

John Alan
fuente
1
Gracias, pero ya lo configuré. Votado porque vale la pena mencionarlo.
James L
0

El problema tiene algo que ver con los permisos en el servidor subyacente y no con SSIS o MSDB. Tuvimos el mismo problema. Al agregar temporalmente la cuenta AD del usuario al grupo de administradores locales, esto se solucionó por nosotros. Agregar su cuenta AD a PowerUsers o Usuarios no lo hizo; Sin embargo, estoy seguro de que podríamos haber encontrado lo que faltaba en la Política de seguridad local para que esto suceda.

PseudoToad
fuente
Agregar a la cuenta local también funcionó para mí, ¿puede sugerirme cuál podría ser la razón probable? Como esto no podría ser la mejor práctica
Saurabh Sinha