¿Cómo solucionar el error de DCOM 0x800070005 (Access is Denied) al conectar un cliente OPC DA a WinCC en PCS 7?

Para solucionar el error HRESULT 0x800070005 (Access is Denied) en conexiones DCOM de OPC DA hacia el servidor WinCC de PCS 7, agregue la cuenta de usuario compartida al grupo local «Distributed COM Users» en el sistema operativo Windows Server, configure los límites de acceso remoto en OLE/COM mediante la dcomcnfg y ejecute la conexión hacia el servidor HMI secundario para evadir el bloqueo de sockets.

¿Cómo solucionar el error de DCOM 0x800070005 (Access is Denied) al conectar un cliente OPC DA a WinCC en PCS 7?

Category: PCS 7 / Connectivity | Technology: Siemens WinCC OPC DA Server, DCOM Configuration (dcomcnfg), Windows Server 2016/2019, AspenTech CIMIO, OLE/COM Security, OPCEnum | Article Type: Troubleshooting Guide | Code: C135

Context: Diagnóstico de capas de seguridad del sistema operativo y resolución de bloqueos de autenticación DCOM en la arquitectura de red de terminales (Terminal Bus) al conectar clientes OPC corporativos externos a servidores HMI redundantes.

¿Cómo solucionar el error de DCOM 0x800070005 (Access is Denied) al conectar un cliente OPC DA a WinCC en PCS 7?
El error de denegación de acceso lúdico 0x800070005 (Access is denied) que interrumpe el enlace del cliente OPC DA (como AspenTech CIMIO) hacia el servidor remoto OPCServer.WinCC —a pesar de que el servicio OPCEnum resuelve correctamente los identificadores CLSID y el cortafuegos está desactivado— ocurre porque la cuenta de usuario de Windows de la estación cliente no está validada dentro de las listas de control de acceso (ACL) del subsistema COM distribuido en el servidor de destino. Para solucionarlo, debe registrar la cuenta de usuario lúdica dentro del grupo de seguridad de Windows Distributed COM Users en el servidor de WinCC, otorgar permisos explícitos de activación remota en los límites globales de DCOM y, si el nodo principal mantiene sus canales saturados por otros clientes (como KepServer), desviar el apuntamiento del cliente hacia la instancia espejo del servidor HMI secundario de respaldo (OPCServer.WinCC.1).

First Checks Before Modifying DCOM Security

Production note: La alteración de las políticas lógicas de DCOM y los permisos de las cuentas de usuario locales en servidores principales de PCS 7 en producción puede provocar la desconexión imprevista de otros clientes OPC activos. Realice las pruebas de conectividad de los nuevos clientes corporativos aprovechando la redundancia de los servidores (Server Failover) o ejecute los cambios inicialmente sobre el servidor HMI secundario (Standby OS Server) para mitigar los riesgos de paradas de planta.

Confirmar homogeneidad de credenciales: Verifique que la estación cliente (Windows Server 2019) y el servidor de WinCC (Windows Server 2016) posean exactamente el mismo nombre de usuario y contraseña local con privilegios administrativos compartidos si no se opera bajo un entorno de Dominio de planta unificado.
Validar el estado local con OPC Scout: Inicie la utilidad nativa de Siemens OPC Scout directamente dentro del servidor OS primario. Si la herramienta se conecta de forma local al servidor OPCServer.WinCC con calidad estricta Good, el motor de base de datos de WinCC está saludable y el problema está confinado exclusivamente a la capa de red de DCOM.
Verificar el servicio OPCEnum: Asegúrese de que en los servicios de Windows (services.msc) de ambas máquinas, el servicio OPCEnum esté configurado en modo automático y en estado de ejecución para garantizar el intercambio síncrono del catálogo de servidores.

Technical Context and Problem Background

En las plataformas de control de procesos basadas en Siemens SIMATIC PCS 7, la exportación de variables de planta en tiempo real hacia sistemas de gestión de producción (MES) o historiadores corporativos avanzados (como AspenTech InfoPlus.21 mediante interfaces CIMIO) se gestiona de manera clásica a través del protocolo industrial clásico OPC DA (Data Access). Debido a que OPC DA fue desarrollado sobre la infraestructura tecnológica heredada de Microsoft COM (Component Object Model) y DCOM (Distributed COM), el canal de comunicación no viaja encapsulado en un único puerto web limpio; depende de la negociación dinámica de llamadas a procedimientos remotos (RPC) sobre el puerto maestro 135 de Windows.

El fallo específico analizado en campo se presenta cuando la arquitectura de red es capaz de completar la primera fase del handshake: el cliente consulta al servicio de enumeración remoto, recibe el CLSID {75D00BBB-DDA5-11D1-B944-9E614D000000} correspondiente al componente central lúdico de WinCC y descubre los nombres de los servidores lógicos libres. Sin embargo, al disparar la petición de inicialización del servidor de datos (CoCreateInstanceEx), el sistema operativo Windows Server bloquea el paso de la instrucción y devuelve el código crítico HRESULT 0x80070005.

Este código indica un bloqueo por directiva de seguridad galvánica a nivel de kernel de Windows. Aunque el ingeniero haya configurado los permisos para el grupo genérico Everyone (Todos) y Anonymous Logon en la herramienta gráfica dcomcnfg, las políticas de seguridad avanzadas implementadas a partir de Windows Server 2016 restringen las llamadas de activación remota anónimas. Además, si el servidor HMI principal ya sostiene un canal de datos exigente abierto con otro cliente externo (como un servidor KepServer), la pila de sockets de red bloquea los intentos de inicio de sesión concurrentes si la identidad del nuevo cliente no se encuentra explícitamente indexada en los descriptores lógicos de los grupos de usuarios autorizados del sistema.

Diagnostic Path for Outbound Sockets and Security Logs

Para determinar si el bloqueo lúdico proviene de un rechazo de credenciales del sistema operativo o de una saturación de canales de red por hilos concurrentes, aplique la siguiente metodología de diagnóstico estructural:

Analizar el registro de errores de CIMIO: Revise las marcas de tiempo en las trazas del cliente. Si detecta líneas consecutivas que indican el fallo de creación de sockets salientes:

Plaintext
WNT Error=10061 No connection could be made because the target machine actively refused it.

Esto confirma que la tarjeta de red del servidor está rechazando activamente el socket físico de red en los puertos dinámicos altos de RPC, usualmente debido a que la sesión COM no superó el filtro de identidad inicial.
2. Monitorear el Visor de Eventos de Windows: Acceda al visor de eventos lógicos de Windows Server en el equipo de WinCC. Expanda los directorios Windows Logs > Security. Busque eventos de auditoría fallida (Audit Failure) con identificadores relacionados con accesos de red y subcapas COM. El evento detallará qué nombre de usuario del nodo remoto fue rechazado por el sistema.
3. Verificar procesos en ejecución en el Administrador de tareas: Al buscar el servidor OPC de WinCC en el Task Manager, no localizará un ejecutable independiente con ese nombre lúdico. El motor OPC DA de Siemens corre integrado directamente dentro de los hilos de ejecución de los procesos del núcleo de WinCC Runtime (como el administrador de variables de adquisición de datos). Si el Runtime está desactivado en el OS Server, la conexión fallará de forma sistemática con errores de denegación.

Configuration Procedure: Setting Windows Groups and DCOM Limits

Para corregir los permisos del descriptor de seguridad de Windows de forma permanente y asegurar un canal estable de lectura de tags sin poner en riesgo la disponibilidad del servidor lúdico principal de la planta, aplique los siguientes procedimientos técnicos de configuración:

Paso 1: Indexar el usuario en el grupo Distributed COM Users

En el servidor principal de WinCC, abra el cuadro de diálogo de ejecución de Windows (Win + R), introduzca el comando para abrir el administrador de usuarios locales y haga clic en OK:
lusrmgr.msc
En el árbol izquierdo, haga clic en el directorio Groups (Grupos).
Localice en la lista central el grupo integrado del sistema operativo denominado Distributed COM Users (Usuarios de COM distribuido) y haga doble clic sobre él.
En la ventana de propiedades que aparece, haga clic en el botón Add... (Agregar...).
Introduzca el nombre exacto de la cuenta de usuario de Windows utilizada por la estación cliente OPC DA corporativa (por ejemplo, el usuario dedicado configurado en el nodo de AspenTech CIMIO). Haga clic en Check Names para validar el identificador lúdico y presione OK.
Haga clic en Apply. Nota de campo de seguridad: De acuerdo a las directivas de seguridad de las cuentas de Windows Server, los derechos de este grupo no se aplicarán de forma caliente inmediata; la cuenta remota deberá realizar un nuevo inicio de sesión lúdico (Logon) para refrescar sus tokens de acceso en el próximo intento de conexión de la interfaz.

[Administrador de Usuarios en WinCC] -> Grupo: Distributed COM Users
                                          |--- Agregar: [Cuenta_Usuario_Cliente_OPC]
                                          |--- Otorga derechos base de paso sobre DCOM

Paso 2: Parametrizar los límites de seguridad global en DCOMCNFG

Abra el cuadro de ejecución (Win + R) en la máquina de WinCC, digite el comando de la consola de componentes y presione Enter:
dcomcnfg
Expanda la ruta izquierda: Component Services > Computers > My Computer.
Haga clic derecho sobre My Computer y seleccione Properties (Propiedades).
Seleccione la pestaña avanzada denominada COM Security (Seguridad COM).
Dentro de la sección Access Permissions (Permisos de acceso), haga clic en el botón Edit Limits... (Editar límites...). Asegúrese de verificar que los grupos Everyone, ANONYMOUS LOGON y el usuario específico del cliente posean activas las casillas de selección de Local Access y Remote Access. Acepte los cambios.
Diríjase a la sección inferior Launch and Activation Permissions (Permisos de ejecución y activación) y haga clic en su botón Edit Limits... (Editar límites...).
Localice el grupo de usuarios específico o añada la cuenta remota y active de forma mandatoria las casillas de verificación avanzadas:
- Local Launch y Remote Launch
- Local Activation y Remote Activation (Esta última casilla de activación remota es el pin de seguridad que suele estar bloqueado en Windows Server 2016 e induce el código de error 0x80070005). Haga clic en OK y aplique las modificaciones de la consola.

Paso 3: Configurar la conexión espejo sobre el Servidor HMI Secundario (Standby)

Si el servidor HMI primario rechaza el socket de red debido a que la interfaz de comunicación está saturada por enlaces concurrentes de otros clientes industriales (como KepServer), aproveche la infraestructura redundante de PCS 7 para equilibrar la carga de la planta sin interrumpir las operaciones:

Acceda a la consola de configuración de la interfaz de la estación cliente OPC DA (AspenTech CIMIO Configuration).
En las propiedades de direccionamiento del nodo del servidor de destino, modifique la dirección IP principal y apunte el parámetro hacia la interfaz de red física del servidor de WinCC secundario (Standby Server).
Al modificar el destino, la herramienta de descubrimiento del cliente detectará el identificador del servidor OPC de WinCC modificado por el sufijo secuencial lúdico del motor redundante de Siemens, indexado con el nombre:
OPCServer.WinCC.1 (o la referencia de ProgID equivalente provista por OpenPCS 7).
Aplique las mismas configuraciones de grupos y límites DCOM del Paso 1 y Paso 2 en el sistema operativo de este segundo servidor. Al iniciar la interfaz, CIMIO completará el login de sesión y establecerá la comunicación exitosa en el primer intento, evadiendo de forma segura el bloqueo de recursos del nodo primario.

Common Industrial SCADA Integration Mistakes

Omitir el permiso de Activación Remota (Remote Activation): Configurar únicamente los permisos de acceso y lectura simples en DCOM pero dejar desactivada la casilla de activación remota. El cliente OPC logrará listar los ProgID (gracias a OPCEnum), pero fallará de forma instantánea al intentar despertar y leer el motor interno de tags de WinCC.
Ejecutar cambios de DCOM sin verificar el estado del Runtime: Intentar depurar y probar las conexiones de red de los clientes externos de bases de datos mientras el proyecto de WinCC en el servidor de destino se encuentra desactivado o en fase de edición en el WinCC Explorer. Sin el modo Runtime activo en el bastidor virtual, las llamadas OLE/COM fallarán de forma continua arrojando códigos de error de socket denegado.
Debilitar la seguridad del servidor mediante configuraciones inseguras masivas: Otorgar permisos de control total indiscriminados a cuentas de sistema o deshabilitar políticas de seguridad globales de Windows Server sin el consentimiento del equipo de ciberseguridad industrial de la planta. Esto expone el bus de terminales (Terminal Bus) del DCS a riesgos de malware de TI innecesarios.

OPC DA Connection Verification Checklist

¿La cuenta de usuario de la estación cliente fue agregada al grupo Distributed COM Users en el servidor WinCC?: Yes / No / Needs Review
¿Se activaron explícitamente los permisos de Remote Activation en los límites globales de dcomcnfg?: Yes / No / Needs Review
¿El cliente OPC DA logra conectarse de forma estable al servidor secundario bajo el ProgID OPCServer.WinCC.1?: Yes / No / Needs Review
¿La calidad de las variables de producción (tags) se muestra Good y actualiza sus lecturas en la interfaz de CIMIO?: Yes / No / Needs Review

FAQ

¿Por qué el cliente OPC DA puede descubrir el nombre del servidor lúdico en la red pero falla al intentar establecer la conexión final de tags? Este comportamiento es un síntoma clásico del funcionamiento segregado de los servicios de Microsoft COM. El descubrimiento inicial y la lectura de los nombres de los servidores lógicos lúdicos (como OPCServer.WinCC) no los ejecuta el propio motor de WinCC; los gestiona un servicio independiente del sistema operativo denominado OPCEnum. Este servicio opera bajo sus propios identificadores CLSID y parámetros de seguridad permisivos que suelen estar abiertos por defecto en Windows para permitir que los exploradores listen los productos en estante. Sin embargo, en el instante exacto en que el cliente OPC intenta dar el segundo paso e inicializar el motor de datos real de WinCC, Windows interviene y evalúa de forma estricta las listas de control de acceso (ACL) de DCOM. Si la cuenta de usuario remota carece del derecho de activación remota (Remote Activation), el sistema bloquea el socket a nivel de kernel y devuelve el código de error de acceso denegado 0x80070005.

¿Qué precauciones técnicas se deben considerar al operar múltiples clientes OPC DA en un entorno redundante de PCS 7? Las especificaciones de arquitectura de Siemens establecen que los servidores HMI principales (OS Servers) de PCS 7 poseen capacidades de hilos de ejecución de hardware limitadas para procesar conexiones de red externas, ya que su prioridad crítica es mantener la sincronización redundante, la adquisición de alarmas en el bus de planta y el refresco de las pantallas de la sala de control. Si un cliente OPC de gran envergadura corporativa (como un recolector CIMIO de AspenTech o un servidor KepServer de TI) interroga miles de tags con tasas de refresco agresivas o mantiene múltiples sockets abiertos de forma concurrente sobre el mismo nodo, puede saturar la pila de hilos de comunicación COM de la CPU del servidor. La mejor práctica de ingeniería industrial para equilibrar la carga de datos de la planta consiste en segregar las conexiones de los clientes externos de bases de datos: configure un cliente apuntando al servidor primario (OPCServer.WinCC) y asigne el segundo cliente hacia el servidor de respaldo secundario utilizando el ProgID extendido indexado como OPCServer.WinCC.1.

¿Se puede solucionar el error 0x80070005 migrando la conectividad de los tags hacia el estándar de comunicación OPC UA? Sí, de forma categórica. El estándar moderno OPC UA (Unified Architecture) fue diseñado específicamente para reemplazar la dependencia obsoleta de las tecnologías Microsoft DCOM de los años 90 en el piso de planta. OPC UA prescinde de la negociación de puertos dinámicos RPC y del mapeo de usuarios locales en Windows; toda la comunicación viaja encapsulada de forma segura a través de un único puerto TCP predefinido y configurable (habitualmente el puerto estándar 4840), implementando mecanismos avanzados de autenticación basados en certificados digitales lúdicos lógicos e identidades de usuario cifradas dentro del propio canal de la aplicación. Si la suite instalada de PCS 7 y los sistemas MES clientes soportan la pila de protocolos de OPC UA, migrar la arquitectura hacia este estándar elimina de forma definitiva los dolores de cabeza de configuración de seguridad, los conflictos de cortafuegos y los errores de denegación de DCOM de Windows Server.

Contact / Support

¿Necesita asistencia de ingeniería experta para la depuración de configuraciones de seguridad DCOM, integración de recolectores de datos AspenTech CIMIO o soporte técnico en servidores OPC industriales de Siemens?

Póngase en contacto con nuestro departamento de ingenieros especialistas certificados en sistemas de automatización, ciberseguridad industrial y redes de conectividad de procesos de planta.

Technical Classification

Category: PCS 7 / Connectivity

Technology: Siemens SIMATIC PCS 7 WinCC SCADA Suite, Microsoft DCOM Subcapas de Seguridad, Interfaces de Conectividad OPC DA

Object Type: DCOM Launch and Activation ACL Limits, OPCServer.WinCC Registry Entries, Windows Server Local Group Policies

Use Case: Resolución de fallos de denegación de acceso lúdico lógicos y bloqueos de seguridad del sistema operativo en el intercambio de datos entre redes de operaciones (OT) y sistemas corporativos (IT).

Article Type: Troubleshooting Guide

Applies To: WinCC V7.x integrado en entornos PCS 7, Windows Server 2016 Standard, Windows Server 2019 Datacenter, Interfaces AspenTech CIMIO, Servidores Redundantes OS

Primary Search Intent: OPC DA WinCC DCOM 80070005 Error Access is Denied.

Related Search Phrases:

¿Cómo solucionar el error de DCOM 0x800070005 (Access is Denied) al conectar un cliente OPC DA a WinCC en PCS 7?