"Acceso denegado" al conectar SSMS a Integration Services

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.

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.

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.