Mejoras de seguridad de DCOM en Windows XP Service Pack 2 y Windows Server 2003 Service Pack 1

Windows Server XP Service Pack 2 (SP2) y Windows Server 2003 Service Pack 1 (SP1) presentan una configuración de seguridad predeterminada mejorada para el modelo de objetos componentes distribuidos (DCOM). En concreto, presentan derechos más granulares que permiten a un administrador tener control independiente sobre los permisos locales y remotos para iniciar, activar y acceder a servidores COM.

¿Qué hace DCOM?

El Modelo de objetos componentes de Microsoft (COM) es un sistema independiente de la plataforma, distribuido y orientado a objetos para crear componentes de software binarios que puedan interactuar. El modelo de objetos de componente distribuido (DCOM) permite que las aplicaciones se distribuyan entre ubicaciones que tengan más sentido para usted y para la aplicación. El protocolo de conexión DCOM proporciona de forma transparente compatibilidad con la comunicación confiable, segura y eficaz entre los componentes COM.

¿A quién se aplica esta característica?

Si usa COM solo para componentes COM en proceso, esta característica no se aplica a usted.

Esta característica se aplica a usted si tiene una aplicación de servidor COM que cumple uno de los siguientes criterios:

• El permiso de acceso para la aplicación es menos estricto que el permiso de inicio, que es necesario para ejecutar la aplicación.
• Normalmente, la aplicación se activa mediante un cliente COM remoto sin usar una cuenta administrativa.
• La aplicación está pensada para usarse solo localmente. Esto significa que puede restringir la aplicación de servidor COM para que no sea accesible de forma remota.

¿Qué nueva funcionalidad se agrega a esta característica en Windows XP Service Pack 2 y Windows Server 2003 Service Pack 1?

Restricciones para todo el equipo

Se ha realizado un cambio en COM para proporcionar controles de acceso para todo el equipo que rigen el acceso a todas las solicitudes de llamada, activación o inicio en el equipo. La manera más sencilla de pensar en estos controles de acceso es como una llamada de AccessCheck adicional que se realiza en una lista de control de acceso (ACL) de todo el equipo en cada llamada, activación o inicio de cualquier servidor COM en el equipo. Si se produce un error en AccessCheck , se deniega la llamada, la activación o la solicitud de inicio. Esto es además de cualquier AccessCheck que se ejecute en las ACL específicas del servidor. En efecto, proporciona un estándar de autorización mínimo que se debe pasar para tener acceso a cualquier servidor COM del equipo. Hay una ACL para todo el equipo para los permisos de inicio para cubrir los derechos de activación e inicio, y una ACL para todo el equipo para los permisos de acceso para cubrir los derechos de llamada. Se pueden configurar a través de Servicios de componentes Microsoft Management Console (MMC).

Estas ACL para todo el equipo proporcionan una manera de invalidar la configuración de seguridad débil especificada por una aplicación específica a través de CoInitializeSecurity o la configuración de seguridad específica de la aplicación. Esto proporciona un estándar de seguridad mínimo que se debe pasar, independientemente de la configuración del servidor específico.

Estas ACL se comprueban cuando se accede a las interfaces expuestas por RPCSS. Esto proporciona un método para controlar el acceso a este servicio del sistema.

Estas ACL proporcionan una ubicación centralizada en la que un administrador puede establecer la directiva de autorización general que se aplica a todos los servidores COM del equipo.

Nota

Cambiar la configuración de seguridad en todo el equipo afectará a todas las aplicaciones de servidor COM y podría impedir que funcionen correctamente. Si hay aplicaciones de servidor COM que tienen restricciones menos estrictas que las restricciones de todo el equipo, reducir las restricciones de todo el equipo podría exponer estas aplicaciones al acceso no deseado. Por el contrario, si aumenta las restricciones de todo el equipo, es posible que algunas aplicaciones de servidor COM ya no sean accesibles mediante una llamada a aplicaciones.

De forma predeterminada, la configuración de restricción de equipos de Windows XP SP2 es:

Permiso	Administrador	Todos	Anónimas
Launch	Inicio local Activación local Inicio remoto Activación remota	Inicio local Activación local
Access		Acceso local Acceso remoto	Acceso local

De forma predeterminada, la configuración de restricción de equipos de Windows Server 2003 SP 1 es la siguiente.

Permiso	Administrador	Usuarios COM distribuidos (grupo integrado)	Todos	Anónimas
Launch	Inicio local Activación local Inicio remoto Activación remota	Inicio local Activación local Inicio remoto Activación remota	Inicio local Activación local	N/D
Access	N/D	Acceso local Acceso remoto	Acceso local Acceso remoto	Acceso local Acceso remoto

Nota

Usuarios COM distribuidos es un nuevo grupo integrado incluido con Windows Server 2003 SP1 para acelerar el proceso de agregar usuarios a la configuración de restricción del equipo DCOM. Este grupo forma parte de la ACL que usa la configuración de MachineAccessRestriction y MachineLaunchRestriction , por lo que la eliminación de usuarios de este grupo afectará a esa configuración.

¿Por qué es importante este cambio? ¿Qué amenazas ayuda a mitigar?

Muchas aplicaciones COM incluyen código específico de seguridad (por ejemplo, llamar a CoInitializeSecurity), pero usar configuraciones débiles, a menudo permitiendo el acceso no autenticado al proceso. Actualmente no hay ninguna manera de que un administrador invalide esta configuración para forzar una mayor seguridad en versiones anteriores de Windows.

La infraestructura COM incluye RPCSS, un servicio del sistema que se ejecuta durante el inicio del sistema y siempre se ejecuta después de eso. Administra la activación de objetos COM y la tabla de objetos en ejecución y proporciona servicios auxiliares a la comunicación remota de DCOM. Expone las interfaces RPC a las que se puede llamar de forma remota. Dado que algunos servidores COM permiten el acceso remoto no autenticado, cualquier usuario puede llamar a estas interfaces, incluidos los usuarios no autenticados. Como resultado, RPCSS puede ser atacado por usuarios malintencionados en equipos remotos y no autenticados.

En versiones anteriores de Windows, no había forma de que un administrador comprenda el nivel de exposición de los servidores COM en un equipo. Un administrador tiene una idea del nivel de exposición comprobando sistemáticamente las opciones de seguridad configuradas para todas las aplicaciones COM registradas en el equipo, pero, dado que hay aproximadamente 150 servidores COM en una instalación predeterminada de Windows, esa tarea fue intimidante. No había ninguna manera de ver la configuración de un servidor que incorpora seguridad en el software, sin revisar el código fuente de ese software.

Las restricciones para todo el equipo DCOM mitigan estos tres problemas. También proporciona a un administrador la capacidad de deshabilitar la activación, el inicio y las llamadas entrantes de DCOM.

¿Qué funciona de manera diferente?

De forma predeterminada, al grupo Todos se le conceden permisos de inicio local, activación local y llamada de acceso local. Esto permite que todos los escenarios locales funcionen sin modificaciones en el software o en el sistema operativo.

De forma predeterminada, en Windows XP SP2, al grupo Todos se le conceden permisos de llamada de acceso remoto. En Windows Server 2003 SP1, a los grupos Todos y Anónimos se les conceden permisos de acceso remoto. Esto permite la mayoría de los escenarios de cliente COM, incluido el caso común en el que un cliente COM pasa una referencia local a un servidor remoto, en efecto convirtiendo el cliente en un servidor. En Windows XP SP2, esto podría deshabilitar escenarios que requieren llamadas de acceso remoto no autenticadas.

De forma predeterminada, solo a los miembros del grupo Administradores se les conceden permisos de activación remota e inicio. Esto deshabilita las activaciones remotas por parte de los no administradores en servidores COM instalados.

Cómo resolver estos problemas?

Si implementa un servidor COM y espera admitir la activación remota por parte de un cliente COM no administrativo, debe considerar si el riesgo asociado con la habilitación de este proceso es aceptable o si debe modificar la implementación para no requerir la activación remota por parte de un cliente COM no administrativo o llamadas remotas no autenticadas.

Si el riesgo es aceptable y desea habilitar la activación remota mediante un cliente COM no administrativo o llamadas remotas no autenticadas, debe cambiar la configuración predeterminada de esta característica.

Nota

Cambiar la configuración de seguridad en todo el equipo afectará a todas las aplicaciones de servidor COM y podría impedir que funcionen correctamente. Si hay aplicaciones de servidor COM que tienen restricciones menos estrictas que las restricciones de todo el equipo, reducir las restricciones de todo el equipo puede exponer estas aplicaciones al acceso no deseado. Por el contrario, si aumenta las restricciones de todo el equipo, es posible que algunas aplicaciones de servidor COM ya no sean accesibles mediante una llamada a aplicaciones.

Puede cambiar las opciones de configuración mediante microsoft Management Console (MMC) de Servicios de componentes o el Registro de Windows.

Si usa el complemento MMC servicios de componentes, estas opciones se pueden configurar en la pestaña Seguridad COM del cuadro de diálogo Propiedades del equipo que administra. El área Permisos de acceso se ha modificado para permitirle establecer límites de todo el equipo además de la configuración predeterminada estándar para los servidores COM. Además, puede proporcionar una configuración de ACL independiente para el acceso local y remoto en ambos límites y valores predeterminados.

En el área Permisos de inicio y activación , puede controlar los permisos locales y remotos, así como los límites de todo el equipo y los valores predeterminados. Puede especificar permisos de activación local y remota e inicio de forma independiente.

Como alternativa, puede configurar estas opciones de ACL mediante el Registro.

Estas ACL se almacenan en el registro en las siguientes ubicaciones:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction=ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction=ACL

Estos son valores con nombre de tipo REG_BINARY que contienen datos que describen la ACL de las entidades de seguridad que pueden tener acceso a cualquier clase COM o objeto COM en el equipo. Los derechos de acceso de la ACL son:

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

Estas ACL se pueden crear mediante funciones de seguridad normales.

Nota

Para proporcionar compatibilidad con versiones anteriores, una ACL puede existir en el formato usado antes de Windows XP SP2 y Windows Server 2003 SP1, que solo usa el derecho de acceso COM_RIGHTS_EXECUTE, o bien puede existir en el nuevo formato usado en Windows XP SP2 y Windows Server 2003 SP1, que usa COM_RIGHTS_EXECUTE junto con una combinación de COM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL y COM_RIGHTS_ACTIVATE_REMOTE. Tenga en cuenta que COM_RIGHTS_EXECUTE> siempre debe estar presente; la ausencia de este derecho genera un descriptor de seguridad no válido. Tenga en cuenta también que no debe mezclar el formato antiguo y el nuevo formato dentro de una sola ACL; todas las entradas de control de acceso (ACE) deben conceder solo el derecho de acceso COM_RIGHTS_EXECUTE, o bien todos deben conceder COM_RIGHTS_EXECUTE junto con una combinación de COM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL y COM_RIGHTS_ACTIVATE_REMOTE.

Nota

Solo los usuarios con derechos de administrador pueden modificar esta configuración.

¿Qué funcionalidad existente cambia en Windows XP Service Pack 2 y Windows Server 2003 Service Pack 1?

RPCSS se ejecuta como un servicio de red

RPCSS es un servicio clave para la infraestructura del asignador de puntos de conexión RPC y DCOM. Este servicio se ejecutó como sistema local en versiones anteriores de Windows. Para reducir la superficie expuesta a ataques de Windows y proporcionar defensa en profundidad, la funcionalidad del servicio RPCSS se dividió en dos servicios. El servicio RPCSS con toda la funcionalidad original que no requería privilegios de sistema local ahora se ejecuta en la cuenta de servicio de red. Un nuevo servicio DCOMLaunch que incluye la funcionalidad que requiere privilegios de sistema local se ejecuta en la cuenta del sistema local.

¿Por qué es importante este cambio?

Este cambio reduce la superficie expuesta a ataques y proporciona defensa en profundidad para el servicio RPCSS porque una elevación de privilegios en el servicio RPCSS ahora está limitada al privilegio servicio de red.

¿Qué funciona de manera diferente?

Este cambio debe ser transparente para los usuarios porque la combinación de los servicios RPCSS y DCOMLaunch es equivalente al servicio RPCSS anterior proporcionado en versiones anteriores de Windows.

Permisos COM más específicos

Las aplicaciones de servidor COM tienen dos tipos de permisos: permisos de inicio y permisos de acceso. Inicie la autorización de control de permisos para iniciar un servidor COM durante la activación COM si el servidor aún no se está ejecutando. Estos permisos se definen como descriptores de seguridad especificados en la configuración del Registro. Los permisos de acceso controlan la autorización para llamar a un servidor COM en ejecución. Estos permisos se definen como descriptores de seguridad proporcionados a la infraestructura COM a través de coInitializeSecurity API o mediante la configuración del Registro. Los permisos de inicio y acceso permiten o deniegan el acceso en función de las entidades de seguridad y no distinguen si el autor de la llamada es local para el servidor o remoto.

El primer cambio distingue los derechos de acceso COM, en función de la distancia. Las dos distancias definidas son Local y Remote. Un mensaje COM local llega por medio del protocolo de llamada a procedimiento remoto local (LRPC), mientras que un mensaje COM remoto llega mediante un protocolo host de llamada a procedimiento remoto (RPC), como el protocolo de control de transmisión (TCP).

La activación COM es el acto de obtener un proxy de interfaz COM en un cliente mediante una llamada a CoCreateInstance o a una de sus variantes. Como efecto secundario de este proceso de activación, a veces se debe iniciar un servidor COM para satisfacer la solicitud del cliente. Una ACL de permisos de inicio afirma quién puede iniciar un servidor COM. Una ACL de permisos de acceso afirma quién puede activar un objeto COM o llamar a ese objeto una vez que el servidor COM ya se está ejecutando.

El segundo cambio es que los derechos de llamada y activación se separan para reflejar dos operaciones distintas y para mover la activación directamente desde la ACL del permiso de acceso a la ACL del permiso de inicio. Dado que tanto la activación como el inicio están relacionados con la adquisición de un puntero de interfaz, la activación y los derechos de acceso de inicio pertenecen lógicamente en una ACL. Y dado que siempre se especifican permisos de inicio a través de la configuración (en comparación con los permisos de acceso, que a menudo se especifican mediante programación), colocar los derechos de activación en la ACL de permiso de inicio proporciona al administrador control sobre la activación.

Las entradas de control de acceso de permisos de inicio (ACE) se dividen en cuatro derechos de acceso:

• Inicio local (LL)
• Inicio remoto (RL)
• Activación local (LA)
• Activación remota (RA)

El descriptor de seguridad de permisos de acceso se divide en dos derechos de acceso:

• Llamadas de acceso local (LC)
• Llamadas de acceso remoto (RC)

Esto permite al administrador aplicar configuraciones de seguridad muy específicas. Por ejemplo, puede configurar un servidor COM para que acepte llamadas de acceso local de todos los usuarios, al tiempo que solo acepta llamadas de acceso remoto de los administradores. Estas distinciónes se pueden especificar mediante cambios en los descriptores de seguridad de permisos COM.

¿Por qué es importante este cambio? ¿Qué amenazas ayuda a mitigar?

Las versiones anteriores de la aplicación de servidor COM no tienen ninguna manera de restringir una aplicación para que solo se pueda usar localmente sin exponer la aplicación en la red mediante DCOM. Cuando un usuario tiene acceso a una aplicación de servidor COM, tiene acceso para uso local y remoto.

Una aplicación de servidor COM puede exponerse a usuarios no autenticados para implementar un escenario de devolución de llamada COM. En este escenario, la aplicación también debe exponer su activación a usuarios no autenticados, lo que podría no ser deseable.

Los permisos COM precisos proporcionan flexibilidad al administrador para controlar la directiva de permisos COM de un equipo. Estos permisos habilitan la seguridad para los escenarios descritos.

¿Qué funciona de manera diferente? ¿Hay alguna dependencia?

Para proporcionar compatibilidad con versiones anteriores, los descriptores de seguridad COM existentes se interpretan para permitir o denegar el acceso local y remoto simultáneamente. Es decir, una entrada de control de acceso (ACE) permite tanto local como remota, o deniega tanto local como remota.

No hay problemas de compatibilidad con versiones anteriores para los derechos de llamada o inicio. Sin embargo, hay un problema de compatibilidad con derechos de activación. Si, en los descriptores de seguridad existentes para un servidor COM, los permisos de inicio configurados son más restrictivos que los permisos de acceso y son más restrictivos que los que son mínimamente necesarios para escenarios de activación de cliente, la ACL de permisos de inicio debe modificarse para conceder a los clientes autorizados los permisos de activación adecuados.

En el caso de las aplicaciones COM que usan la configuración de seguridad predeterminada, no hay problemas de compatibilidad. En el caso de las aplicaciones que se inician dinámicamente mediante la activación COM, la mayoría no tiene problemas de compatibilidad, ya que los permisos de inicio ya deben incluir a cualquier persona que pueda activar un objeto. De lo contrario, estas aplicaciones generan errores de activación incluso antes de aplicar Windows XP SP2 o Windows Server 2003 SP1, cuando los autores de llamadas sin permiso de inicio intentan activar un objeto y el servidor COM aún no se está ejecutando.

Las aplicaciones de mayor preocupación para los problemas de compatibilidad son las aplicaciones COM que ya están iniciadas por algún otro mecanismo, como el Explorador de Windows o el Administrador de control de servicios. También puede iniciar estas aplicaciones mediante una activación COM anterior, que invalida los permisos de inicio y acceso predeterminados y especifica los permisos de inicio que son más restrictivos que los permisos de llamada. Para obtener más información sobre cómo solucionar este problema de compatibilidad, consulte "Cómo resolver estos problemas?" en la sección siguiente.

Si un sistema actualizado a Windows XP SP2 o Windows Server 2003 SP1 se revierte a un estado anterior, cualquier ACE que se editó para permitir el acceso local, el acceso remoto o ambos, se interpreta para permitir el acceso local y remoto. Cualquier ACE que se editó para denegar el acceso local, el acceso remoto o ambos, se interpreta para denegar el acceso local y remoto. Siempre que desinstale un Service Pack, debe asegurarse de que ningún ACA recién establecido haga que las aplicaciones dejen de funcionar.

Cómo resolver estos problemas?

Si implementa un servidor COM y invalida la configuración de seguridad predeterminada, confirme que la ACL de permisos de inicio específicos de la aplicación concede permiso de activación a los usuarios adecuados. Si no es así, debe cambiar la ACL de permiso de inicio específico de la aplicación para conceder derechos de activación de usuarios adecuados para que las aplicaciones y los componentes de Windows que usan DCOM no produzcan errores. Estos permisos de inicio específicos de la aplicación se almacenan en el registro.

Las ACL COM se pueden crear o modificar mediante funciones de seguridad normales.

¿Qué configuración se agrega o cambia en Windows XP Service Pack 2?

Precaución

El uso incorrecto de esta configuración puede hacer que las aplicaciones y los componentes de Windows que usan DCOM produzcan un error.

En la tabla siguiente, se usan estas abreviaturas:

LL: inicio local

LA: activación local

RL: inicio remoto

RA: activación remota

LC: llamadas de acceso local

RC: llamadas de acceso remoto

ACL: lista de Access Control

Nombre del valor	Location	Valor predeterminado anterior	Valor predeterminado	Valores posibles
MachineLaunchRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos - LL, LA, RL, RA Anónimo- LL, LA, RL, RA (Se trata de una nueva clave del Registro. En función del comportamiento existente, estos son los valores efectivos).	Administrador: LL, LA, RL, RA	ACL
MachineAccessRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos - LC, RC Anónimo: LC, RC (Se trata de una nueva clave del Registro. En función del comportamiento existente, estos son los valores efectivos).	Todos: LC, RC Anónimo: LC	ACL
CallFailureLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	No es aplicable.	Esta clave del Registro no está presente; sin embargo, una clave o un valor que faltan se interpretan como 2. Este evento no se registra de forma predeterminada. Si cambia este valor a 1 para empezar a registrar esta información para ayudarle a solucionar un problema, asegúrese de supervisar el tamaño del registro de eventos, ya que se trata de un evento que puede generar un gran número de entradas.	1- Registrar siempre errores de registro de eventos durante una llamada en el proceso del servidor COM. 2 - Nunca registre errores de registro de eventos durante una llamada en el proceso del servidor de llamadas.
InvalidSecurityDescriptorLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	No es aplicable.	Esta clave del Registro no está presente; sin embargo, una clave o un valor que faltan se interpretan como 1. Este evento se registra de forma predeterminada. Rara vez debería ocurrir.	1- Registrar siempre errores de registro de eventos cuando la infraestructura COM encuentra un descriptor de seguridad no válido. 2- Nunca registre errores de registro de eventos cuando la infraestructura COM encuentre un descriptor de seguridad no válido.
DCOM:Restricciones de inicio de máquina en la sintaxis del lenguaje de definición de descriptores de seguridad (SDDL)	(directiva de grupo objeto) Configuración del equipo \Configuración de Windows\Directivas locales \Opciones de seguridad	No es aplicable.	No definida	Lista de control de acceso en formato SDDL. La existencia de esta directiva invalida los valores en MachineLaunchRestriction, anteriormente.
DCOM:Restricciones de acceso de máquina en la sintaxis del lenguaje de definición de descriptores de seguridad (SDDL)	(directiva de grupo objeto) Configuración del equipo \Configuración de Windows \Directivas locales \Opciones de seguridad	No es aplicable.	No definida	Lista de control de acceso en formato SDDL. La existencia de esta directiva invalida los valores de MachineAccessRestriction, anteriormente.

¿Qué configuraciones se agregan o cambian en Windows Server 2003 Service Pack 1?

Nota

El uso incorrecto de esta configuración puede hacer que se produzcan errores en las aplicaciones y los componentes de Windows que usan DCOM.

En la tabla siguiente, se usan estas abreviaturas:

LL: inicio local

LA: activación local

RL: inicio remoto

RA: activación remota

LC: llamadas de acceso local

RC: llamadas de acceso remoto

ACL: lista de Access Control

Nombre del valor	Location	Valor predeterminado anterior	Valor predeterminado	Valores posibles
MachineLaunchRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos: LL, LA, RL, RA Anónimo: LL, LA, RL, RA (Se trata de una nueva clave del Registro. En función del comportamiento existente, estos serían los valores efectivos).	Administrador: LL, LA, RL, RA Todos: LL, LA Usuarios COM distribuidos: LL, LA, RL, RA	ACL
MachineAccessRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos: LC, RC Anónimo: LC, RC (Se trata de una nueva clave del Registro. En función del comportamiento existente, estos serían los valores efectivos).	Todos: LC, RC Anónimo: LC, RC	ACL
CallFailureLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	No es aplicable.	Esta clave del Registro no está presente; sin embargo, una clave o un valor que faltan se interpretan como 2. Este evento no se registra de forma predeterminada. Si cambia este valor a 1 para empezar a registrar esta información para ayudarle a solucionar un problema, asegúrese de supervisar el tamaño del registro de eventos, ya que se trata de un evento que puede generar un gran número de entradas.	1- Registrar siempre errores de registro de eventos cuando la infraestructura COM encuentra un descriptor de seguridad no válido. 2- Nunca registre errores de registro de eventos cuando la infraestructura COM encuentre un descriptor de seguridad no válido.
InvalidSecurityDescriptorLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	No es aplicable.	Esta clave del Registro no está presente; sin embargo, una clave o un valor que faltan se interpretan como 1. Este evento se registra de forma predeterminada. Rara vez debería ocurrir.	1- Registrar siempre errores de registro de eventos cuando la infraestructura COM encuentra un descriptor de seguridad no válido. 2 - Nunca registre errores de registro de eventos cuando la infraestructura COM encuentre un descriptor de seguridad no válido.
DCOM:Restricciones de inicio de máquina en la sintaxis del lenguaje de definición de descriptores de seguridad (SDDL)	(directiva de grupo objeto) Configuración del equipo \Configuración de Windows \Directivas locales \Opciones de seguridad	No es aplicable.	Sin definir.	Lista de control de acceso en formato SDDL. La existencia de esta directiva invalida los valores de MachineLaunchRestriction, anteriormente.
DCOM:Restricciones de acceso de máquina en la sintaxis del lenguaje de definición de descriptores de seguridad (SDDL)	(directiva de grupo objeto) Configuración del equipo \Configuración de Windows \Directivas locales \Opciones de seguridad	No es aplicable.	Sin definir.	Lista de control de acceso en formato SDDL. La existencia de esta directiva invalida los valores de MachineAccessRestriction, anteriormente.

Temas relacionados

Seguridad en COM